The Seven Deadly UX Sins of the Fediverse Web Experience (To Fix)
-
This post did not contain any content.
-
This post did not contain any content.
like fediverse isn’t an open source project that someone could actually contribute work to fix instead of write an article for internet points
-
like fediverse isn’t an open source project that someone could actually contribute work to fix instead of write an article for internet points
I think starting a discussion about these kinds of issues is important.
It’s an area where all of OSS has issues. It comes with projects being developed by individuals their own requirements.
The challenge comes when “we” (the tech community) want to see such projects expand… Into the non-tech community. If that’s to happen with any project, the requirements of that community need to be considered.
And they’re a fickle bunch that are unwilling to learn how stuff works.
-
This post did not contain any content.
One of the reason, why /kbin has achieved the success (so large, that eventually took it down…) has been it solving much of these UX sins:
- This was only by chance, but as /kbin was ~not already~ never ready for third-party hosting, there was only one non-Polish speaking instance of /kbin (flagship kbin.social). This is another reason, why registration numbers made briefly kbin.social’s MAU greater, than that of entire Lemmy software!
- But what about decentralisation? As I probably have argued when /kbin yet existed, the Threadiverse could as well consist only of lemmy.ml, piefed.social and a Mbin instance (or the Feediverse might by only mastodon.social, misskey.io, flipboard.com, and Pleroma/Akkoma instance) and still be decentralised. Several carbon-copy instances are the simplest way to make an interoperating network - but not the only one!
-
/kbin of course is a Threadiverse app and evades this sin by definition. A Lemmy user never has to browse an empty “timeline”
-
This is a cursed solution for this sin, but with so great scale of flagship instance (and no alternatives) much of the federation work has already been done by more determined people. And if not? Then…
-
… we can just say:
-
-
and call it a day.
-
This has been solved partially by Lemmy and its community
Announces, and partially by scale. -
Of course everything on Lemmy and compatible platforms has to be posted to a community. However /kbin’s magazines did more than that. They also aggregated (already federated) microblog content based on included hashtags. The magazine mod could specify, what hashtags would be aggregated under the mag.
- The sidebar on /kbin’s posts also includes sections like Related Magazines, Related Threads and Related Posts (for toots etc.).
- … and Active People. And “People” is one of the entries on instance’s navbar. Yes, different one for every magazine, so you could follow anyone active in the topic.
All of these has been inherited by Mbin, its fork (well, maybe not its size xd)
-
One of the reason, why /kbin has achieved the success (so large, that eventually took it down…) has been it solving much of these UX sins:
- This was only by chance, but as /kbin was ~not already~ never ready for third-party hosting, there was only one non-Polish speaking instance of /kbin (flagship kbin.social). This is another reason, why registration numbers made briefly kbin.social’s MAU greater, than that of entire Lemmy software!
- But what about decentralisation? As I probably have argued when /kbin yet existed, the Threadiverse could as well consist only of lemmy.ml, piefed.social and a Mbin instance (or the Feediverse might by only mastodon.social, misskey.io, flipboard.com, and Pleroma/Akkoma instance) and still be decentralised. Several carbon-copy instances are the simplest way to make an interoperating network - but not the only one!
-
/kbin of course is a Threadiverse app and evades this sin by definition. A Lemmy user never has to browse an empty “timeline”
-
This is a cursed solution for this sin, but with so great scale of flagship instance (and no alternatives) much of the federation work has already been done by more determined people. And if not? Then…
-
… we can just say:
-
-
and call it a day.
-
This has been solved partially by Lemmy and its community
Announces, and partially by scale. -
Of course everything on Lemmy and compatible platforms has to be posted to a community. However /kbin’s magazines did more than that. They also aggregated (already federated) microblog content based on included hashtags. The magazine mod could specify, what hashtags would be aggregated under the mag.
- The sidebar on /kbin’s posts also includes sections like Related Magazines, Related Threads and Related Posts (for toots etc.).
- … and Active People. And “People” is one of the entries on instance’s navbar. Yes, different one for every magazine, so you could follow anyone active in the topic.
All of these has been inherited by Mbin, its fork (well, maybe not its size xd)
Do you have any idea why Mbin never got as active as Kbin was?
-
Do you have any idea why Mbin never got as active as Kbin was?
IMHO for the same reason why Myspace has over hundreds of millions of MAU and Spacehey has got only over million of users overall.
IMHO solving UX sins does not bring new users. It rather helps not to deter them.
The Great Migration from Reddit did not repeat with the same scale, as with Great Twitter Migrations. Even then, most people IMHO return rather to their already existing accounts on already existing instances. Fedia.io has over 5 thousands total users, less than dozen Lemmy servers.
With the lemm.ee going down, we will witness a MAU drop. A non-zero number of people care no more about federation and will not make a switch.
There might not be enough stock of users to repeat /kbin’s growth right now. Even recent developments at PieFed make its MAU number only slightly larger than Mbin
