Update Direct Messages and Rooms headers from UI

[opusforlife2]

This issue is: Ready to build

Problem

What would you like to do?

Remove the Direct Messages and Rooms expandable headers from the DMs and Rooms tabs respectively.

Why would you like to do it?

It is annoyingly frequent that I accidentally tap the header and hide the chat list when I'm intending to open the top chat.

Moreover, I don't see the point of these headers. Not only are they buggy (switching the tab and switching back expands them again), but seemingly redundant. The title bar of the app already tells you which tab you have opened. The headers seem to have been copied from the Element Web UI directly, without an actual use case.

The only expandable header that makes sense is Invites, because you might get a lot at once, and want to hide them so you can focus on your existing chat list.

How would you like to achieve it?

I would like to see the 2 headers removed completely. The Invites header can have a distinctly visible UI boundary so that it's clear when the invites end and the existing DMs/Rooms start.

Solution

Based on our chat, here is the proposed solution. The changes I have made are:

• Created a band under collapsible /expandable headers
• Added no. of items in the list (similar to ios)
• Changed type style of header to make it clearer

Link to Figma file: https://www.figma.com/file/QugKzfgL4gISlsmluw9EVb/Change-expandable-headers?node-id=4%3A2593

Also, sections should only appear here if they have items in them.

[bmarty]

FTR: there are other possible headers: "favorites", "Low priority" and also "System alert". Depending on the tab, the sections are built here: https://github.com/vector-im/element-android/blob/main/vector/src/main/java/im/vector/app/features/home/room/list/RoomListSectionBuilderSpace.kt#L75

[opusforlife2]

Thanks. I just realised there is a long press menu for the chat list.

How about checking if there are any chats in the Favourites or Low priority categories, and choosing not to display the DM and Room headers if there are zero such chats? The headers could be created the moment a chat is added to either of the categories.

These two seem like the 'permanent' or 'long-term' categories. Invites and System alert will tend to be addressed within a much shorter time frame, so I don't think they will be as much of an issue.

[ouchadam]

when I first used element I found it a bit strange that the title items were collapsible, I would have expected that UX on menus or expanding text to show more information

I would be interested to know if many users would understand why their messages are missing in this scenario

[daniellekirkwood]

Meeting Notes

• The headers feel like navigation, should they be collapsible at all, or just separate tabs?
• Collapsing Invites and Low Priority is well used and should stay
• Visually, they could have better treatment
• What are the web IA changes and how would they impact this?
• Favourites needs to be collapsible because they're stuck to the top of the screen regardless of whether it was the most recent messages
• Each section has a badge associated, so if a Low Priority room has an unread message then you'll struggle to find it with a long Rooms list
• If a section is empty, it does not show in the list

Next steps

• Discuss longer term IA changes with Delight team @daniellekirkwood
• Keep Invites, Favourites, Low Priority, System Alerts as expand and collapse but continue to discuss removing Expand/Collapse for All DMs or All Rooms sections
• Quick visual fixes to be proposed by @amshakal, including looking at tappable areas

Questions

• If there's only one section, can we remove the header altogether?

[amshakal]

Based on our chat, here is the proposed solution. The changes I have made are:

• Created a band under collapsible /expandable headers
• Added no. of items in the list (similar to ios)
• Changed type style of header to make it clearer

Link to Figma file: https://www.figma.com/file/QugKzfgL4gISlsmluw9EVb/Change-expandable-headers?node-id=4%3A2593

[daniellekirkwood]

I have updated the content of the issue with the feedback from Amsha and removed the Needs-Design and Needs-Product label as this issue is now Ready to be built.

[mnaturel]

Hi! I would to like to fix this issue but I don't clearly understand what should be done in term of UX. For UI, it seems okay since there is a link to Figma. Can someone sum up the expected behavior (visibility, expandable or not?, etc.) about the header sections depending on the different cases ?

[daniellekirkwood]

@mnaturel Heya!

• All sections should be expandable/collapsible
• Sections are only visible if they have content

@amshakal to confirm

[amshakal]

^ Just what @daniellekirkwood said

[bmarty]

That's fine, but what @daniellekirkwood has said is already implemented no?

[mnaturel]

That's fine, but what @daniellekirkwood has said is already implemented no?

Indeed, this is the UX which is currently implemented. But UI has been changed and there is a counter of number of items added into the headers.

[mnaturel]

Hello @amshakal @daniellekirkwood, when editing UI headers as specified, I have realized we already have a red notification counter as well (see capture below). Are you aware of this notification counter (it does not appear on the Figma screens) ?
In my opinion, with this design, it may be confusing for some users about the meaning of each counters.

So my questions are:

• Is the number of items counter really needed ?
• If this counter is really needed, should we stay with the same design ?

[amshakal]

Hi there, thanks for working on this. The rationale to keep the counter is so that users know there are items under that list if the section is collapsed, there could be a scenario where the user thinks there is nothing inside that section otherwise. This also helps us have parity with iOS.

The main change we were proposing was to make the headers more prominent (with a grey band and with a more distinctive text style)

Was aware of the notification badge - didn't account for it in the designs since the behaviour wasn't changing. I believe the colour of the badge should be grey or red based on the type of notification they receive?

[mnaturel]

Okay, thanks for the reply. Yes the badge is indeed either red or grey.

[amshakal]

Another thing we can do to avoid users getting confused by different numbers is move notification badge to the right to match notification (unread counter) per room

Ref: #4640

[mnaturel]

It is a good idea! I will try moving it to the right to see how it renders.

[mnaturel]

Hi @amshakal , I have implemented the required changes. Can you review if the design is correct? I have added some screenshots in #5181. Also, ask me if you need to see the behavior of the app.