element-hq
The Room Topic
Following the release of the newly designed Room Header we have received some feedback on the removal of the room topic from the room header. This feedback is often intertwined with other pieces of feedback on this change and so I am creating this issue just to track Room Topic Access feedback
If you have feedback on the removal of the room topic from the room header, please leave your thoughts below.
- Please be kind
- Please give as much detail as you can about the problem you are experiencing as a user
It is unlikely that we will consider moving the topic back into the room header as it was before, that doesn't mean that other options to up-level the room topic are not available - they are! Let's collect some innovative ideas for how we can solve the problem. If other products do this well, please leave a screenshot for us!
Thank you
Thanks for breaking this out.
For me both stages of the removal were a net negative.
In our team, we use lots of rooms. Some of them with external teams, that every individual might only visit once in a blue moon. The topics there (including the ability to use markdown) were extremely helpful to provide quick information about context in this room: where's the bug tracker, which jitsi link are we using here, special stuff, etc.
It was small enough to not annoy regulars, easy to discover with little screen estate that helps the occasional users and didn't need to click buttons that need to be aimed for and move while using: if I press the (i) button to show the info, the button will move away, so what happens is that
- i have to aim for the i button
- click the i button
- find the focus for the info text that is now in the middle of a larger pane somewhere
- aim for the i button because it has moved
- click the i button
All the while the text in the window gets rewrapped and I have to refocus on the original conversation.
To me, I'm not sure what my benefit is now ...
The "Solus" Linux distribution started using Matrix as a chat platform (instead of IRC) last year after refreshing/restarting its infrastructure. One thing that both platforms had in common was the room topic, which the rooms make use of to provide important information to the users, packagers and developers. These include:
- Links to Help Center, issue reporting page and issue tracker in the "Solus Support" room
- Quick links to several tooling and package repository GitHub pages in the "Solus Development" room
- Date and time of the last synchronization between Stable and Unstable repositories in the "Solus Packaging" room
- Recent important package changes in the "Solus Packaging" room, informing about stuff that should be tested and/or could be problematic (kernels, libc, etc.)
Most importantly perhaps though is the info regarding the status of the Unstable repository in the "Solus Packaging" room. This prominently displays (or used to prominently display) whether the repository was currently frozen, so people with commit rights don't immediately push their changes while either major updates or a synchronization between the repositories was going on. Additionally it informs users of the Unstable repository on whether it's currently safe to update, with a big "DO NOT UPDATE" notice when it's not. All the guidance for Unstable users mentions this important fact to avoid unnecessary support cases. Requiring users to click on the top bar or little info button is one additional step that stands between them and crucial information. This will inevitably lead to people forgetting to check the status before updating and potentially bricking their systems. I know even I personally sometimes forget to activelycheck the topic, even though I'm intimately familiar with the system, and have been saved by an incidental glance at the room topic multiple times. Something that is not going to happen with the new, hidden way to access it.
With IRC one at least had the topic printed out on (re-)joining a channel, so it was in view even if your client was configured to not show it in a top bar or similar. Due to the always-connected nature of Matrix something like this is unfortunately not an option.
Honestly, I don't fully understand why the room topic was moved to the sidebar entirely. It doesn't seem like it would waste any screen estate to at least show a truncated room topic in the top bar. This would enable people to at least put the most important information there and serve as an indication to users that there is something there. Apart from that I unfortunately don't have a great idea on how to present it (I'm not a UI designer), but anything that completely hides it by default is suboptimal.
Something that might come up would be to put some sticky messages somewhere. However, I would expect this to take up even more screen estate than the unobtrusive topic did.
Something I haven't been able to quickly find out - maybe @daniellekirkwood can provide a pointer - is the reasoning why this had to go away ... what is the benefit that was assumed here?
Thank you for creating this issue. One recurring piece of feedback we’ve received concerns the auto-hiding of the room topic. We currently embed Markdown links that are rendered using the feature_html_topic experimental feature. Users have reported that the auto-hiding behavior makes important links less accessible and have requested options to configure this behavior, whether at the client config level, room level, or user level.
Something that just happened to me for the Nth time: as I now have to click the header icons over and over to get to links in the room topic, every now and then I open up a video call and have to close it again. This confuses everyone in the room. Unfortunately - not fun.
The room topic was valuable information, and I've already caught myself asking questions in a room that I had not asked had the room topic linking to the FAQ been visible.
If as you indicate moving the topic back in for the general case is not an option, would you consider giving users and/or room admins the option to show it in there for rooms that explicitly opt in to it, or have a short version of the topic (say, more button-like, a la badges of READMEs) visible?
I've tried doing this manually by giving a room a name like $PROJECT infrastructure [FAQ](https://...) [issues](https://...), but that's a) impractical as the links would clobber the room list, and b) doesn't work because no Markdown is accepted there.
Looking at simplistic matrix clients like ement or gomuks what are the most important information: It's the
- messages (who wrote what when),
- the room name
- and the topic
Not only is the topic not always visible, but hidden inside a tab of the sidebar and possibly ellipsed. So worst case it takes three clicks to see the full topic:
- activate the sidebar
- select info tab
- expand the full topic
I don't mind having the topic on the sidebar, but it should be a bit more accessible.
Reposting some relevant comments from the issue that spawned this issue so they don't get lost:
The topic is entirely gone from the header, that just hasn't been released yet, you can try it at develop.element.io - it lives in the right panel now.
... I really hope this gets reconsidered. In my experience, people often don't read room topics even when it's right in their face (i.e. viewable in the room timeline view with no extra clicks); I imagine hiding the topic behind extra mouse clicks and a closed-by-default sidebar will make this problem much worse.
— https://github.com/element-hq/element-web/issues/27902#issuecomment-2271464048
The topic is entirely gone from the header, that just hasn't been released yet, you can try it at develop.element.io - it lives in the right panel now.
Room topics are often very important to communicate about what discussion is on-topic for a given room, and what kinds of behavior are allowed. As a moderator in a relatively large room, removing the room topic from the header would be highly undesirable for me, and I expect this change to result in an increase in moderation work. Ideally, I'd like it if the room topics were more prominent in the UI than they were before this change.
If it's likely to be taken into account for decision making, I could collect some statistics on how often people are redirected based on information visible in the room topic before and after this change.
— https://github.com/element-hq/element-web/issues/27902#issuecomment-2272740494
It is unlikely that we will consider moving the topic back into the room header as it was before
I'm curious what the rationale for changing it and sticking with this change are.
that doesn't mean that other options to up-level the room topic are not available - they are!
Perhaps showing a popup when joining a room with the contents of the topic overlaid on the timeline that must be dismissed before one can send messages, and showing the popup again each time the topic changes. Maybe even requiring scrolling to the bottom of the popup contents before being allowed to dismiss it.
If other products do this well, please leave a screenshot for us!
FWIW, Slack, Discord, and Zulip all display the topic in their equivalents to a room header.
With the latest element version's pinned messages I've explored those as a replacement. Sadly, those don't cut it: Room topics were used (in all rooms I'm frequently visiting, all revolving about embedded development) to convey links to common resource, such as FAQ, issue tracker or a planning pad.
Apart from taking up more valuable screen estate than the old topics did, pinned messages have a serious regression when used as a topic replacement: While they do support markdown, links in them can not be clicked, neither when they are just URIs (as they often were in topics) nor as proper links.
Apart from taking up more valuable screen estate than the old topics did, pinned messages have a serious regression when used as a topic replacement: While they do support markdown, links in them can not be clicked, neither when they are just URIs (as they often were in topics) nor as proper links.
The same for me. The cause here seems to be that a "click" event causes the pinned messages to rotate and also the link isn't rendered as a link.
Also if one edits the pinned message, then it only gets updated when switching the focus to another room and back.
The screen estate is definitely more than we previously had to give up, but then it's also a bit more visible. I'd be ready to make this trade off if the other stuff works.
Has this been entirely abandoned? Even the feature flag for it has been disabled?
I was using a combination of feature_new_room_decoration_ui=false and feature_html_topic=true, which worked great:
But in the newest version ~~it doesn't do MD->HTML rendering~~ and doesnt show the topic at the top anymore:
EDIT: It still does Markdown rendering, I was mistaken.
Even the feature flag for it has been disabled?
The old room header code was deleted when the Product team released the new one.
But in the newest version it doesn't do MD->HTML rendering and doesnt show the topic at the top anymore:
The MD->HTML conversion happens at the sender side, HTML topics are rendered from HTML source, not from MD source.
And it works just fine here
Even the feature flag for it has been disabled?
The old room header code was deleted when the Product team released the new one.
But in the newest version it doesn't do MD->HTML rendering and doesnt show the topic at the top anymore:
The MD->HTML conversion happens at the sender side, HTML topics are rendered from HTML source, not from MD source.
And it works just fine here
Ah the topic was not re-applied after migration on our staging environment and therefore it was still plaintext instead of rendered markdown. You are right in that this still works.
Just unfortunate that there is now way to keep the topic shown in the top bar, I guess.
For me this used to be a vital source of information for visitors of the chat channels. Having to open the "room info" side-panel manually is just not a viable replacement. Imagine knowing nothing when you enter the chat, and having to go from "look up" to "look up, see three dimmed icons, figure out what they mean, click on the right one, then read the info".
Even when the info was in the header, people often missed it. Imagine how many people will actually understand that important information is hidden behind a dim "i" button.
I have a few questions:
- If this is coming back (potentially as an optional thing), is there any indication as to a time span? Because this is actively hindering the chat channels I'm running.
- If this is not coming back, is this something we can reintroduce via a custom extension?
- And if that is also not possible, how would you suggest we provide info like "the latest meeting notes", "date of the next meeting", "link to the FAQ", etc.?
The MD->HTML conversion happens at the sender side, HTML topics are rendered from HTML source, not from MD source.
This doesn't seem to work in the Element app on macOS (version 1.11.85) though. There the topic just shows as plain MarkDown text, even when I edit it and re-save.
is this something we can reintroduce via a custom extension?
Forks are always welcome
is this something we can reintroduce via a custom extension?
Forks are always welcome
That is not an answer to my question, though. I was asking whether something is even possible, not how to contribute such improvements back to the project.
It really worries me that this thread is filled with motivations for bringing back the room-topic-in-the-header feature. Yet after months of very similar feedback, there is no indication at all whether this is even being considered at the moment.
I was asking whether something is even possible, not how to contribute such improvements back to the project.
Yes it is possible to make such a modification, but if the Product team don't want it upstream then no it would not be possible to contribute it back to the project.
The Product team explicitly removed the topic from the header, I would not expect it to be coming back as that is quite unlikely, though I am not the product team.
The Product team explicitly removed the topic from the header, I would not expect it to be coming back as that is quite unlikely, though I am not the product team.
Then can we get the Product team in here to discuss with us? Because having this as an open topic, with lots of good motivation why the feature is useful to bring back, is kind of misleading when there is nobody looking at it who can actually make a decision here.
The label X-Needs-Product is already asking for that, it'll be somewhere on their everlong backlog.
Is there a public document that describes the motivation behind the removal of the info from the room header? So far I can only find very non-descriptive PRs, and a dead link (which I assume goes into a non-public place I have no access to).
The label X-Needs-Product is already asking for that, it'll be somewhere on their everlong backlog.
Given that there's so much pushback against this change, from so many different people, who all have clear & valid motivations, is there something we can do to speed this up? Maybe it's time to say "this is more controversial than we expected, let's roll back the change and take the time to come up with a better solution"?
At the end of the day, the Product team make decisions based on customer feedback, less so community feedback. So if any customers here feel the way the community do I suggest making feedback through the business channels as that will have 1000x as much impact
At the end of the day, the Product team make decisions based on customer feedback
There can't have been customer feedback that was a hard "remove the room topic from the header". Usually such feedback is more like "we don't want to see the room topic in the header". It's up to the product team to decide how to implement that. All I'm saying is that it could have been a toggle to keep the feature available for those who want it. I don't see how any customer would be against such a thing.
So if any customers here feel the way the community do I suggest making feedback through the business channels as that will have 1000x as much impact
Ok, so this is basically a :middle_finger: to the Open Source community. Clear.
Ok, so this is basically a 🖕 to the Open Source community. Clear.
Not at all? The project is still open source so you always have the ability to make whatever modifications you like. The license allows it as long as you keep them open source. Where modifications align with production vision then they are accepted upstream.
Its not a design by committee project
I wouldn't describe it in drsybren's words, but "just fork it" doesn't work for most of the users here. This is not just laziness of users who want to avoid self-hosting a fork. It's worse because those troubled by this issue are room operators who may not even use Element themselves, but the members of their rooms often do, and it's those room members whom a room topic is set for.
The impact of removing topic visibility is thus not just on Element users (who are of course free to switch), but on the Matrix ecosystem in general, because all of a sudden a widely communication channel is made inaccessible to a large user base.
The comments above establish the topic's importance and why merely hiding it was likely incorrect. The core issue seems to be the UX, not the persistent text itself, given pinned messages are now proposed as a replacement. Could we restore the topic's utility by handling it as if it were a pinned message?
