Should Mastodon UX distinguish "Replies" from "Threads"?

[mcclure]

Pitch

In the Mastodon.soc GUI, and many third party Mastodon clients, there is a "Show replies" filter.

This sounds like a useful feature to me. However I did not realize for a long time that hiding "replies" would also hide threads (EG, self-replies). Logically it makes sense "Hide Replies" would hide threads, but when I first saw the feature I thought the intent was "hide discussions", so it didn't occur to me threads (usually a continuation of a post rather than a response to it) would be covered. They are the same thing as a reply in the database, but socially they are used for a different purpose. In discussions I have had with other people about this, often other people also seem to be surprised when they find out "hide replies" is hiding threads.

This alarms me because it makes me worry some people have enabled "hide replies" without realizing it. If this is widespread, it creates a minor incentive to not create threads at all, or to engage in otherwise strange behavior like RTing thread posts immediately after making them to escape the "hide replies" filter. I have a long-running thread where once a day I update with a song I like, and while I can definitely imagine some people might consider this obnoxious or want to mute it, it seems too bad if there are people who would have wanted to see it but hid it by accident. (In a long running thread like this there is not even the chance someone could click on the root post, because the root post may be very old.)

I'm not completely sure what my "expected behavior" here is. I think I'm just looking for some assurance the development team has thought out the behavior. This said, I think my suggestion would be to make one of the following two changes:

1. Split the "Hide Replies" filter into two disjoint filters, "Hide Replies" and "Hide Threads"*. OR
2. Reword "Hide Replies" to "Hide replies and threads".

Motivation

Consider: Could it be implemented as a 3rd party app using the REST API instead?

In the case of my first suggestion— separate "hide replies" and "hide threads" into two filters— I believe this would need server support. The problem is a "thread" generally means a self-reply in some chain of self-replies containing no posts from someone else, and only the server has ready access to that full history. A third party app could approximate this by checking if a post begins with a mention, but this could get flummoxed in several ways, for example if example A makes a post, B replies to A, then A replies to themself and deletes B's handle from the second reply. Probably if someone has enabled "hide replies", "show threads" they want that final post hidden because it is ultimately a reply. I think to implement this filter effectively the server would have to track a "is a reply?" database flag for each post, set if the post is a reply to another person's post or a reply to a reply, and convey the flag to third party clients.

[erisdev]

my hot greasy take: there is no world in which i could be convinced that threaded posts are "replies" in any meaningful sense of the word. that they are ~technically~ replies is an implementation detail.

option 1 is to me the most sensible. option 2 feels like the "if thou must" option: if the current behavior is intentional it absolutely needs to be clarified.

[confluence]

I support the idea of splitting replies and threads into two different settings, because I have the opposite use case: I follow people who post bursts of information in very long threads, and I don't want to have to scroll through 20+ posts in reverse in my timeline after I've read them in order by clicking through to the thread.

Ideally I would like a length threshold (e.g. threads longer than 5 posts), and perhaps a visual indicator that a post is part of a thread which is being hidden (in case this is not obvious from the text).

I hadn't considered the possibility of someone continuously adding new posts to an existing old thread, but that's a good point. Perhaps there could be an optional "reset" parameter for a time interval after which a new post would not be hidden.

These additional settings could also be useful for threaded discussions involving multiple people, but I still think that it should be possible to set them separately for threads and replies, because they are used so differently in practice.

[r0bbie]

Went looking for an existing issue relating to the UX on threads and found this, so just wanted to add that there's some good suggestions above, and I hope this is something the developers might prioritise! Compared to Twitter, it seems a massive UX drawback with Mastodon at present.

The main issues it seems to me are:

• Composing a thread is clunky. You need to just create one post, then keep replying to it. Many people compose threads so that each post in one section of a whole.
  • When trying to keep each individual post potentially under character limits, upload associated media etc, they may be delays between posts with the current approach also, so people seeing the post in their timeline may only see a partial thread in progress
  • If other people reply to posts while a thread is still in process replies can get jumble up
  • Also easy on long threads to get mixed up on which you're replying to / which order you're posting in etc, if you're copying/pasting the text from another editor you've drafted it in
• Posts in a thread are currently displayed in reverse chronological order, which is the opposite way you'd read them. as others have noted. There may be gaps between posts as presented in the timeline, and it may not be immediately obvious a post even is part of a thread or how they slot together
• As also noted above, long threads could perhaps hide some posts when viewed on the Home/Profile view - so the feed isn't being filled up with a jumble of thread posts mixed between other posts in an unreadable or at least unintuitive order

I do think Twitter has been nice UI/UX around solving some of these issues at present (till Musk inevitably decides to delete it for some reason), which potentially Mastodon could take some influence on (or improve upon perhaps!). Namely:

• Threads can be composed together in a dedicated view (just click the + button when composing a post to chain more onto it), then all posted together
• If the author wants to add more posts to a thread they've created, there's a dedicated "Add another post" button at the bottom of the thread that chains it on (i.e. ensuring it's to the END), as opposed to treating it like just another reply
• Posts in thread are grouped together in the timeline so that the user can actually see they should be read together, see where each post fits in, and it's in chronological order so it actually makes sense!
• Long threads have some posts in the middle hidden, while clearly indicating it's a thread, so the user can just click on it if it interested to view whole thread (a single long thread doesn't absolutely fill up their timeline and can easily scroll through to other posts)

Threads do seem like a nice way to me to share longer form content, consisting of smaller ultra-readable units within the post character limits. They're very common on both Twitter and Mastodon, and ideally hope to see them properly considered and considered within the UX of the latter also :)