Open agentjabsco opened 1 year ago
Yeah our thread rendering is very frustrating. I'm going to try to dedicate some design resources to fixing this, but it's one of the many things that keeps getting punted by other priorities.
If you need a long thread as an example: https://bsky.app/profile/carlbergstrom.com/post/3k5e6btkslm2e
The thread itself has 42 posts.
I don't mind having to click, even several times, but I think the visuals could be clearer.
'Continue thread' is easy to overlook, at least on desktop.
And the > indicates: you are leaving your path and go to a side road.
But what I do by clicking on it is the opposite: I stay on my path (the thread), which goes further down, not to the right.
So I think it would help for the thread itself (ignoring the question about how replies are shown) if
Nice to have: "Show whole thread" instead of "Continue thread".
Edit: I'd also like a 'show all' possibility for threads and their replies. In some forums I've seen the choice between "flat view" and "threaded view", but that may be different because the post that starts it is usually just a single post, not a thread. ('flat view' could also be called 'chronological view').
If I had to pick one of the two, it would be threaded.
The > would work for the comments, though:
Show me the whole thread without having to click, and use the inserted line with > for "get sidetracked by the comments".
Would let you place the comments after the post they belong to.
As long as "Continue thread" works as it does at the moment, I'd really like to be able to open it in a new browser tab (desktop).
PR #2578 which was merged recently might be relevant
I'm on 1.86, looking at the example from above in Firefox and Chrome. Do the changes in thread display only apply to new threads, done from today on? (I wouldn't mind, just curious).
https://bsky.app/profile/carlbergstrom.com/post/3k5e6btkslm2e
After (11/n) there is now no indication that the thread goes on
Even knowing that it does I do not see a way to get to (12/n)
The recent update is not yet applied to "Tree View Mode" yet
Is your feature request related to a problem? Please describe.
Right now, replies in new branches of threads are concatenated directly to the bottom of the "first thread" in linear fashion, with no context illustrating which post they are in reply to. This has led to certain misunderstandings on Bluesky: users have replied to posts in their notifications thinking a question directed in reply to someone else's comment was intended for theirs, and vice versa.
So far, all these understandings have been, mercifully, minor: that is not to say they could not lead to very fortunate misunderstandings, including engineered "misunderstandings" that would have plausible deniability. (This feature/need gap will become a critical class of social engineering risk as the protocol federates across multiple front-end implementations.)
Describe the solution you'd like
In the case of indicating which reply is being made to which posts in a "threaded" presentation where the "reply-tree" is non-linear, one natural way that comes to mind would be to present the text of every "not-directly-threaded" reply chain with the text of the post it is replying to on one small ellipsized (ie. ending with "..." if the context would be longer than one line) at the top
For cases where one reply has many "single-post leaves" (ie. replies that do not themselves have any further replies), rather than presenting the same context for each of them, a "leaf-like presentation" could extend from their common parent as a context, to show that a run of leaves are not, themselves, a thread
Describe alternatives you've considered
Reddit presents an actual tree-like structure of posts: however, *Reddit has a very different culture from Twitter, which is where Bluesky's growing userbase comes from. This is what I mean about featuresets becoming a social-engineering vector: someone on a site like Bluesky without good and explicit thread-awareness may be annoyed by a user who makes a lot of posts with heavy assumptions abouth the threaded context, and someone on a side with a Reddit-like presentation can become annoyed at a conversation that doesn't clearly distinguish between branches of reply threads (because ie. Bluesky presents them almost all as one big thread).
Additional context
This proposal is probably most influenced by how replies work on Discord, where "usual threading" is implicit by default (as it's a chat platform): Bluesky is I would say something closest to a hybrid between Discord's "chat-like" model and Reddit's "newsgroup-like" model, so a hybrid between these two UX approaches (where replies are as "tree-like" as newsgroups, but as "time-series-like" as chat) makes the most sense to me.