Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new user experience #4870

Closed
nightpool opened this issue Sep 9, 2017 · 30 comments
Closed

new user experience #4870

nightpool opened this issue Sep 9, 2017 · 30 comments
Labels
new user experience Features for attracting and onboarding new users

Comments

@nightpool
Copy link
Member

nightpool commented Sep 9, 2017

We've been talking a lot (in different issues and on the network) about the experience of brand new users joining Mastodon, so I made this issue to summarize some of the current problems, and also the current solutions we have.

My hope is that a more holistic approach to this problem can give us a better understanding of what things are likely to help or not, and generate better ideas then just tackling individual parts in isolation.

On Mastodon, acquiring a new user requires four discrete steps.

  1. Finding an instance

    Or, more specifically, finding an instance that fits the individual user, has a local community they'd like, etc. Currently both https://joinmastodon.com and https://instances.social attempt to solve this problem, but they have a lot of steps for users to take, don't have a lot of ways to differentiate between different instances, and in general just leave people more confused then before.

  2. Signing up for an account

    This is classical onboarding. The current onboarding clickthrough is a good start, but it would be great if it was more interactive, and explained more parts of the software as you used it. For example, it would be great if it walked you through making your "first toot"—which could also serve as a way of helping others find you and interact with you, if it's appropriately tagged.

  3. Content discovery

    Once we get users on the site how do they find enough people to follow that they're going to experience the software fully and enjoy the experience? For example, tumblr asks you to select 5 or so "categories" of things you're interested in and auto-populates your timeline with interesting posts from those tags. Facebook does contact voodoo magic to find your exact clones and suggests those. Something inbetween those would probably be the best for us.

  4. ~~Retention~~

    Once (if?) users have had a good experience, how do we help them remember to continue to use the site, instead of just forgetting about it? Notifications emails definitely help here. We could probably also do a better job about suggesting mobile apps, and maybe doing digest emails if you're not very active.

anyway I don't think every suggestion here has to solve all 4 things at once, but it seems nice to get all of the current thinking about this stuff on the same page.

@nightpool
Copy link
Member Author

Two ideas I have currently:

  • a stumbleupon or web ring like site for finding instances. Some sort of frame-like interface where users are actually on the front page of instances, but with a little banner that says like "This is one instance out of many! This instance is run by BLANK, and you can read more about it or register below. Or click this button to view another random instance!"

    the benefits to this is that it reduces the friction between finding a server and registering for it (steps 1+2) and it gives confused users an easy-out (just sign up!) while not obscuring the process for people who want more choice (the stumbleupon interface is pretty good at this iirc)

  • for 3, I think a dead-simple "follow the local admins" of your instance would go a long way towards avoiding an empty timeline. it's how nearly every social network got it's start (tumblr, facebook, and myspace have all had versions of this features) and it also works to strengthen local instance culture.

some thoughts on what I think won't work.

  • I don't think triadic closures do a good job of addressing Add "followers" and "following" public pages #3. Starting from a brand new user, they won't have followed any or many people, and any recommendations of people to follow based on that metric will be—at best—very inaccurate, since they haven't had a lot of time to curate a timeline they enjoy. This isn't that I think triadic closures are a bad thing—personally, I would love to have them for my own account—but I just don't think they're a significant step forward for the new user experience.

@nightpool nightpool added the new user experience Features for attracting and onboarding new users label Sep 9, 2017
@beatrix-bitrot
Copy link
Contributor

automatically following the local admin also has the side effect that the admin will get notified and can maybe help you settle in :3

@ghost
Copy link

ghost commented Sep 11, 2017

I believe that automatically following some remote users (not only local admins) is good for federal culture. (Sorry to duplicate comment of #4871 (comment))

@nightpool
Copy link
Member Author

Who was working on the web ring thing? @beatrix-bitrot? i was thinking about that today and wanted to poke it

@beatrix-bitrot
Copy link
Contributor

mmmmmmm it was not me... maybe cass or zyabin?

@kerim
Copy link

kerim commented Oct 1, 2017

In my mind the biggest bottleneck for new users (and a continuing headache for existing users) is the whole "remote follow" thing. I have been advocating for everyone to be able to be able to set a canonical identity for themselves which they can use when joining other Mastodon instances. This way if I am on Mastodon.xyz and I join scholar.social, people who follow me will be following my canonical ID not some new one I created just to join that instance. And when I follow them back, I will be following from my canonical ID as well. It will take a lot of the confusion out of Mastodon, and a lot of the headaches of having decentralized identities. Of course, someone who wants to have multiple identities that aren't linked can still do so, but I strongly believe that this feature should be the default behavior.

@nightpool
Copy link
Member Author

if I am on Mastodon.xyz and I join scholar.social, people who follow me will be following my canonical ID

@kerim wouldn't that defeat the purpose of creating a second account? or am I misunderstanding you?

@nightpool
Copy link
Member Author

@beatrix-bitrot might have been @KitRedgrave?

@kerim
Copy link

kerim commented Oct 1, 2017

@nightpool There are many reasons to have multiple accounts. One is to interact with people in a different community, another is to have separation between one's own identities (for privacy or to sort one's social world). But why should it be assumed that these two use cases always go hand-in-hand? It seems to me much more likely (and this is the case of most people I have spoken to) that people see different instances as more akin to FB Groups that they would like to join with the same identity rather than having entirely fragmented social identities they have to do extra work to manage. (Who am I following with each identity? Which one do I have to use to message that person? etc.)

@kerim
Copy link

kerim commented Oct 1, 2017

It's great that Mastodon gives users this level of control, but if you are talking about onboarding new users, this is the biggest issue that has come up when I try to explain how it works or when people are trying out the site for the first time. If there is one thing I think could really improve the experience for new users, it would be reducing the initial confusion caused by signing up to more than one instance when you are first testing out the platform.

@kerim
Copy link

kerim commented Oct 1, 2017

To give more detail from my own experience. As an academic I did not know about scholar.social when I first joined. By the time I found out about it, I had already widely advertised and created a lot of followers on my mastodon.xyz account. I regret not having started on scholar.social, but I didn't want to have to do the work of re-building my network all over again. I found some apps that try to sync follows across accounts, but they didn't work well for me. And to be honest, the main reason I wanted to be on scholar.social was just to connect with other academics with my existing account, not to have another account.

@nightpool
Copy link
Member Author

@kerim When onboarding users i've honestly never found the "following other people" aspect difficult to explain. You see somebody, you follow them. Easy as that. If you're trying to import an existing social circle and have two people find each other, it gets more complicated. however, that's also (pretty) easy: just type their name in to the search bar.

To help me understand, why did you want an account on scholar.social to connect with other academics? The only thing having an account on that instance gives you is being part of that instances culture. Having the same admin, the same local timeline, the same federated timeline. At the same time though, that's not something you can do half-way. You're either part of the instance or you're not, and it's a two-way relationship. The bottom line is that if instances were "joinable" in the way you described, they'd stop being special. you'd be following everybody, from everywhere, there wouldn't be anything tying people together, and there wouldn't be any shared context to create a culture in. As much as I hate many of the arguments people use the term "context collapse" to support, what you're describing truly is an erosion of the boundaries that make instances distinct.

(as a side note—it makes conversations a little easier for everybody if you take some time to write the full post you intend, instead of posting three times)


Your second post, I think, is the most revealing. A core problem people run into is "how do I find which instance to join before I join the network?" That is definitely a huge problem, and I don't mean to make light of it. That's a problem we've discussed on this issue tracker before and it was the first topic tackled by SocialCG. But I think the solution you propose is too broad, and perhaps harmful to mastodon's current culture.

It's hard to imagine a truly perfect solution to the problem, of course. You can never know which communities you're going to like before joining them—as transparent as they could possibly be, human social connections grow best organically, not artificially. You can't truly join a community without at least having been adjacent to it, and the best way to be adjacent to a mastodon community is to already be part of the network. And things change over time too, as well. That's why I think the ability to migrate from one instance to the other, retaining your followers, is a better solution—it's the smallest possible change that makes a meaningful impact on the problem and targets the root cause specifically.

@kerim
Copy link

kerim commented Oct 2, 2017

At the same time though, that's not something you can do half-way. You're either part of the instance or you're not, and it's a two-way relationship. The bottom line is that if instances were "joinable" in the way you described, they'd stop being special. you'd be following everybody, from everywhere, there wouldn't be anything tying people together, and there wouldn't be any shared context to create a culture in. As much as I hate many of the arguments people use the term "context collapse" to support, what you're describing truly is an erosion of the boundaries that make instances distinct.

I understand what you are saying here but I see two things wrong with it.

First, it does not seem to me that joining an instance with a canonical identity need negate any of those things. I sign up to all kinds of services with my gmail address, even Facebook but it doesn't stop those services from having their own terms of service and rules and culture.

Secondly, to rephrase what you are saying it seems you want to create friction between instances so it isn't so easy to move or jump between them. While I understand the motivation for creating such friction, it seems to me somewhat disingenuous to then talk about reducing that friction in other ways since your goal is essentially to maintain some kind of friction. For this reason I don't see it as an attempt to target the root cause "specifically," but rather as a way of avoiding dealing with contradictory goals rather than tackling them head on.

@fsnk
Copy link

fsnk commented Oct 12, 2017

I have some thoughts on #1.

What if there was a way for admins to tell Join Mastodon a little about their instance, and then Join Mastodon could play the role of the Sorting Hat (obligatory Harry Potter reference) and suggest a few instances to new users based on their preferences?

Similar to instances.social but with the user's interests taken into account, not just TOS rules, and integrated into the Join Mastodon site so it feels like a unified experience. It would be a lot less overwhelming than just a long list of server names, or clicking randomly through a web ring of hundreds of instances.

I kind of imagine it working like this:

On the Mastodon instances, there's a place where admins can enable listing in Join Mastodon. (Because obviously there's no reason to direct new users to single user instances or instances with closed registration, or who just don't want to be listed.)

Then admins can select from a limited number (say five) of predefined categories that represent their community. Things like: general interest, science, technology, gaming, music, art, books, politics, religion, LGBTQ+, social justice, free speech, active moderation, etc.

That kind of thing.

And also have language and region choices. (Might as well kill that bird too.)

This information gets sent to Join Mastodon.

Then on join Mastodon, the first step for users is "Choose your instance!" where they can select their interests, and any language or region preferences. This could be as simple as just selecting checkboxes or something fun and interactive like a short quiz. (The first gives you speed, but I think the second helps people feel more invested in the community they choose to join if it's done well.)

Then using a magical sorting algorithm, Join Mastodon will suggest 3 instances that are a good fit.

I imagine this as cards displaying the "About" info of the instances and when the user clicks on one it takes them to the registration page for that instance.

There should probably also be an "Instance me!" option, for people who don't care and don't want to click checkboxes or do some kind of quiz.

I think it would also be important to keep the categories limited to a couple dozen and keep them broad. Too many niche categories and it gets overwhelming for the user, and also insanely unmatchably specific. Like you don't want to deal with trying to match people to servers on the basis that they're into Star Trek Discovery, pet hamsters, Windows 95, and their favorite colour is green. You only need to hit the side of the barn here, not the bull's eye.

I also think in a matching scheme, there should be some kind of fairness control so that when it comes to recommending instances, for equally good matches, there's a fair rotation in which instances are suggested. Obviously better match to user interests should be prioritized, but if there's a situation where there's an equally good match and one instance has been suggested 100 times and another 10 times, the one that's been suggested less should get priority.

@bbbradsmith
Copy link

I just began using Mastodon today, and I found one thing in particular very confusing:

I joined mastodon.social and was given 10 default follows on my account. After figuring out how to delete these follows, however, my expectation is that my Home view should just empty out. Unfollowing a user should remove their toots from my timeline, shouldn't it?

As far as I can tell, no new toots from the users I unfollowed are still appearing past that point in time in my timeline, but I can't understand why these ones from when I had just signed up are still there. When I follow someone new, their old toots appear in the past in the timeline, why does unfollowing someone not make their toots disappear in the same way?

Anyhow, I'm not even sure I understand the behaviour correctly yet, but this confused my for about an hour after signing up. I couldn't understand what "Home" was and how it was supposed to be different from the "Local" and "Federated" feeds (both of which are kind of useless at mastodon.social, in my view), and I was searching for a guide on how to get "the feed that is just people I'm following", until I eventually came to a slow realization that this was "Home" all along.

Anyhow, I don't know if that's a feature request or what but "unfollowing someone should remove their toots from my Home timeline" would have helped me a lot in trying to understand what Home actually does. When you have very few follows that timeline is probably not updating very quickly-- makes it hard to understand what you're doing!

@Gargron
Copy link
Member

Gargron commented Oct 13, 2017

After figuring out how to delete these follows, however, my expectation is that my Home view should just empty out. Unfollowing a user should remove their toots from my timeline, shouldn't it?

Actually, unfollow does that, but not instantly. But the web client could pretend to do it, if that would help signalling the functionality.

@bbbradsmith
Copy link

Well, by "not instantly" it's 9 hours later and my Home timeline doesn't appear to have changed. So, I'm not complaining that maybe unfollows are de-prioritized and go into a backlog for a while, but just trying to point out that the lack of feedback between trying to figure out what "Home" is and how following/unfollowing affects it was definitely a learning problem for me. (It took me about an hour to understand, and I was kind of on the verge of just giving up entirely on Mastodon.)

So, yes if the client could do some kind of local filtering to artificially give more immediate feedback from unfollows, that would probably help.

The other thing that would have helped is if the getting started document had a prominent heading and paragraph specifically about the home feed. To me it's the most important thing here, and it really doesn't get a description of its own in that document. Looking at it now carefully, I can see that it at least mentions what it does in passing, but I definitely wasn't able to piece that together when initially trying to figure out how to use Mastadon. (By comparison, there are clear sections describing the "local" and "federated" feeds, neither of which is something I'd really want to use at all, at least not in any large instance. The home feed should probably have its own section at least as prominent as those.)

@fsnk
Copy link

fsnk commented Nov 3, 2017

TL;DR
My suggestion is: onboard people to general purpose, stable instances that can take the user load and postpone instance selection until after people are familiar with Mastodon and the fediverse and understand what an instance is and what they're looking for.

I've been thinking about/discussing this more, and my revised opinion is any "join" process that requires a user to select an instance without having any practical experience using Mastodon and what instance selection is about creates unnecessary mental labour which is a barrier to uptake.

The more complicated clicking "join" is, the more people drop out through the process. I know; I could be the mascot for click fatigue. Typically, I bail on any "join" process more complicated than choosing a username and a password.

My new suggestion is a "Sign up" button on a centralized "Join Mastodon" site that takes a new user to the registration page of an instance chosen quasi randomly (weighting the user's location and language) from a list that meets a minimal set of criteria:

  • general interest,
  • has a TOS that requires compliance with local law,
  • has existed for at least X amount of time,
  • maintains a certain level of uptime,
  • and does not suspend federation except in cases of broken or malicious servers where federation has a detrimental impact on the local server's performance or network connectivity.

Ideally it could be mostly automated, with a setting the admin interface that can be enabled to ping the centralized "join" location for inclusion, and send data like uptime, region, language, and federation status.

This would also allow the instances who don't want to onboard "normies" to not participate. I've noticed there's an attitude of exclusivity in some opinions on how to get more people using Mastodon: that an effort should be made to attract the right kind of people (and keep out the undesirables). That's fine for individual instances, but my opinion is that a collective onboarding solution should be geared to create the lowest possible barrier to entry in the fediverse.

I also think the inclusion of federation status as a criteria is super important. Right now we tell people "It's like email! You can talk to your friends no matter what server they join!" but that's not true.

People can talk to their friends only as long as their friends are on an instance that federates with their instance -and that can change at the drop of a hat (or an admin spat). So right now we either have to lie to people or go into an eye-glazing explanation of federation.

@nightpool
Copy link
Member Author

and does not suspend federation except in cases of broken or malicious servers where federation has a detrimental impact on the local server's performance or network connectivity.

no instance that has this lax of a moderation policy will ever be promoted by the mastodon project.


I'm wary of any solution that prioritizes centralization over teaching and showing the user decentralization in practice. I understand that this places a barrier to adoption but i'm just not sure whether the cultural costs of promoting centralization are worth it in practice. I dunno, maybe setting up a "tracker" instance and allowing mastodon-the-software to opt-in to it might be better then the current adhoc situation. I'll have to think on it more before I'm ready to have a final opinion.

@fsnk
Copy link

fsnk commented Nov 4, 2017

@nightpool
Then information about which instances are blocked by a given instance needs to be prominent in whatever selection list people are being offered. Users absolutely need that to make an informed selection.

@deutrino
Copy link

@fsnk there is discussion of this also in #3874

@deutrino
Copy link

deutrino commented Jun 25, 2018

I'm coming back to this issue to sum up some ideas I had.

It's cool people and the cool stuff they post which makes Mastodon sticky. Not celebs, but people with common interests who post a high density of interesting stuff. However, it seems to me that casual new users don't expend much effort seeking out people to follow before they wander off, rarely to return. So, how can we get interesting content in front of casual new users right away?

Elsewhere in the linked thread, there were suggestions for a streamlined instance chooser on joinmastodon.org which seamlessly transitions from choosing an instance into registration on the chosen instance, all in one UI. I make my suggestions here in that context.

▣ Suggest topical instances based on a prospective user's interests

In the instance chooser, I propose that instances which are strongly topical get a human-curated field of topic keywords (e.g. "books", "literature"). During the instance selection process, after any other filtering has been done, we aggregate the topic keywords from the filtered subset. We present the user a multiselect of those, and then highlight instances with matching topic keywords in the instance chooser.

By highlighting rather than filtering, we offer the user the option to make an affirmative choice: I want to join this instance in part because it matches my interests. I think that sets a positive tone for the interaction, as well as some expectations on the user's part. Overall, I believe new users will be more likely to land on an instance where they will meet people and see things they like. Thus, this idea addresses Finding an Instance and Retention.

There is an important caveat here. First, please note that this idea strongly echoes @fsnk in #4870 (comment) although I differ with them a bit. I believe only strongly topical instances should get topic keywords. This will require human curation of the list, which I see as a good thing. In any event, in this way we avoid violating user expectations: I argue that the "I thought I was getting an anime-heavy instance but instead the local timeline is 80% linux development" failure mode is actually worse than not implementing this feature at all. General instances and those that merely have a lean toward certain topics are, in my opinion, not a good fit for this feature.

There will inevitably arise debate over human-curated instance lists on joinmastodon.org. My views on that matter are thus: joinmastodon.org is a centralized point of contact whether we like it or not; running joinmastodon.org has always involved editorial decision-making; thus I am comfortable with and would encourage more human curation of the instances which joinmastodon.org recommends.

▣ Improve default follows and offer suggested content based on hashtags

After getting people to sign up at all, retention is by far the second-biggest problem I've experienced in suggesting that people try Mastodon.

I believe we can use hashtags to improve the quality of automatic follows, and to suggest content to new users with a low-activity home timeline. Proposal: maintain a list (algorithmic or curated) of very broadly used and long-lived hashtags (eg "linux" and "cats" and "photography"). Present the user with a multiselect of these during onboarding. Then:

  • Select users active in these hashtags as default follows for new users
  • Occasionally put recent toots from the specified hashtags in the timeline of users who haven't followed more than x users, haven't seen a toot in more than z minutes, etc.

I believe these hashtag-based features would address Content Discovery and thus Retention while largely avoiding the concerns that arose with trending hashtags:

  • Since hashtags are broad and general, and are used only to suggest follows and content to a (typically) steady flow of new users, you don't have a problem of thundering herds descending on a hashtag
  • Also because the tags are very general, I don't foresee a problem with social fallout from driving too many eyeballs to a topic
  • Because this is only used for suggesting follows and content for new users, and because (I propose) hashtags are either human-curated, or algorithmically selected to have been in very common use for a very long time, these features are unlikely to be a vector for harassment
  • Finally, the "don't index me for search" button in the privacy settings should opt users out of appearing in these hashtag-related features, thus eliminating any privacy concerns I can see

None of these features is particularly simple, but people in the thread I linked at the top were talking about a "wow" factor, or something that stands out, in driving new user engagement. A more personalized onboarding process that uses simple heuristics to increase the chance new users will meet cool people and see cool content is a big step toward parity with other platforms... I think we just need to hang onto the new users long enough for the true asset here - the userbase - to shine. These features can help.

Edit: if you want to go full human-curated and implement both the feature to highlight topical instances in the chooser, and the features to promote users and content to noobs based on topical hashtags, they could both be handled by a single multiselect during the sign-up flow.

  1. Develop a relatively short list of broad topic keywords (eg "animals", "tech", "art", "lgbt")
  2. Associate a list of related broad/general hashtags with each keyword
  3. The "please click some interests" multiselect for the new user would present only the topic keywords
  4. Selected keywords would be used to highlight topical instances in the chooser as proposed above
  5. Hashtags associated with selected keywords would be used for the hashtag-driven features as proposed above

This would require human curation as follows:

  • creating and maintaining a controlled vocabulary of topic keywords (presumably, at some point, localized to as many languages as possible)
  • creating and maintaining a (eventually localized per language) list of associated hashtags per topical keyword

I suspect that by putting human insight behind these features, they'd work well enough to greatly improve the new user experience in terms of quickly seeing interesting content, and thus help user retention. A fair amount of this could be done algorithmically but the coding and tuning would take a lot longer than making a good initial stab at human curated lists, and the result be less predictable.

@deutrino
Copy link

deutrino commented Jun 25, 2018

I also wanted to comment a bit more on streamlining the process of Finding an Instance and Signing Up For An Account.

Somebody on masto mentioned making the instance selection -> registration process appear essentially seamless from joinmastodon.org. There have been some similar ideas in this thread here, and concerns about rules/CoC/instance culture, etc.

A seamless instance chooser -> signup feature would be great. Things that are less great:

  • Dropping users who want heavy moderation on less moderated instances
  • Dropping users who want lighter moderation on heavily moderated instances
  • Making casual new users have to do an entire research project into the history and current cyberpolitics of the Fediverse to pick an instance or moderation style

In my above comment I argue for some human curation of the instance list on joinmastodon.org, and some additional metadata therein. Now I argue for more.

  • Instances to be suggested by joinmastodon.org are flagged in the master list as heavy moderation and non-heavy moderation
  • As part of the instance chooser workflow, the user should be presented with a multiselect for heavy, and non-heavy moderation, where the explanation for each is a maximum of one sentence long. The user can select both options, but must select at least one, to continue. This action filters the set of instances the chooser will offer.

The key here is to set a dividing line between heavy moderation and non-heavy moderation instances such that the general paradigm one is selecting for is adequately expressed in one sentence. Add all the little "read more" links you like, but most new users probably do not care to process more than this amount of information. At the same time, it's not a good idea to remove this choice altogether: dropping new users on random instances will result in mismatches between user temperament and instance moderation style. I think this idea represents a good compromise between reducing friction versus keeping choices we really do want the user to make as part of the signup process.

@VictoriaElliottContentDesign

Bumping this issue as a new user - I signed up specifically to GitHub to add support to this issue being addressed.

As a Senior Content Designer I’m hearing discussed a lot in UX/Content Design circles, both on Twitter and Mastodon.

I wrote a blog piece to help guide people through the sign up process, and there are other sites which have written walkthroughs, but any guidance such as this still places the burden on the newbie user to make an upfront investment of energy and time to read and understand it. This is therefore off-putting to potential new users.

It’s a general principle of UX that one should be able to interact with any form of digital content without needing to go elsewhere to understand it first.

I completely get this isn’t a straightforward thing to design, especially as the notion of servers is foreign to many new users. I’m also aware that resource is likely to be especially tight at this time. I wonder whether some form of UX hackathon might be worth doing to look into how best resolve this issue?

@kerim
Copy link

kerim commented Nov 15, 2022

I see that an issue I contributed to in 2017 never got addressed. Now I'm seen dozens of complaints about exactly this every issue every day. Too bad nobody thought it worth fixing. I've tried to help by writing guides and encouraging people to not worry about it so much, but the simple truth is that it creates unnecessary friction for new users. And to be honest, the way this works for experienced users is far from ideal. For instance, following someone on a remote takes far too many clicks (someone even wrote a Firefox extension to simplify this process). I appreciate what Mastodon is trying to do, but am frustrated because so many people I would like to see on it are put off by things that seem like they could be fixed if it was a priority to do so.

@brendanjones
Copy link

I had an idea recently about one way to make choosing a server easier, I'll add it below. It does of course require Gargron to want to set something like this up:

Mastodon GmbH should start a server that's just for people signing up who don't know about servers yet. People can stay on there for a limited time (say, a month or two), after which their profile/data could be removed if they haven't moved to another server.

This means people willing to put the time into picking a server can do so, while those who don't are given a server instead of dropping off and not coming back.

So when people click 'Create account' on https://joinmastodon.org/, instead of going straight tohttps://joinmastodon.org/servers they're sent to an interim page. It'll say "Join a server to get started" and offer the options:
"Choose now" [sends them to https://joinmastodon.org/servers] OR "Choose later (we'll add you to the Mastodon server for starters. You'll have a month to look around and choose a server you like.)" [sends them to the Mastodon GmbH server)

Of course for this to be a decent user experience:

  1. Switching servers (and moving all your data and follows/followers) needs to be easier, and
  2. You need to be able to bring your post history with you when switching servers. Support Post Migration #12423

Yes, those are some big upgrades, but they need to happen anyway.

@AndreasDavour
Copy link

As an alternative to directing all new users to one default instance, this suggestion is a step in the right direction.
Also, if federation is a killer feature, it has to be pushed forward. I've never tried switching servers, but it's definitely an area that could be a differentiator.

@mjankowski
Copy link
Contributor

Doing some old issue triage and came across this one ... lots of good ideas here.

I'm not sure how to evaluate this one ... this is so broad it will never be "done" (We should always be improving NUE).

That said - I also think that in the ~7 years since this issue we have improved every single area originally mentioned.

Curious from participants - what are the most still-pressing still-hard-to-do things that might actually have viable short term do-able suggestions available?

To project team - any ideas in here that strike you as viable and that would be reviewed/merged if anyone worked on them?

@trwnh
Copy link
Member

trwnh commented Nov 26, 2024

i’m inclined to say we should close this issue and split it out into actionable focused suggestions where appropriate. we do have a “new user experience” label which fulfills the same role as this issue, no?

@mjankowski
Copy link
Contributor

Excellent idea.

Closing under the umbrella of "this is so large we cannot possibly ever solve it" -- but yes, by all means if there are narrower ideas in here please turn them into PRs/issues using that labeling schedule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new user experience Features for attracting and onboarding new users
Projects
None yet
Development

No branches or pull requests