The most important features for communications apps: preview and reverse-preview
When I was still in university, my professors endlessly hated and complained about the school-provided Learning Management System (LMS). Other than uptime, it almost always came down to a usability problem: they'd accidentally publish something, or not publish something, or have trouble finding some piece of functionality that they knew was there, or not be able to get it to calculate grades right...
You know there was something really wrong with it, because they usually replaced the LMS with general purpose apps like Google Drive and Email. It was after using it as a TA that I figured out why...
If I click this button, what will the people on the other end see?
From the point of view of a student, the LMS looked kind of like a read-only wiki. After you open up a class, there's a sidebar of pages, some of which either have lists of documents, plain text, or something like your grades or a test. Naively, I assumed that the wiki-ness would extend to the editing experience, that I'd be given the "write bit" and be able to edit a page, preview it...
Nope. From the teacher's point of view, the interface was completely different: it looked like a file manager, more or less, with folders and files that only have a loose relationship to what the students were going to see, and a surprisingly complicated permissions system and transaction model governing when and whether a document would be student-visible. You had to figure out how to set up the permissions, or the content would be silently invisible to the students, and how to insert it into the student-visible categories, and there was no way to "go in as a student" (as a professor articulated their desire) to see if you had gotten it right.
At first glance, Mastodon (you knew it was going to come up eventually) seems a lot better than that. The stuff you type into the box is what is going to be visible. But once you venture beyond plain text, different frontends might present the content differently; essentially, being federated means that it's not possible to provide an accurate preview.
For example, if I wanted to post a riddle, I might use the "Content Warning" feature to hide the answer, because my instance presents it as a simple link-and-obscure flow, and I assume that every other instance does the same thing. Thus, I created a toot where you can click a link that says, "What time is it when an elephant sits on your truck?" and get "Two-thirty." revealed. Ha ha.
But if, instead, a third-party instance presents the link as "CONTENT WARNING: What time is it when an elephant sits on your truck?", that changes the meaning completely! Your frontend just put words in my mouth!
It's surprising how you don't really notice what you have unless it's gone: pretty much every consumer-grade communications system tries to offer a way to preview your changes before you commit them: maybe the whole platform is plain text and it's obvious what it'll look like (IRC), or maybe it's like
jekyll serve and just presents a high-fidelity replica of what the result is going to be, or maybe it's just a WYSIWYG. The HTML standards have increasingly required "bug-for-bug compatibility", because differences between browsers are, in practice, garbling web author's intended meaning.
Goal-oriented users, exercising your LMS or microblogging platform, probably already have a good idea of what they want the result to look like. Especially if they've already seen other people using it (coming up with the idea of using content warnings to present a riddle came from seeing other people's content warnings and noticing that it did what I wanted).
What buttons did they click to get it to do this thing that I see?
People learn to speak and to write by imitation, so why wouldn't microblogging (or even just regular blogging) work the same way?
The features provided by a communications app are basically a language, just like any other. Ever seen an IRC buff sneak a
/me thinks so too into a platform that doesn't even have ACTION messages? (p.s. it's pretty telling that IRC clients have standardized on the exact way they render ACTION messages, because they know any changes would garble their intent)
I actually really like this aspect of Twitter. Most of its special features, like
@mentions, are rendered exactly the same way they're typed, so imitating it is trivial. The power of plain text in action!
So, anyway, whether it's just by asking someone how they did it, or through some kind of UI feature, I would really like to be able to take a rendered message that I like and figure out how to achieve it myself. And the Fediverse is actively hostile towards that, too.
The worst possible case is where it's literally impossible to imitate someone else, like if the instance I'm on has a lower character limit than the instance of someone I'm subscribed to. Similarly, if I'm asking someone how to do something, and they're using a different client, it's just one more barrier to entry. And a lot of features (like content warnings) are not textual, though where Mastodon copied Twitter, it also copied the good parts of that.
The Fediverse is user-hostile. Change my mind.
When a writer interacts with a piece of communications software, they are going to attempt to construct a mental model of what the reader is going to experience as a result of their actions. That's how communication works in general: I move a pencil around with a result image in mind, I vibrate my vocal chords after already imagining what the resulting sounds will be, and I set up tags in a DEV post with the expectation that it'll result in certain people receiving the message (and will be shown underneath the title but before the content).
Similarly, when a reader interacts with a piece of communications software, they are going to construct a mental model of what and why the post's writer did to create that post. I know, if I see something like [this] (https://example.com/, that it's just a mistake that the author made, an artifact of the software, and I can figure out what their intent was. The more variation in feature sets, the harder that is.
The Fediverse's "feature" of having multiple clients with radically different feature sets is a barrier to communication.