There have been various posts here in the last days describing how difficult it is for new people to start using Lemmy. In fact they are absolutely correct, it is much easier to get started on Reddit. But what many forget is that Lemmy is not a corporation employing dozens of full-time designers, running A/B-tests and so on. Lemmy is an open source project run by volunteers, with only @dessalines and me working on it full-time. Neither of us is a particularly good designer, and our time is mainly spent working on the backend (database, federation, api), and preparing the upcoming 1.0 release.
If you see anything on join-lemmy.org or in the Lemmy UI itself that could be improved, the best option is to make that improvement yourself. Both of them use standard web technologies (nodejs, tailwindcss, inferno etc). The userbase here is quite technical so there are many of you able to contribute. We rarely reject any pull requests as long as they make a real improvement. Though it usually requires a little back and forth to review the changes and then address the review comments.
You can find the source code for join-lemmy.org here and follow development instructions in the readme. Regarding the default Lemmy UI go here and read the documentation with development instructions. If you are not a developer you can still help, for example by improving the documentation. Additionally you can make changes to the texts for joinlemmy and lemmy-ui.
All this said, there have also been some suggestions to make onboarding easier by directing new users to a hardcoded default instance. This may sound like a good idea at first but won’t work well in practice. Running such an instance would take significant time for administration and moderation, but we maintainers are already too busy. Besides it would be impossible to reach an agreement who this default instance should federate with or how exactly it should be moderated. So if you want to get nontechnical users to Lemmy, the solution is to link them directly to a specific instance based on their interests.
In terms of the “default instance” suggestion, I have an interesting hybrid suggestion. What about having an “easy on-ramp” instance where you get registered for one month with a hard-exit (auto-migrate to other instance, perhaps using some kind of federated-auth/token system for the migration, and forced password-setup on first use of the new instance). At any point during on-ramp the user could configure destination-instance from a list in the settings (or configure auto-export for manual import to any other “auto-migrate-unsupported” instance), with optional early-migration if the user has decided before the end of the month. Optionally a recommendation engine could iteratively curate a list of suggested instances based on usage during on-ramp (admins of those instances could provide - limited number of - tags of their choosing for the engine to use for matching). That part could be opt-in because probably a lot of users would find it creepy. The UX would need to be very user-friendly “pointy clicky” because that would be the overwhelming target demographic of such an instance. I think “on-boarding and educating” is better than “gatekeeping” (which feels like the “if you need to ask the price you can’t afford it” shopping trope). A nice side-effect is it already painlessly introduces users to the killer-feature “easy migration” between instances due to data-portability.
That would take a significant amount of work to implement, and we dont have the resources for it. But all the code is open source, so youre welcome to give it a try yourself.