RightPanel navigation is unintuitive, especially with threads

[ara4n]

Steps to reproduce

While dogfooding threads I'm finding the RightPanel behaviour very unintuitive. Problems include:

• While I may be interested in the threads on one room, i might be interested in something else (members, widgets etc) in another room. I think the RightPanel should remember the setting for each room, rather than it being a global.
• Pinned Messages lacks a back button on the RightPanel, and doesn't get linked from the RoomInfo panel.
• In terms of IA, It's strange that some of the RightPanel options from the topright buttons take you to a child of the RoomInfo panel specific to that room, but some of them are global in scope (e.g. Notifications). Buttons which are room specific should be grouped together somehow - or perhaps we could even show that they are conceptulally children of the main (i) info icon? We have repeatedly seen that users ignore the buttons on the topright (unless they show badge notifications to remind the user they exist, for things like notifs).

[SimonBrandner]

I also think a big part of this is #17376 when looking into spaces

[ara4n]

ah yup, 100%.

[ara4n]

To clarify on the whole "should threads stay open when you change rooms" thing:

• Our current IA trains the user to see the RightPanel as specific to your current room. (The whole UI from left-to-right gets more specific as you drill down into a space->room list->room->rightpanel).
• Therefore it's unintuitive when the rightpanel starts telling you about stuff which is nothing to do with the room - e.g. space members for some random space.
• You also expect the RightPanel view to remember where you left it as you switch between rooms.

Now, if you want to have a thread visible while switching between rooms, i think we need a separate mechanism to pin that thread in a PIP much as we do for voice/video conferences. (Or alternatively threads could be those in the first place, rather than being in the RightPanel).

[SimonBrandner]

Therefore it's unintuitive when the rightpanel starts telling you about stuff which is nothing to do with the room - e.g. space members for some random space.

Though, I think it makes perfect sense to show space members when exploring rooms of that space, just not to miss that case :D

[nadonomy]

To add to this comment, I'd like to to advocate heavily for us to figure out how to let Threads persist when switching rooms:

• It's my lived experience from years of using Slack, and I suspect lots of other peoples too
• Often I'll open a thread, and to reply to it I need to look at other rooms to check or ask things

I realise in today's model (and proposal) threads are effectively children of specific rooms, but I'm struggling to use them in practise.

@daniellekirkwood @janogarcia let me know if you'd prefer me to file an adjacent, explicit, issue for that request!

[ara4n]

I'm also struggling to use threads much in practice (finding it very hard to know when psychologically to start a thread rather than a reply, especially when reply is hardcoded muscle memory), although lack of notifs are a big factor there.

Separately: we have worst of both worlds currently when switching rooms - if you look at threads in your current room, you then get shown in the new room if you switch room (even if you don't care about them). I think the right solution here would be to give a way to pin threads outside of the RightPanel if you want to keep them around as you flit between rooms, tbh.

[daniellekirkwood]

Thanks for the comments!

@nadonomy Yes, let's create an issue that is Threads specific and talks specifically to the use case of how to persist a chosen thread in the right panel (it might well be Matthew's idea of Pinning, but let's not put the solution into the problem). This is not something that will be in the MVP/P0 version of Threads but is something we can definitely look into.

As for the rest of this issue, @janogarcia has a great breakdown so I will let them respond to address the rest.
Jano, can you post here as a comment what you have written in Element this morning?

[frandavid100]

I'm also struggling to use threads much in practice (finding it very hard to know when psychologically to start a thread rather than a reply)

I really think that there shouldn't be a "thread" button and a "reply" button.

Instead there should be a single button, which should always add your message to the thread; and it should show it on the main TL, or not show it, based on different factors which could also be discussed.

[SimonBrandner]

I really think that there shouldn't be a "thread" button and a "reply" button.

Instead there should be a single button, which should always add your message to the thread; and it should show it on the main TL, or not show it, based on different factors which could also be discussed.

Replies and threads have different purposes. You might have a preference for one thing but I don't think everyone will feel the same way about it, so condensing both into one feels like a not so great idea... This also feels like a separate issue

[frandavid100]

Replies and threads have different purposes.

I don't think that replies have any purpose that can't be covered just as well by threads.

This also feels like a separate issue

I don't know. I just brought it up because Matthew said he wasn't using threads much because it's hard to decide whether to use a thread or a reply. My point is the user shouldn't even need to make that decision.

[janogarcia]

We’ve been discussing internally most of these issues regarding the right panel. It's clear that it's in need of a major overhaul.

As for the threads panel, it hasn’t introduced any new behavior to the right panel, it’s basically following the existing conventions for it, and by doing so it’s making more evident the current design flaws of the right panel: the back navigation button’s behavior, the panel status persistence behavior when switching rooms...

I’m sharing here for reference the immediate plan of action for the Threads P0 epic that we discussed internally. We can explore more in-depth other issues and implementations outside the scope of Threads P0.

• Ideally, keep track of the status for local, room-level panels. Local panels include the Room Info panel and the Threads panel. This way when opening a thread in a room, switching to a different room, and then going back to the first one, the thread will still be there.
• Only global panels, if any, can persist their contents across rooms. We have only one global panel, the Notifications panel. That said, it’s currently barely usable as it can only show mentions in unencrypted rooms, so we could even consider not persisting it for now, and thus minimizing conflicts with any open local panel, like threads.
• Update the labels for the back button’s tooltip to indicate the specific navigation destination. “Back” is ambiguous as you can’t tell in advance if it traverses navigation history (what most people will guess given the label) or the navigation hierarchy tree (what’s actually happening). Optionally, we could explore labeling the back buttons, instead of relying exclusively on tooltips.
• Allow for hierarchical navigation to the User Profile view from multiple contexts: Thread context Thread list → Thread detail → User profile, and room info context Room info → People list → User profile. Otherwise, users get trapped in the user profile view when accessed in the context of a thread.

[daniellekirkwood]

Meeting Notes so far: https://docs.google.com/document/d/1ENSeqSjSjbC4yMdwIrRe-pomP9qV6j8AP5Hwv05iOxE/edit?usp=sharing

[skolmer]

We as widget developers are very excited about this new maximized widgets feature. Thanks for making this happen!
In our test we also experienced some UX inconsistency with the sidebar messaging but I think it is already covered in one of the previous comments so I don't want to repeat it.
What I want to ask though: Is it planned to persist the maximized widget state in the io.element.widgets.layout event?
If you create a room just to hold a video call it could be a very useful feature if the moderator of the room could prepare the room layout so that jitsi is maximized by default.

[toger5]

@skolmer sorry for reading this just now. But yes this is the case. You can use the "set room layout for everyone" button (if you have permission to do so in the room) and it will also apply the maximised layout.
The sidebar is beeing refactored and can be tested with the netlify link at the bottom of this PR.
It is very welcome to get tried out and gets feedback in places, where it does not work!

[janogarcia]

@daniellekirkwood Adding some relevant comment from a recent discussion with @toger5.

Timo suggested a model where "if the right panel is open each change that triggers the right panel will just be appended to the navigation history" and "if the right panel is closed and the right panel is triggered by some ui action a default history will be created and set to the right panel:".

I'm copying my feedback and recommendations below:

---

I’ve been thinking a lot on these and many other workarounds for the current right panel behavior. I wouldn’t recommend tracking the history as proposed (i.e. keep track of all history if panel is open, reset history once it’s closed).

There’s no easy way back home

That’s my main concern when taking that approach.

The room header buttons toggle the right panel, those won’t take you to each section initial view (as it happens for example in the navigation bar of a mobile app).

For example, if the right panel is already open showing a user profile and then you click on a thread summary in the main timeline, the thread replaces the user profile view and the back button will be pointing to that user profile you were viewing.

Now, if you need to navigate to the thread list you’d need to, unintuitively, click on the thread icon in the room header to hide the thread panel and then click on it again to display it in its default state.

Benchmarking

There’s plenty of examples of products that have faced exactly the same limitations when trying to handle all the sidebar contents with a single container: Slack, Rocket.Chat, Mattermost, Flowdock, Chanty…

An example of an app that’s taking a different approach is Discord. They circumvent the limitations of a single, shared right sidebar by separating concerns and using independent, floating containers (i.e. popover windows and modals) for each area: Mentions and Unreads, Pinned Messages, Threads, User Profiles...

Short-term solution

As I suggested in the original discussion on the current right panel issues, we should focus — at least in the short term — on mitigating the most pressing ones and handle those one by one.

I know it’s not an ideal solution, or an elegant one to implement and maintain.

My current recommendation is to keep using/traversing the hierarchical navigation tree as much as possible, so that you can always easily reach the initial state for that panel by going up in the hierarchy.

So, for example you can always traverse this navigation path in both directions:

Room info > People > User profile

For the particular case of viewing user profiles when in the context of a thread, and then be able to go back to thread, we could handle it in two different ways:

• Hierarchically: The original solution I suggested. A hardcoded, hierarchical navigation path Threads → Thread → User profile (in sidebar) that works forwards and backwards in a predictable way.
• Modality: A different approach that could also work is showing the User profile in a modal window (or bottom sheet) Threads → Thread ··· User profile (modal), so that the user profile panel doesn’t replace the contents of the Thread panel, and it doesn’t interfere with its navigation path.

Long-term solution

As suggested in the original discussion we should explore alternative approaches as part of a larger redesign of the app navigation and architecture, but those changes are more involved and far reaching than the current scope for the Threads P0 milestone.

We could explore making use of detached containers ala Discord (popover windows and modals), or maybe consider tabs (or stacks) so that we have more than one sidebar container/slot that can coexist without stepping on top of each other.

[janogarcia]

@daniellekirkwood Also relevant to this discussion: recommended labels for the Back button.

matrix-org/matrix-react-sdk#7398 (comment)

[janogarcia]

@daniellekirkwood @nadonomy

Forgot to add another approach worth mentioning as a long-term solution, which should be relatively easy to implement now that @toger5 has added support for tracking per-room right panel navigation history.

Problem

The core issue with the current navigation model for the right panel is that the back button is trying to handle both hierarchical and history navigation, which is never going to work, as those will always end up clashing, leading to:

Easily broken right panel history

As long as you interact exclusively with actions contained in the right panel, a back button that tracks history makes sense (i.e. every new state of the panel was triggered by the immediately preceding state), but as soon as the panel state is modified in reaction to an event happening outside of it, the back button history will be kind of broken.

For example, clicking on an avatar or thread summary in the main timeline will reset the back button history and make it work hierarchically — because otherwise there wouldn't be an "easy way back home" as explained below — and thus we're breaking the contract for the back button, which sometimes would be pointing to the history but under some other circumstances would be pointing to a hardcoded navigation path (hierarchical).

There’s no easy way back home

As mentioned in my previous comment, there's no optimal way to get back to the initial state for each section (e.g. reaching the Thread List when viewing a Thread, or the Room Info when viewing a User Profile...) or traverse the hierarchy (e.g. going up in the Room Info navigation path Room Info > Members > User Profile when viewing a User Profile) if the back button can only track history and we have to rely solely on the room header buttons.

The room header buttons toggle the right panel, those won’t take you to each section initial view (as it happens for example in the navigation bar of a mobile app).

Solution

A possible universal, long-term solution that works for any context.

By separating concerns for historical and hierarchical navigation we could avoid such clashes altogether, and effectively address all the issues above, in a scalable and future-proof way (i.e. without needing to hardcode a lot of exceptions and interdependent navigation paths).

A relative easy implementation would consist of:

• Simple, compact breadcrumbs on the panel header for traversing the current panel hierarchy tree. We'd only need to display the first and last level, and everything in between could be collapsed into an overflow item (e.g. as in the breadcrumb for Apple Developer Docs). Alternatively, we could use a dropdown menu instead of a breadcrumb, but that takes an extra click, it doesn't help with discoverability either as much as the breadcrumb, and relies more on recall than recognition.
• Make the back button always track history of the panel, which only gets reset on closing the panel (just as it would happen on a browser tab).