Threads interface v1

[erlend-sh]

The way we’re currently displaying Threads in the threads-view is actually how I think we should be displaying it in the chat-view immediately following a message-threading event.

Let’s say we’ll show maximum the three first posts (could be interesting to combine that with the last two, but probably best to punt the extra UI work that’ll entail for later).

Upon completing the threading and thus making a new thread, this preview widget shows at the bottom of the chat, with a clickable title (to enter the thread) as well as a ‘Dismiss ❌ ’ button to hide it if you just wanna continue the mainline conversation.

Essentially we just start by making an improved version of the Discord method, by showing additional posts in the New Thread callout block:

The threads-view on the other hand should be compact, essentially like this:

Opening a thread (whether from the preview-widget’s linked title in chat-view or the compact item in threads-view) takes you to a page like this:

(I don’t care too much about the specific elements/placements etc. right now, as these always go through many iterations anyhow.)

---

TODO

• feat: threads interface PoC #43
• Eject Thread: Hide the moved chat-messages along with ‘Moved to:’ notice. Show moved-notice.
• Post within thread

[erlend-sh]

zeu: I personally would like any messages to be all in one timeline. The idea being that eventually the main timeline will have indicators as to if the message belongs in a thread, but the entire conversation is captured.

There are two ways to go about this and they both have pros/cons, but they can probably co-exist as UI preferences:

Unified timeline

The benefit is that no post ever mysteriously disappears from the timeline.

Challenges include:

• how do users know how to correctly reply to an inline thread versus the mainline chat, and do it easily.
• anything more than two simultaneous threads will easily overwhelm the timeline.

Zulip for instance only has okay solutions to both of these problems. We need to be better.

Ejected threads

The benefit is less noise and crossing of streams.

Challenges:

1. how can users be kept aware of ongoing thread so they don’t miss out on the convo?
2. posts disappearing from main timeline can lead to confusion.

There is a pretty good solution to (1) which Discord and similar doesn’t do, which is to continue clearly showing the thread as a tab in the mainline window, and also as 🆕 in the right-hand sidebar (wouldn’t be visible on mobile though), that way it’s still highly discoverable.

(2) can also be solved for by not removing the messages from view right away, but marking them as having been moved/threaded and as such they’re corralled into a box and cannot be replied to inline but rather have to be clicked on to enter the new thread.

The cool thing is we can indeed support both options interchangeably. And we get a preliminary version of ‘Ejected threads’ by building in the ability for users to dismiss/hide threads from mainline at their own convenience.

I think the Discord-style thread ejection (which we already do better, by allowing multi-post transitions) is still the best/easiest thing to build first, because:

• The all-in-one UX is more complex and will take longer to do well.
• Threads-compatibility with Discord is more strategically urgent, because it enables us to provide a seamlessly bridged experience.

Therefore reopening this issue with a refreshed TODO in top.

---

Essentially we just start by making an improved version of the Discord method, by showing additional posts in the New Thread callout block: