You could have a frontpage with a very simple redirect to the pods who gladly have more users, and a link to a page with multiple options. The frontpage would be a great way to channel new user who do not give a crap about al the technical stuff, to pods who would like new users and relieve other pods.
I am not to technical but would it be an idea to have a new field in your json list, where the podmins could set a priority to how much they would like new users. “will gladly accept more users”, “almost full” etc. as a refinement of the registrations_open boolean?
To get normal people to join, the pod needs to be chosen for them.
One of the things diaspora is all about, surely, is enabling people to exercise choice and control over their data. Choosing a pod for them is not the way forward. What we need to do is to make it really simply for people to exercise their choice, not to take that choice away from them.
Another danger with removing the choice process from users is that they don’t realise that the network is decentralised and composed of many different pods (which is already a problem).
Now, OK I wouldn’t mind a ‘random’ button for choosing a pod, but only if it was at the very end, after the parts to help people choose, a sort of ‘I really can’t be bothered to make my own choice, so choose for me’ button.
There really has to be a vote before there is any move towards taking away the choice from prospective members, because it would be a change of direction for the project and certainly not uncontroversial.
@hola I like the approach you’re taking there, asking a few questions and then providing a short listing of options which closely match the answers. I think that approach will make it a lot easier to choose. Perhaps underneath there could be a small link ‘show me more choices’ in case a person isn’t convinced by any of the options shown. That could take you to the full pod list, if that’s what you want.
Another danger with removing the choice process from users is that they don’t realise that the network is decentralised and composed of many different pods (which is already a problem).
It’s not “removing” any choice - it’s making it easier to join the network. You can always change later when you understand what pods are.
its not just the pod issue,any project needs to weigh novice to expert … differing familiarity etc …im still trying to understand the complexities and resources and how they are utilised… the logical way to go is a modular construction,starting as riderplus say with basic … the added issues Diaspora has is with choice and security … these are Diasporas selling points ,but the two are not mutually compatiable in some cases … also the added pressures on developers and maintainers … im confident the Diaspora community will sort this and other issues out … my only frustration is whilst i can throw ideas about … theres nothing like ‘rock solid code’ to throw at someone … ’ here … use it,lose it or rip it apart for spares’ - we will get there to
If it is a given fact that for some new users is difficult to choose pod, yes of course it is vital to understand that is a federated network and if they want to have a quick and easy way to choose and at the same time recommend is better to choose pod according sam concepts.
Is a random system that includes only open pods and that we know work properly, also includes a list of pods only with the url and country.
The idea is only open registry pods and proven correct functionality.
Would greatly appreciate help completing the lsita of pods and translate the project to other languages. This pad to list pods https://titanpad.com/QhKPaa3yXu
@juansantiago well, it’s a very very good thing that you’re working on that project, but we also need to improve the aspects of the mainstream podupti.me. Hope you can help us with that, too
I still think that language is important. It is true that a lot of installations is in Holland and that most Podmin is able to write in English. But there is a big Spanish talking community too, and communicating in your mother-language is often preferable.
I am not sure how the Jason.json list is maintained, but if there is a possibility that the podmins themselves could change the values ‘Podmin_language’ might be a good addition to the list. Where the pod is hosted is one thing, but if you are an one-language-only person, the podmins language skills would be as important as where the server is hosted.
I am not sure how the Jason.json list is maintained, but if there is a possibility that the podmins themselves could change the values ‘Podmin_language’ might be a good addition to the list.
Well, it could be added to pod configuration and then exposed in the /statistics.json route - after that it’s easy to read into pod lists or the central pod chooser. But it needs to be somehow chosen by podmin, automatically figuring it out is a bit tricky
@jasonrobinson
Sorry for the late response. From the experience I have recommending Diaspora, I know for a fact that choosing a pod could be quite more “pod-agnostic” for the user.
I’m in favor of having a “choose a pod for me” option, and “choose manually”, maybe not with that wording, but that would be the general idea.
We could start iterating on some lo-fi mockups of a new interface. I’ll not be able to help with code for it until february,… Anyway, I think the best will be to start with some sketches. Even pen & paper, and avoid writing a single line of code until we get those right.
There are some people that may not ‘care’ as much as others about which pod to start with. Maybe an ‘i’m feeling lucky’ button that is just a random number generator and picks one of the pods with certain criteria (live for x number of months, uptime greater than x%)
The list is a bit unwieldy i guess. Maybe also shuffle the ‘closed’ ones to the bottom, and maybe the .dev or one major version number down are in a separate group (IE .3.x.x vs .4.x.x)
It seems the random picker always gives out poddery.com and we ran out of memory with sudden rush of active users https://poddery.com/posts/1522447. I think the random picker needs to give other pods a chance.
@camil we have not closed registrations yet. But we won’t be able handle all this sudden rush of users. If we hit another out of memory crash, we’ll have to close registrations.
@davidmorley any idea about quickly hotfixing or hiding the random pod button to not crash poddery?
@praveenarimbrathod imho it’s better to be safe and not let the pod die, ie close registrations, until podupti.me is fixed. If the pod goes unstable due to load you will lose more users than gain Hope David can push a fix asap!
It seems the random picker always gives out poddery.com
Oh, so it does. Weird. You could either make a PR in the PodUptime repo to fix this, if you have the coding knowledge; or close registrations temporarily and place a notice to this effect on the poddery landing page so that users know what’s going on.
… my only frustration is whilst i can throw ideas about … theres nothing like ‘rock solid code’ to throw at someone … ’ here … use it,lose it or rip it apart for spares’ - we will get there to 