One difference is that Twitter doesn't have to educate it's users about federation since it's centralized, so there will always be that requirement out of a fedi user to at least cognitively handle that concept; if they can't handle that, then you're just trying to appeal to the most fickle person who will likely never be won over.
It shouldn't need a tutorial or extensive guide, the only requirement anyone should be expected to know (or all that should be explained) is just: anyone can be on any server and still interact between each other. If you want to interact with some post or user on another server's website, just copy/paste the URL of that webpage into the search of your instance's website (or mobile client), and it'll be able to decode it and give you options to reply/follow/whatever through your account.
The thing I think needs to be improved amongst instances is of providing a redirect for any ActivityPub requests to a post that's actually from a remote server (e.g. https://example.com/@user@someotherhost.com/posts/abc123). There should be a simple conformance test for server admins, and a 'how to' for each server software to iron that out, as well as any backend fixes necessary. THAT is the bigger thing of UX issues, because it feels unnecessary to train users what URLs are 'bad URL' and which ones are 'good URL' (to click through the post, and find the URL of the origin server, and then copy THAT into your search instead). That is the biggest thing to fix over any frontend issues.
As for interactions starting from a remote server, some of that can add unnecessary complexities and slower experience (e.g. the 'remote follow' workflow of typing in your WebFinger ID, authenticating, action confirmation, etc). There's not a lot available to simplify it without expecting browser extensions or similar.
The only thing that could be done is designating a protocol handler URI scheme, such as 'web+activitypub:' for remote actions, whereas if a protocol handler is detected as registered, it'd provide a URL to invoke that handler instead. E.g. you could have a Soapbox install (or pleroma-fe, or whatever) register as a handler for 'web+activitypub:' URIs, thus when someone's on a remote website and wants to follow someone from the remote website, they could click a link that points to say 'web+activitypub:action=follow;resource=https://example.com/users/bob' (or whatever formatting) which would kick them over to their instance, and give them the option to just click 'confirm', versus typing in a WebFinger ID and a longer follow. The only thing is that it'd only be useful if you only use a single account, since it'd be bound to handling any of those custom URIs at one instance.
@Ryle@Flaky I like to see my writing style as being long and drawn out and I could probably write a more descriptive guide in a night or so that's easier for people who "don't get it" to "get".
Then again I've been using fedi for a year or two at least.
You don’t need a guide to use Twitter. Approaching this as a guide issue is the problem. Very clearly it’s a bad UI/UX problem that most people are experiencing.
I’m genuinely curious how we could improve it in Awoo.
I’m not too surprised about the confusion, I’ve seen people linking documents like these in response, or having large drawn out guides which for me just feels very unfriendly.
I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explanation it for users to use it effectively.
For email, it’s because it’s commonplace, as many are even growing up in an environment where email has existed as a norm before they were born, as people have to understand email for some work environments, or for even getting a job. I don’t think that people think much on how email works, of knowing that it’s a federated protocol, just merely “that’s the way it works”. Hell, majority of people likely don’t even configure their own email client themself, they likely just use the vendor’s application instead.
Nonetheless, federated content platforms are an emerging thing, and thus people have to ‘re-learn’ that there are different ways to intercommunicate than email.
Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page (…)
It’s been at least 6 years since I last touched mobile app dev. Last I remember it was an ‘Android thing’ to ‘intercept’ certain registered URLs to a mobile app, whereas I think the iOS way was only with registering custom URI schemes. It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity. The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).
“One difference is that Twitter doesn’t have to educate it’s users about federation since it’s centralized, so there will always be that requirement “
I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explain it for users to use it effectively.
I see most current issues with the Fediverse to be a UI or associated UX issue.
“As for interactions starting from a remote server, some of that can add unnecessary complexities and slower experience (e.g. the ‘remote follow’ workflow of typing in your WebFinger ID, authenticating, action confirmation, etc). There’s not a lot available to simplify it without expecting browser extensions or similar. “
I certainly agree this particular problem isn’t a trivial issue to solve, mainly because it requires adoption of a solution across different implementations.
“The only thing that could be done is designating a protocol handler URI scheme, such as ‘web+activitypub:’ for remote actions”
Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page on the other hand get a normal webpage that can simply accept your username@instance (and maybe offer to store it in local storage so you don’t have to reenter it next time) and do the necessary forwarding to the appropriate instance for an action.
I don’t think though this is where users are immediately running into problems. I think there are a lot more basic problems like content discoverability, which isn’t a problem on stuff like Fidonet.
I frequently think about a situation a couple of new users on this instance complained about recently with me. You want to talk about a particular topic? Well, there’s a group of servers over here that cover it, they’re the standard, except, none of them are accepting registrations, they’re not on public relays, the admins on those instances don’t want to join a relay or don’t respond. They’re federating with your server, but equally, you don’t know anyone on that server and vice versa so discovery is difficult. They locked down the ability to see their feeds, so you don’t even see who you could follow remotely. This is really bad and I think the couple of users that complained about this have given up on the fediverse entirely since they haven’t logged in, in a week now.
I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explanation it for users to use it effectively.
For email, it’s because it’s commonplace, as many are even growing up in an environment where email has existed as a norm before they were born, as people have to understand email for some work environments, or for even getting a job. I don’t think that people think much on how email works, of knowing that it’s a federated protocol, just merely “that’s the way it works”. Hell, majority of people likely don’t even configure their own email client themself, they likely just use the vendor’s application instead.
Nonetheless, federated content platforms are an emerging thing, and thus people have to ‘re-learn’ that there are different ways to intercommunicate than email.
Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page (…)
It’s been at least 6 years since I last touched mobile app dev. Last I remember it was an ‘Android thing’ to ‘intercept’ certain registered URLs to a mobile app, whereas I think the iOS way was only with registering custom URI schemes. It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity. The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).
…A delete & redraft later: it would be nice if Soapbox had a Markdown preview…
and not forget that a post was set to Markdown syntax, when delete and redrafting (which gets unset).
I think it’s more, what’s your e-mail address? Then there is nothing else really to trade between people.
Ask people what’s their handle on Fediverse… To which people get confused and then you ask if they’re on Mastodon. Then, maybe. Someone then gives their user@instance, some give just the user without instance and then I’ve had some users give me their e-mail…
I believe that confusion is mostly caused by just the login process (let’s just start calling it the fedi handle or something). The fact that to login to your account, you use an e-mail address, or just your user without domain on most instances. Compare to say Twitter where you can use your username, or most free consumer e-mail providers ask you to enter your full e-mail address etc.
“whereas I think the iOS way was only with registering custom URI schemes.”
Yeah, it usually requires having JS trigger it on the page but I didn’t think it worth mentioning.
“It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity.”
My overall thought is that ActivityPub was standardised through the W3C and they’ve traditionally hosted things like XSL Transformation schemas among other things, they could be an option; IANA also set aside specific domains for certain technical demands and maintain them which could be another entity that could be viable as an option.
“The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).”
Kind of, Android URL app registration requires a particular domain and can’t just be applied to every domain with a certain URL structure. Using apps on Android feels very broken for fediverse links currently (some actually register A LOT of instance URLs to get around this).
But again; I don’t think that this one single facet is the significant reason behind people not understanding how to use the fediverse, I do think it creates a very unpolished experience though and that’s definitely something you’ve clearly identified.
“…A delete & redraft later: it would be nice if Soapbox had a Markdown preview… and not forget that a post was set to Markdown syntax, when delete and redrafting (which gets unset).”
Markdown wise:
Totally agree on the markdown preview
Markdown when converted to plain text really should could up wioth a nice ASCII alternatives, so we don’t need to manually add things like quotationmarks for Mastodon users.
I changed my Settings to always compose in markdown because I keep forgetting.