How to get people to use Mastodon?
-
also rebrand it from Mastodon to Trunky.
- Trochaic meter is more addictive: 2 syllables with accent on the first. just like YOU-tube, FACE-book, GOO-gle, TWIT-ter, etc. it's part of why TEEN-age MU-tant NIN-ja TUR-tles and MIGH-ty MOR-phin POW-er RAN-gers was popular.
- Trunky is full of bright bouncy sounds that pop, the T and the K both hit nice, the R is exciting and powerful, the y ends it on a high timbre, it's cute.
- A mastodon is an extinct lumbering beast from the ice age which is the antithesis of anything trying to break out as a hot new service. But this would allow the service to keep its pachyderm branding.
- Change "favorite" to "trumpet" (as in trumpeting praise), again it's trochaic (TRUM-pet) and carries less cognitive LOAD than "favoriting" which feels heavy and committed. Just because you LIKE something doesn't mean it's your FAVORITE thing you know? this would decrease the friction of interaction (which is GOOD).
- keep tooting as the analogue for tweeting, rename boosting to re-tooting for brand consistency, and add a bookmarking function called "Remembering" (because ELEPHANTS NEVER FORGET, right? :D)
Also it should make a lil trumpet sound when you "trumpet" something
-
Quite frankly, I never understood the point of character limits to begin with. I mean, sure, don't let people post literal novels on your short-form social media platform, but it being a short-form social media platform already conditions people not to post novels...
Yeah. I see astro_ray in the thread has already replied to that point... It's ridiculous!
Quite frankly, I never understood the point of character limits
My understanding is, in the early days, you could send an SMS to Twitter to post, and that is the origin of character limits. Why it's still a thing? Haven't the slightest. Drives me fuckin batty. It's one reason I never joined Twitter in the first place. Why Mastodon implemented it? It seems a lot of derivatives want to be a "clone" of some existing service, presumably for user familiarity. In the process they don't seem to consider whether any individual "feature" is actually beneficial.
-
I think there's a few other issues with server selection
-
Longevity. How do you know that the server you are on will be there in 1, 5 or even 10 years? For larger servers like Mastodon.social you have a general idea that it will last as long as Masto itself, but others have very little guarantees on if you'll log in and find your entire feed gone. It only takes
-
That brings me to my next point: migration is currently inadequate. Migrating accounts only redirects your following/followers lists and some account settings. All of the posts, reposts and content uploaded are left on the old server and potentially wiped out if it's shut down. Professionals or anyone who wants a lasting online profile need to stick to big instances because they risk losing everything if their server can't continue. I also feel like there should also be an emergency "export all" button the admins can press, so the server will email all users a copy of their data in case of shutdown. That way users who can't export their data manually before the end date will have a copy of it. And this still doesn't solve the issue of small servers shutting down out of nowhere and wiping out every user's profile on there. If that happens to an average user they're probably just going quit Masto outright
-
Defederation is a good idea to keep bad servers isolated from the community and let servers dictate how open they want to be. But there's not a lot of indication of what servers have blocked/restricted the one you're signing up for, other than going to another server and seeing if the admins have manually typed up a list of that they blocked/restricted. There's also not a great way to see if the server you're looking at is read-only and any posts you make aren't being seen by users on the other server. Or that you're looking at a server that has since defederated and will no longer update posts. Also (afaik, there's not a ton of good explanations) but if you're newly connecting to a server it will only federate new posts going forward and not previous posts. Which again messes things up for people who want to use it as a consistent timeline. Dropping users into random small/medium servers risks preventing them from seeing their friends posts or cutting them off from their friends entirely
-
You mention data privacy as a risk of large servers, but how is it any better on small servers? You have no idea if the user you're handing your data over to is trustworthy or reliable or that the server they manage is secured. And how do you know that a large company won't come in and offer them money to sell the server, and suddenly all your data is in the hands of spammers? And direct posts are not private. Plenty of people on Twt used their real names/emails/pictures. It's not going to be viable to have every user create a burner email and never reveal any info, even in private messages without them deciding it's not worth it. Alternatively, they have to verify the trustworthiness of every admin on a potential server, despite them likely only having a username and posts to work off of
I think there are bigger issues than "just choose a server, they're all like email" that causes people to gravitate towards larger platforms. It's not just connectivity and uptime, there are logistical issues that will impact users if Masto gains more mainstream adoption. I haven't even touched on the threat of bad actors and spam which I don't feel like the network is ready for yet
Longevity.
100% percent! This needs to be taken into account.
Migration.
I definitely think account migration should be improved, but I wonder how feasible that is, in a technical sense... I don't know how that sort of data is structured at all.
Federation/Defederation
That's a good point. Once again, I really don't know of a solution to this. I'm not too familiar with how federation works, in a technical sense. Servers definitely should definitely make public by default their blocked servers and whatnot, though.
Privacy
Of course, it's impossible to make sure that every single server is safe. My point was that, if everyone is in the same server, then the risk of something going bad for any number of people increases, versus if everyone is in a bunch of different servers. I guess it's a balance between the trustworthiness of many people with control over a few and the trustworthiness of a few people with control over many. Maybe it's not so relevant. Most people don't care about privacy anyway, I was just trying to make a point about why decentralization should be valued in a practical sense.
Yeah, there's a lot of things that still need to be improved!
-
-
Quite frankly, I never understood the point of character limits
My understanding is, in the early days, you could send an SMS to Twitter to post, and that is the origin of character limits. Why it's still a thing? Haven't the slightest. Drives me fuckin batty. It's one reason I never joined Twitter in the first place. Why Mastodon implemented it? It seems a lot of derivatives want to be a "clone" of some existing service, presumably for user familiarity. In the process they don't seem to consider whether any individual "feature" is actually beneficial.
My understanding is, in the early days, you could send an SMS to Twitter to post, and that is the origin of character limits.
OH! Had no idea!
Well, maybe they'll remove it if the community pushes for it.
-
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?
On the auto-selector, I've said it before but join-fediverse needs to ask a few questions: Service? Location? Language? Hobbies? And then it spits out one or two recommendations, with an option to load more.
While I'd be fine with an auto-selector (as I help Admin feddit.uk), it would miss out on the variety of instances out there - books, games (video, tabletop, etc), franchises, etc that some people might be looking for.
So how about 2 big points: auto-selector (based on location) and answer a couple of questions.
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.
Lemmy is better for on-boarding on this front as they have the Local and All feeds from the start. Just having that front and centre (defaulting to Local, as you don't want to overwhelm them) would be a big help.
-
rename boosting to re-tootin
I would say reserve re-tootin for when quote post lands on mastodon
yes, that's what boosting is on mastodon. see how ineffectual their 'boosting' nomenclature is? that's why they should be renamed.
-
yes, that's what boosting is on mastodon. see how ineffectual their 'boosting' nomenclature is? that's why they should be renamed.
Ooh sorry, I thinking like Misskey. In the English translation, they use note and renote to replace tweet and re-tweet from Twitter era
-
Also it should make a lil trumpet sound when you "trumpet" something
I can’t get with that as a person who has sound off always
-
Quite frankly, I never understood the point of character limits
My understanding is, in the early days, you could send an SMS to Twitter to post, and that is the origin of character limits. Why it's still a thing? Haven't the slightest. Drives me fuckin batty. It's one reason I never joined Twitter in the first place. Why Mastodon implemented it? It seems a lot of derivatives want to be a "clone" of some existing service, presumably for user familiarity. In the process they don't seem to consider whether any individual "feature" is actually beneficial.
My understanding is, in the early days, you could send an SMS to Twitter to post, so the limitation was imposed by SMS and not necessarily Twitter.
No. The twitter were build with the limit in mind, in fact it is its whole spiel.
Why? It's not thar deep.
-
It games the attention span of viewers. You can read 3-4 articles before getting tired or going about your day, but you can guzzle infinite number of twits, because they are small, engaging and various
-
It not only games the viewers but posters too. Maybe you want to write an article, or blog post, but you know it's going to be long. So you better do it on the weekend. Or when you have more time. Which for many is never.
But writing a couple sentences? Easy! You can do it on a bus! You can do it on the toilet! And, if everyone is on the same level as you, you don't feel bad for keeping it short.
-
-
also rebrand it from Mastodon to Trunky.
- Trochaic meter is more addictive: 2 syllables with accent on the first. just like YOU-tube, FACE-book, GOO-gle, TWIT-ter, etc. it's part of why TEEN-age MU-tant NIN-ja TUR-tles and MIGH-ty MOR-phin POW-er RAN-gers was popular.
- Trunky is full of bright bouncy sounds that pop, the T and the K both hit nice, the R is exciting and powerful, the y ends it on a high timbre, it's cute.
- A mastodon is an extinct lumbering beast from the ice age which is the antithesis of anything trying to break out as a hot new service. But this would allow the service to keep its pachyderm branding.
- Change "favorite" to "trumpet" (as in trumpeting praise), again it's trochaic (TRUM-pet) and carries less cognitive LOAD than "favoriting" which feels heavy and committed. Just because you LIKE something doesn't mean it's your FAVORITE thing you know? this would decrease the friction of interaction (which is GOOD).
- keep tooting as the analogue for tweeting, rename boosting to re-tooting for brand consistency, and add a bookmarking function called "Remembering" (because ELEPHANTS NEVER FORGET, right? :D)
While I'm not entirely convinced that Trunky is the best choice of names, I do agree with your overall reasoning. Mastodon was always an awkward choice for a name and probably hurt adoption quite a bit, despite all the cute elephant cartoons people ended up making. Even Pleroma (an alternative server implementation compatible with ActivityPub) sounds cooler than Mastodon, despite also being three syllables long.
-
On the auto-selector, I've said it before but join-fediverse needs to ask a few questions: Service? Location? Language? Hobbies? And then it spits out one or two recommendations, with an option to load more.
While I'd be fine with an auto-selector (as I help Admin feddit.uk), it would miss out on the variety of instances out there - books, games (video, tabletop, etc), franchises, etc that some people might be looking for.
So how about 2 big points: auto-selector (based on location) and answer a couple of questions.
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.
Lemmy is better for on-boarding on this front as they have the Local and All feeds from the start. Just having that front and centre (defaulting to Local, as you don't want to overwhelm them) would be a big help.
Lemmy is better for on-boarding on this front as they have the Local and All feeds from the start. Just having that front and centre (defaulting to Local, as you don’t want to overwhelm them) would be a big help.
Yup, Lemmy does it really well.
So how about 2 big points: auto-selector (based on location) and answer a couple of questions.
I think that's totally fine. The big point is that the user shouldn't choose a server. Answer a few questions that can lead to a server? OK. But as soon as you make someone choose you might be reintroducing that confusion that seems to not be very popular with normies.
While I’d be fine with an auto-selector (as I help Admin feddit.uk), it would miss out on the variety of instances out there - books, games (video, tabletop, etc), franchises, etc that some people might be looking for.
Here, I'll point to this thread by Ted Curran: https://indieweb.social/@tedcurran/113946323075198755
Also, this reply thread https://lemm.ee/comment/18473212
Ted talks about how it might be best to simply send people to one instance (a sort of starter instance) and then encourage them to move to a different, more specific one. Other users complain that account migration is insufficient.
Maybe, after improving account migration, we should send users to a few semi-random starter instances that have agreed to a certain set of rules and adhere to a set of quality standards, but then encourage them to leave by migrating their account to an instance that better matches their interests.
From what I've gathered with the replies I've been getting, this might actually be the best solution, for now. Though, of course, it does include a significant improvement over the tech side, rather than relatively simple UI changes...
-
also rebrand it from Mastodon to Trunky.
- Trochaic meter is more addictive: 2 syllables with accent on the first. just like YOU-tube, FACE-book, GOO-gle, TWIT-ter, etc. it's part of why TEEN-age MU-tant NIN-ja TUR-tles and MIGH-ty MOR-phin POW-er RAN-gers was popular.
- Trunky is full of bright bouncy sounds that pop, the T and the K both hit nice, the R is exciting and powerful, the y ends it on a high timbre, it's cute.
- A mastodon is an extinct lumbering beast from the ice age which is the antithesis of anything trying to break out as a hot new service. But this would allow the service to keep its pachyderm branding.
- Change "favorite" to "trumpet" (as in trumpeting praise), again it's trochaic (TRUM-pet) and carries less cognitive LOAD than "favoriting" which feels heavy and committed. Just because you LIKE something doesn't mean it's your FAVORITE thing you know? this would decrease the friction of interaction (which is GOOD).
- keep tooting as the analogue for tweeting, rename boosting to re-tooting for brand consistency, and add a bookmarking function called "Remembering" (because ELEPHANTS NEVER FORGET, right? :D)
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!
-
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.
