cross-posted from: https://lemm.ee/post/56496251 [https://lemm.ee/post/56496251] > I’d like to add to suggest a couple of things regarding Mastodon and user onboarding/retention. > > # The Server Selection ProblemTM > The single biggest problem with Mastodon adoption is the fact people see talk about a server and give up. As such, servers need to be removed from the conversation and onboarding process. A server still needs to be selected for a new user, however, which raises the question: How should we select a server for a new user? > > The obvious solution is to simply direct users to mastodon.social, which is actually what Mastodon already does [joinmastodon.org] to a certain extent. The issue with this is that the Fediverse is meant to be decentralized. As such, it’s counterproductive to funnel people towards a single server. This causes maintenance bottlenecks and privacy/data-protection concerns. > > Mastodon's landing page. [https://i.postimg.cc/d0MQyVNT/image.png] > > As such, there needs to be some sort of method that ranks servers based on a few factors in order to select the optimal server for any given user, while keeping the decentralized nature of the Fediverse in mind. > > ## Why any server? > First, it’s important to answer the question of why would any given user pick any given server. > > Generally speaking, the server isn’t a big deal, as in, any server allows users to interact with the whole of the network in its full capacity. > > All servers are Mastodon, after all. > > However, there are differences. The most significant ones are, I’d say: location, uptime, and language. > > A user benefits from being registered to a server that’s geographically close to them, as that leads to a better connection. Additionally, servers with high uptime and stability are preferred, as users may have different times they use the server and nobody likes to try and access a server and see that it’s down for any number of reasons. Finally, users need to be able to understand the language the server is in (obviously). > > I believe these three factors should be at the forefront of the decision-making process for deciding what server to be suggested to any given user on sign-up. > > ## Auto-selector > With that, comes the solution: a server auto-selector. A game I play, DCSS [https://crawl.develz.org/], actually does something similar for online play. > > DCSS server selection [https://i.postimg.cc/wBq3NRPb/image.png] > (I have my location turned off and there are very few servers, as you can see, so listing them is trivial.) > > This isn’t exactly a novel scientific breakthrough, but I think it’s a significant notion for helping the onboarding process for new Mastodon users. > > A server auto-selector should filter servers to suggest by following these steps: > - Detect the user’s system language. > - Detect the user’s location. > - Calculate the server’s uptime score. > - Pseudo-rank user-count. > > I believe the first two points are self-explanatory. Being that Mastodon (and the Fediverse, in general) stands firmly against data-harvesting, location data should probably not be mandatorily collected. It should be easy to either ask the user for some vague information or simply allow them to skip this step entirely, even if it might affect the user experience. Additionally, there’s the issue that many servers don’t make it known where they’re hosted. Ideally, this could change to facilitate server selection for the users, but there’s always the point that, if a server doesn’t say where it’s hosted, it gets pulled down by the algorithm, which in turn encourages divulging that kind of information; this might a problem solved by the solution, if you get my meaning. > > What I mean by uptime score is simply an evaluation of the server’s uptime history. For example, it’s not good policy to direct users towards servers that are often unavailable, it might be disadvantageous to direct users to servers with too-frequent downtime for maintenance, and so on. As such, the server auto-selector should calculate a sort of “score” for any server that fits the first two points. I can’t say how this should be calculated, exactly, but I’m sure some computer-knowers out there can come up with a less-than-terrible methodology for this. > > The last point is something that I think should be taken into account as well, regarding the user-count of the servers. As I mentioned, we can’t funnel users towards a single server, but another issue is that we should actually encourage user dispersion over many servers. The outlined method might already do this to a sufficient extent, but I suggest doing some sort of randomization of filtered servers based on user-count. I think it’s wrong to simply plug a new user into the least-populated server around, but I do think that over-populated servers, in a relative sense, should be discouraged by the server-selector. > > Worst case scenario, a random server that passes the uptime score point can be selected for any new user. > > ## The onboarding experience > Basically, this should be as simple as possible. The more questions need to be answered, the worse. > > I think a simple “Join Mastodon” button is the best. Just a big blue button in the middle of the homepage. > > Server selection should start as soon as the new user accesses the joinmastodon website, and clicking the button simply redirects the user to the sign-up process for that server. > > I believe this approach would increase adoption of Mastodon by streamlining the server selection process, as well as help the continuous decentralization of the Fediverse. > > # The Feed Problem > Another significant issue with Mastodon is the feed and community/discovery aspects. > > Creating a new Mastodon account yields… Nothing. An empty feed! > > New account, empty feed. [https://i.postimg.cc/JzQ9ssjn/image.png] > > This is absolutely terrible and ruins user retention. I’ve had several people tell me that this first-experience emptiness completely turned them off from Mastodon. It’s not intuitive, and it needs to be corrected. > > ## A simple solution > > Mastodon does have feeds, but they’re all tucked away in the Explore and Live Feeds tabs. > > I think the single biggest change that Mastodon can make, as far as this goes, is to shift the Explore->Posts feed to the Home tab. Just do it like Twitter or Bluesky, make the discovery feed the first thing a new user encounters. > > That, by itself, should make a difference in terms of user retention. > > *** > > Maybe I’m delusional and severely underestimating how doable this is, but I really believe Mastodon needs to change the way it deals with new users if we want it to actually grow into a strong social media, keyword social (it needs people). > > Thoughts?