How about if we take some time off from talking about Threads (TM) the Instagram/Facebook/Meta App, and instead talk about the best #interfaces for displaying and building a conversation #thread on the internet?
It makes me crazy that in order to build up what you will be able to read top-to-bottom in this #thread, I need to continually reply to the bottom post in this thread.
Furthermore, if you were to write a reply to one of the toots in this thread, your replies appear at the very bottom, with no visual cue to other users to indicate which toot you were replying to.
And the same applies to subthreads within this thread.
The upshot of the #threading interface that Mastodon inherited from Twitter is that, while it is straightforward to post an essay or rant as a sequence of toots, it is not at all straightforward to follow any conversations that it generates.
In principle, it should be relatively straightforward to create a Mastodon / ActivityPub client that would organize threads in a manner more similar to #Livejournal / #Dreamwidth / Euphoria (https://euphoria.io/room/welcome/), but building something like that would present new problems because views of thread / conversation structure would differ by client.
If you were to view this thread on a client that supported the kind of threading that I would prefer, this current toot would be indented [pauses, counts] six levels deep, and that would be irritating, because all of these posts are part of a single #rant about conversation interfaces on the internet.
For a bit, I was chatting with some people I know from Euphoria about whether we could conceivably build a #Matrix client that would mimic Euphoria's #threaded conversation experience, and we realized that (technical challenges aside), we would quickly run into this exact issue if we tried to use this client to communicate with people using a more mainstream client, such as #Element.
Conversely, if I were to build this #thread for a client with the kind of indentation structure I want to see, I would have one top level toot, and post all subsequent toots as replies to that top toot.
Everything except for the top toot would appear at the same indentation level, and replies to toots in the thread would be indented in place (below the corresponding toot) so it would be visually clear which part of the thread they reply to, and also that they are not part of the main thread.
A hypothetical #Mastodon client that approached #threading in the way that I suggest could take things a step further by automatically collapsing (hiding) subthreads, so that people can choose whether to view those replies (again, in place) or not.
Unfortunately, trying to organize a Mastodon thread with all toots as replies to a single top-level toot results in an incoherent thread view on the default web client and (as far as I know) all other existing clients.
In particular, in a "normal" #Mastodon interface, if you activate / click on / link to a toot within a longer thread, all you are able to see is that toot, its immediate ancestors, and its descendants. The siblings of its parents and ancestors are not visible.
That means that for a thread to consistently display chronologically on an existing client, it needs to be structured with each post as a reply to the previous.
So, in our current world, in which conversation platforms are accessed by diverse clients, there are real barriers to client diversity in how #threading is handled.
This isn't just a #Fediverse issue, but applies to any protocol that can be accessed through independently developed clients.
The upshot of my upthread comments on threading interfaces is that I think that there will tend to be a pairings between protocols and interface designs, even if there might be a clearly preferable design approach available.
For a protocol (e.g. #ActivityPub, #Matrix, #email) for which there are diverse clients available (true for ActivityPub and email, but not really for Matrix), there will tend to be a standardization of interface conventions between clients.
This kind of standardization can sometimes be useful, but sometimes is unfortunate.
On the flip side, when a platform / protocol is centralized (or just centralized for a majority of users), interface changes---whether desirable or not---can occur very rapidly.
For example, when Google decides to implement Gmail in a way that makes bottom-posted emails (see https://en.wikipedia.org/wiki/Posting_style) difficult to read, large numbers of people must quickly change their conventions on how they write email.
The ways that Gmail has transformed our use of email can be seen as a negative aspect of centralization, but as I've noted above, related issues can occur with decentralization as well.
We're strongly nudged to conform with the standards adopted by either a single centralized platform or the standards adopted by the majority of clients in a decentralized platform.
This is a case where "if you want it then build it" doesn't necessarily work.
And the challenges I'm describing would exist even for someone who had all the of the skills and development infrastructure already in place, and even if they had already solved all of the technical problems and knew exactly how to implement their vision correctly.
Add comment