Threads Beta — Design implementation review

[janogarcia]

Resources

• Figma: Reference screenshots

---

Thread list

• Root message avatar: Make .mx_EventTile_avatar render a 36px image (instead of 24px)
  ❌ Apr. 1 Now it's measuring 32px instead of 36px.
• Root message avatar: Change .mx_EventTile_avatar top position to 0 (instead of top: -4px)
• Vertical alignment for elements in the thread summary should behave the same way as thread summaries in the main timeline (the ones that Michael (t3chguy) recently fixed).
• Align thread list to the top (latest activity on the top, screenshot).
  ✋ Blocked by BACAT scrolling
  ❌ May. 26 It's been suggested to treat this enhancement separately from the Threads project. Threads Beta — Design implementation review #21502 (comment)
• Make the right gutter 40px (screenshot: currently set to 32px).
  ❌ Apr. 1 Now it's measuring 46px instead of 40px.
• Unread indicator: set dot size to 10px and center it. (screenshot)
  → Figma
  🐛 Apr. 1 Barely visible, the dot is almost completely cut off (macOS Chrome).
• Unread indicator: use Compound’s secondary color for the gray color (instead of #61708b)

Thread list: Hover state

• Fix split background colors. (screenshot)
  Tracked by Implement improved spacing for the thread list and timeline. #21759
• Remove left green border for own root messages.
• Make the border radius 8px (instead of 4px).
• Extend background color on all sides to add expected padding.
  Tracked by Implement improved spacing for the thread list and timeline. #21759

Thread list: Empty state

Refer to mockups.

• Fix the margins for the contents (screenshot).
• Add missing line: Tip: Use “Reply in thread” when hovering over a message..
  → Figma
  🐛 Apr. 1 When visiting a room it suddenly changes to the previous version (the one without the tip) when it attempts to load the thread list for the first time.
• Set Show all threads font size to 15px.
• Filter popover menu: Do not reverse caret direction when control is active.
  → Figma
• Filter popover menu: Set a gap of 2px between popover menu and the control.
  → Figma
  ❌ Apr. 1 The gap is now bigger, get it 2px closer.

Thread view

• Make the left gutter 60px (screenshot: currently set to 48px)
  ❌ Apr. 1 It was 48px, now 52px, still not 60px.
• The user name and message body should align to the same vertical line. (screenshot)
• Vertical spacing between message titles: Apply the same spacing as in the main timeline (screenshot).
  ❌ Apr. 1 Set padding-top: 14px for .mx_ThreadView .mx_EventTile.
• Align timeline to the top of the timeline container.
  → Figma
  ✋ Blocked by BACAT scrolling
  ❌ May. 26 We're dropping this requirement for the thread timeline.
• View in room action is missing in the root message contextual actions.

Thread search: Keyword match in thread reply

• Fix layout for “From a thread” footer: align left edge and add missing gap between icon and label (just change margin-left: 8px; for .mx_ThreadSummaryIcon::before to be margin-right: 8px;), reduce top margin (make margin-top: 8px for mx_ThreadSummaryIcon).
  → Figma
  ❌ Apr. 1 "From a thread" text should use secondary color. Also, .mx_ThreadSummaryIcon is now an inline element, and thus the 8px vertical margin is having no effect.
• Make the thread reply footer mx_ThreadSummaryIcon clickable, behaving the same way as its related mx_EventTile_line.

Thread search: Keyword match in thread root message

• Root messages in search results should display the thread summary in the footer. (“From a thread” it’s only for thread replies)
  → Figma
  Tracked by Thread summary is not displayed for root messages in search results #21450

Refer to the annotations on how the flow should work for “Keyword match in root message”:

• Clicking on the root message shows it in the room timeline.
• Clicking on the thread summary opens the thread panel for the matching room. It will only exit the search result screen if keyword match is from a different room.

[t3chguy]

Align thread list to the top (screenshot).

Align timeline to the top of the timeline container.

This is non-trivial as this is part of our ScrollPanel pagination mechanism - https://github.com/matrix-org/matrix-react-sdk/blob/develop/docs/scrolling.md#bacat-bottom-aligned-clipped-at-top-scrolling

The approach taken instead is to vertically align the timeline tiles to the bottom of the scroll container (using flexbox) and give the timeline inside the scroll container an explicit height, initially set to a multiple of the PAGE_SIZE (400px at time of writing) as needed by the content.

[t3chguy]

Make the border radius 8px (instead of 4px).

This already appears to be 8px, can you confirm?

[nadonomy]

@janogarcia @t3chguy @gsouquet can I add these visual glitches to your list pls? (develop, latest):

1. Display name split across multiple lines. I assume/suggest it should always be single line and use text-overflow: ellipsis; or similar.
2. At certain responsive sizes, read receipts can overlay the thread summary. I assume/suggest the thread summary should be less wide at this breakpoint.

[t3chguy]

@nadonomy 1. is #21472

[t3chguy]

Regarding “From a thread” we can probably improve it, given that if that footer comes up then it may result in multiple messages with the same footer if the thread had quick subsequent replies and one of them matches the query.

If the result is a thread reply then any possible shown context around it will be also so no point each and every event having its own "From a thread"

[janogarcia]

This is non-trivial as this is part of our ScrollPanel pagination mechanism - https://github.com/matrix-org/matrix-react-sdk/blob/develop/docs/scrolling.md#bacat-bottom-aligned-clipped-at-top-scrolling

@t3chguy Thanks for sharing the technical background on the current timeline scrolling implementation. 👍

That said, we shouldn’t expect all scrolling lists in the app to behave the same way, as those are dependent on the content. What makes complete sense for the room timeline may not be the most usable pattern for other contexts. I know this is from a completely different context, with its own constraints, but we’ve implemented it already for iOS/Android and need this to work consistently across platforms.

So, what if we make some tradeoffs to make it work?

→ For example, let’s say we’re able to get the desired scrolling behavior TACAB (top-aligned, clipped-at-bottom), but we don’t try to prevent the list from jumping when new elements are dynamically added/removed? Would that make it any easier? Jumps in the thread list, while not an ideal UX, would be far less frequent than jumps in a timeline which gets constantly updated.

[t3chguy]

That said, we shouldn’t expect all scrolling lists in the app to behave the same way, as those are dependent on the content. What makes complete sense for the room timeline may not be the most usable pattern for other contexts. I know this is from a completely different context, with its own constraints, but we’ve implemented it already for iOS/Android and need this to work consistently across platforms.

Unfortunately maintaining two scrolling implementations will be very maintenance expensive, preventing scroll jumps in infinite-scrolling lists is non-trivial.

→ For example, let’s say we’re able to get the desired scrolling behavior TACAB (top-aligned, clipped-at-bottom), but we don’t try to prevent the list from jumping when new elements are dynamically added/removed? Would that make it any easier? Jumps in the thread list, while not an ideal UX, would be far less frequent than jumps in a timeline which gets constantly updated.

Yes it would but the maintenance burden would still be large, it'd cause a lot of code duplication and lead to a lot of potential for bugs due to the low test coverage we have and are able to have over complex interactions like infinite scrollers.

Jumps in the thread list, while not an ideal UX, would be far less frequent than jumps in a timeline which gets constantly updated.

A TACAB approach would have guaranteed scroll jumps every time you're back-paginating (scrolling up) due to the spinner rendering in & out.

[janogarcia]

This is a limitation of the spec, the search API doesn't tell us they're thread roots: matrix-org/matrix-spec-proposals#3666

@t3chguy In that case, we can wait for the spec to be updated.

That said, the screenshot you shared with example search results is showing a thread summary on the first message. Has this been implemented somehow for search result context messages (but not for the actual search result matching messages)?

(iOS/Android are also showing thread summaries for root messages in search results. That’s why I assumed it was missing on Web. Unsure how they circumvented the current backend limitations and how performant it is.)

[t3chguy]

That said, the #21502 (comment) with example search results is showing a thread summary on the first message. Has this been implemented somehow for search result context messages (but not for the actual search result matching messages)?

As per my comment

We will only be able to show the thread summary until the spec issue is fixed where we have already loaded that thread prior to encountering this thread root as a search result.

In other words, its done on a best effort basis without having to hammer the server by asking for each event if it is a thread root. (i.e if user scrolled to it or it was recent or user opened the Thread Panel to cause all threads to get loaded in)

Edit: we could more eagerly fetch all threads (as soon as you open the room, or when you perform a search) but both can cause the server to get hammered more than necessary and cause a lot more memory & bandwidth to get consumed.

[t3chguy]

@t3chguy In that case, we can wait for the spec to be updated.

Tracked by #21450

[t3chguy]

• Editing in threads doesn't line up with Save button and the grey bg doesn't fill the width

[jryans]

@t3chguy That shouldn't be happening. It seems .mx_ThreadInfo is not tracking/following the same width constraints as .mx_EventTile_line. Can we please make it track that constraint?

I think @jryans implemented the current responsive optimizations for the thread summary, maybe he can add some context for that difference, if intended for some reason.

Hmm no, it's not intentional... Both .mx_EventTile_line and .mx_ThreadInfo have a margin-right of 110px to allow room for the read receipts... but .mx_ThreadInfo is poking out of its parent box for some reason, so the margin isn't limiting the width properly... I'll see if I can spot a fix for this.

[jryans]

I'll see if I can spot a fix for this.

Looks like @t3chguy found a fix in parallel, so that should take care of it.

[t3chguy]

Vertical alignment for elements in the thread summary should behave the same way as thread summaries in the main timeline (the ones that Michael (t3chguy) recently fixed).

@janogarcia can you elaborate on this?

It is the only non-blocked point which is not tracked in another issue

[janogarcia]

@t3chguy Sure, we need to make sure we're applying the same vertical alignment properties/behavior for thread summaries in the thread list as those we defined a while ago for thread summaries in the main timeline. Ideally, we wouldn't need to define/update these styles in two separate places.

• Left (main timeline): correct alignment, that we fixed a while ago.
• Right (thread list): reply count and message preview are not sitting on the expected baseline (just the same issue we had for thread summaries in the main timeline).

[novocaine]

@janogarcia can you please confirm whether we have done enough here to close the ticket?

[janogarcia]

@novocaine @t3chguy

So, the only issue pending to be addressed is the infinite scrolling behavior. More specifically, the limitation of the current implementation (BACAT), that prevents us from ordering the scrollable events from top to bottom.

I’ve been thinking more about this lately and would like to share some updates:

• I’m dropping the requirement (I already checked it off) for the top-to-bottom alignment in the thread timeline (Align timeline to the top of the timeline container.), which is, by far, the less critical one. I’d even say that it can work almost equally well either with BACAT or TACAB scrolling.
• I still consider the case for the thread list to be relevant, though (Align timeline to the top of the timeline container.). We (the design team) would still want users to have scrolling lists where the items are ordered from top to bottom. That doesn’t only make sense for the Thread List but other contexts as well, like the Mentions/Notifications panel or the Files panel.

From a UX perspective, we can’t presume that BACAT scrolling will work and serve best every possible scenario and interaction need (e.g., we already use the top-to-bottom scrolling pattern in the room list on the left sidebar and the people list on the right sidebar, although not for infinite items).

We consider top-to-bottom scrolling a core interaction pattern worth the effort of solving. It surely has a considerable implementation cost, but it also has a similar or higher product/UX cost not having it.

Now, given that we want to reuse this behavior in different contexts (mentions panel, files panel), meaning it’s not a Threads-specific limitation but a core interaction issue affecting our product in general, I think we could move this requirement out of the scope of the Exit Beta milestone for Threads and handle it separately.

So, to recap:

• We are dropping the requirement for the vertical alignment of the thread timeline altogether.
• We’d still want to order the thread list from most recently updated on the top to oldest on the bottom. We would handle it separately from the Threads project, treating it as a global app enhancement instead.

What do you think?

---

/cc @nadonomy CCing you as per a previous internal discussion.

[janogarcia]

@novocaine @t3chguy Feel free to close this issue if you agree with the stuff above.

[t3chguy]

I still consider the case for the thread list to be relevant, though (Align timeline to the top of the timeline container.). We (the design team) would still want users to have scrolling lists where the items are ordered from top to bottom. That doesn’t only make sense for the Thread List but other contexts as well, like the Mentions/Notifications panel or the Files panel.

The ordering isn't an issue to flip, the issue is the potential for a gap at the top due to how BACAT reserves space to prevent scroll jumps e.g by the spinner coming up and going away.

TACAB scrolling has guaranteed scroll-jumps for lazily/infinite loaded lists as the spinner renders and then vanishes.

We’d still want to order the thread list from most recently updated on the top to oldest on the bottom. We would handle it separately from the Threads project, treating it as a global app enhancement instead.

Great, though would be good to clarify whether by

We (the design team) would still want users to have scrolling lists where the items are ordered from top to bottom.

You mean just flipping the order or TACAB which would trade scroll jumps for having no gap

Thanks

[janogarcia]

We want to be able to flip the order, top to bottom, with the first item being aligned to the top of the scrolling container, without any extraneous/additional white space on the top, as in the mockup below (a filterable/sortable list of items).

I'd also expect no scroll position jumps when interacting with the scrolling behavior. If the spinner is introducing the problem, then we could think of a slightly different design for it.

---

[t3chguy]

If we can replace the spinner with something that consumes no vertical space (to have to pop-in and out) then that would help

[t3chguy]

We can probably hack BACAT to remove the paging behaviour for the threads list, as long as we can turn the spinner/no-spinner into a constant height element. Like the old youtube top-bar horizontal animation which I cannot find a reference to atm

[janogarcia]

If we ca n replace the spinner with something that consumes no vertical space (to have to pop-in and out) then that would help

What if we did something like this?

Let's say Item 09 was already available on first load. Then, we'd draw the spinner over the existing content when fetching more items (Item 10 and up). Would that make it any easier?

[janogarcia]

Like the old youtube top-bar horizontal animation which I cannot find a reference to atm

Can't recall that one, but would to see an example.

[t3chguy]

Yup an overlaid loading state would work too, anything that doesn't cause the vertical bounce

[janogarcia]

Alternatively, we could just show an animated loading bar on the bottom that would only take up 2 additional pixels. We could just keep that 2px gap on the bottom even when the loader is inactive. We could live with that, even if not ideal.

We could also combine both for better feedback on what's being loaded, but it's probably getting a bit noisy.

[t3chguy]

https://www.cssscript.com/demo/youtube-top-loader/ the loading bar was what I had in mind, combining both is also possible

[janogarcia]

https://www.cssscript.com/demo/youtube-top-loader/

Thanks for the example! Yeah, basically the same stuff I suggested in the previous example. 👍

[t3chguy]

I just noticed Github has such a minimal loading animation also :D

[daniellekirkwood]

believe this is completed and can therefore be closed...

[janogarcia]

@daniellekirkwood Related internal discussion on BACAT scrolling and sorting.

That said, we probably don't plan to act on the scrolling implementation soon, so we may want to consider that as a standalone enhancement (affecting the threads list, but also the mentions and files panels) that we can separate from the Threads project, as suggested previously.

[daniellekirkwood]

Created an issue to keep track of the scrolling things here

Will now close this issue.