How to get people to use Mastodon?
-
cross-posted from: 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 Problem^TM^
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 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.
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, actually does something similar for online play.
(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!
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?
The server selection problem goes away if people stop treating their hosting website as an after thought or dumb terminal. People really have to stop promoting web server software as if it's a platform, and start finding reasons to recommend actual websites to people.
Ain't nobody ever recommended phpBB to anyone who wasn't looking to host a forum.
-
The server selection problem goes away if people stop treating their hosting website as an after thought or dumb terminal. People really have to stop promoting web server software as if it's a platform, and start finding reasons to recommend actual websites to people.
Ain't nobody ever recommended phpBB to anyone who wasn't looking to host a forum.
Sure, but phpBB boards are separate entities, not parts of a whole... So that's not really a 1 to 1 comparison, IMO.
That being said, you're right. If people started sharing instances directly instead of just saying "Mastodon," this issue would be attenuated, at the very least.
The issue is that people want the social part of social media. If you share mastodon.social, people will think "Mastodon," but if you share indieweb.social people will be confused, and possible disinterested because they don't necessarily expect to be connected to the other "Mastodons." At the end of the day, you'll always have to say it's a "Mastodon Server," and as soon as that gets brought up, I'm afraid it might push people away before they even get a foot in.
Then again, that's kind of how Discord gets shared around, so maybe that's OK, IDK.
-
cross-posted from: 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 Problem^TM^
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 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.
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, actually does something similar for online play.
(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!
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?
The geolocalized choosing is a great idea! Sometimes you join based on communities as well, in that case a “join custom server” button could be added!
-
The geolocalized choosing is a great idea! Sometimes you join based on communities as well, in that case a “join custom server” button could be added!
a “join custom server” button could be added!
100%!
-
Trunky is full of bright bouncy sounds that pop
You've got to be taking the piss, right? This is serious software used by adults, not the colourful ride-on luggage for toddlers!
It’s not about it being for adults or for children. Mastodon is indeed a weird name, and people who have never heard of this platform with lots of things on their mind are more likely to dismiss it if it doesn’t immediately capture their attention / they don’t immediately know what it means.
While this naming “issue” is definitely on the bottom of priorities, I do find it worth mentioning, if only just for the sake of conversation. Plus, it’s kind of interesting to think about how something that, at first, doesn’t seem that important might influence the success of a product.
-
Sure, but phpBB boards are separate entities, not parts of a whole... So that's not really a 1 to 1 comparison, IMO.
That being said, you're right. If people started sharing instances directly instead of just saying "Mastodon," this issue would be attenuated, at the very least.
The issue is that people want the social part of social media. If you share mastodon.social, people will think "Mastodon," but if you share indieweb.social people will be confused, and possible disinterested because they don't necessarily expect to be connected to the other "Mastodons." At the end of the day, you'll always have to say it's a "Mastodon Server," and as soon as that gets brought up, I'm afraid it might push people away before they even get a foot in.
Then again, that's kind of how Discord gets shared around, so maybe that's OK, IDK.
Mastodon servers are separate entities, too. The fact that they communicate with each other doesn't change that, and the persistent desire that folks here have to imagine otherwise is a hurdle to adoption.
The mental model is of a central space that instances grant or bar access to, but that's simply not how the technology actually works. Too much effort has gone into trying to make ActivityPub-enabled websites look like something they're not (centralized social media), while totally ignoring what they are: small forums and microblogs that have optional access to other forums and microblogs.
Mastodon is web server software. "Mastodon" doesn't exist. It's an illusion. And the fact that everyone keeps trying to sell this illusion is exactly why there are all of these broken expectations and hurdles.
-
It’s not about it being for adults or for children. Mastodon is indeed a weird name, and people who have never heard of this platform with lots of things on their mind are more likely to dismiss it if it doesn’t immediately capture their attention / they don’t immediately know what it means.
While this naming “issue” is definitely on the bottom of priorities, I do find it worth mentioning, if only just for the sake of conversation. Plus, it’s kind of interesting to think about how something that, at first, doesn’t seem that important might influence the success of a product.
When I told my best friend about mastodon, it misimprinted on her brain in a flash as "walrus chat" and now she can't for the life of her remember its actual name.
-
cross-posted from: 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 Problem^TM^
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 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.
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, actually does something similar for online play.
(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!
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?
Oh man. I had forgotten Dungeon Crawl Stone Soup. I think I last played that in high school.
-
Mastodon servers are separate entities, too. The fact that they communicate with each other doesn't change that, and the persistent desire that folks here have to imagine otherwise is a hurdle to adoption.
The mental model is of a central space that instances grant or bar access to, but that's simply not how the technology actually works. Too much effort has gone into trying to make ActivityPub-enabled websites look like something they're not (centralized social media), while totally ignoring what they are: small forums and microblogs that have optional access to other forums and microblogs.
Mastodon is web server software. "Mastodon" doesn't exist. It's an illusion. And the fact that everyone keeps trying to sell this illusion is exactly why there are all of these broken expectations and hurdles.
My gut reaction was to reject what you said, but the more I think about it... You might have a point.
I don't know. I don't want to say too much and regret it, but you did give me plenty to think about. Thank you for your contribution to the discussion.
-
Oh man. I had forgotten Dungeon Crawl Stone Soup. I think I last played that in high school.
Ah ha, a fellow crawler! The game's still going and getting updated!
-
When I told my best friend about mastodon, it misimprinted on her brain in a flash as "walrus chat" and now she can't for the life of her remember its actual name.
It's the tusks, clearly.
-
There's actually an Android Mastodon client called Tusky, which I think sounds really nice.
I really know nothing about this stuff >///< thank you for your input!
I love Tusky, it is my app of choice for Mastodon
-
The geolocalized choosing is a great idea! Sometimes you join based on communities as well, in that case a “join custom server” button could be added!
There's a new server planned relatively locally to me and it's capitalising on the terrifying plunge into fascism that all the Big Socials now have as their badge of dishonour. People have never been "happy"
to be on Facebook but the local focus in a pretty leftie iinet city area is a good idea. If people know people irl on Fedi they will maybe have an easier time. -
My gut reaction was to reject what you said, but the more I think about it... You might have a point.
I don't know. I don't want to say too much and regret it, but you did give me plenty to think about. Thank you for your contribution to the discussion.
Maybe email is a better comparison for federated stuff than phpbb? You wouldn't tell someone to 'just get an email adress'. You'd recommend a specific email provider.
-
Maybe email is a better comparison for federated stuff than phpbb? You wouldn't tell someone to 'just get an email adress'. You'd recommend a specific email provider.
Yes, perhaps. But I suspect that still distracts from the fact that we're trying to sell an illusion with the fediverse, and I personally believe that that is a mistake. So many issues people voice about their experience here come from the design of everything emulating Big Social, and Big Social is centralized.
Aping the design language of centralized social media and then trying to get anyone other than enthusiasts on board is never going to work.
One of the ways we do this is by referring to "Mastodon" and "Lemmy" as if they are places you can go to, websites you can use. This is why I chose phpBB as my reference point. I've used WordPress and Joomla in the past, with less impact. We don't and have never spoken about phpBB as a singular location. You would respond to someone suggesting you "use phpBB" with, at the very least, a confused look. Or, if you didn't know what it is, you'd ask them "what is that?" and they'd tell you "forum software", revealing that their request of you was absurd. "Get an email address" is, at the very least, something that isn't a nonsensical request. Websites demand it of us all of the time.
-
As long as we're suggesting improvements for Masto:
- Remove character limits. This forces users to either not fully explain themselves or to break their post down into 5 different posts which then have to somehow be assembled by the reader. GoToSocial raises this to 5000 as the default. If someone posts >500, by all means, collapse the post.
- Stop fucking tagging literally anyone who was ever involved in a thread. I don't understand why this is a thing. It just makes every message super cluttered and makes me not want to get involved in any discussions for fear of having my notifications blown up with irrelevant BS at any time.
But, but, unlimited characters aren't purist, old-skool, original-gangsta microblogging! And understanding threaded conversations isn't purist, old-skool, original-gangsta microblogging either!
What do you want next, full HTML rendering support? Embedded in-line images? More than four options for polls?!
-
System shared this topic on
