-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do away with "go to first unread". Instead, always open the first unread #1548
Comments
I would like to add something in support of this feature, but I think you just said what needed to be said, heh. In my opinion, and from I could gather, this feature is less confusing and leads to less actions needed for the user to make, whether they want to read everything they missed or if they want to dismiss everything directly. Like, if the current "dismiss bar" were a "jump to latest message" the user would take the same number of actions as now, but benefiting also users who would like to read everything (who wouldn't need to take any extra action, just scroll down while they read). i hope I was clear :) Edit: I confused this issue thinking it belonged to RiotX (which has the same problem). I'll leave the comment because I think it's still valid. |
If the button is removed, or its behavior changed from "first unread" to "first mention", then I hope the change is optional. It's common for me to walk away from my computer while in a channel, and return to find more than a screen full of new messages. A good chat interface would recognize that my desktop was idle in that time and therefore leave the new messages unread, with an obvious way to jump to the first one when I'm ready. The button is especially handy in that situation. Also, sometimes I enter a channel because I want to immediately see what was said most recently, and then go back and catch up on the earlier unread messages when I have more time. Again, the button is useful here, while auto-jumping to the first unread is not. |
Note that there are two pointers: m.read and m.fully_read. So it is possible for the up arrow to always jump to m.fully_read. Personally, I prefer riot-web to jump to m.read (instead of most recent) when switching to a room. However, if there is a need to jump to most recent or a mention then I think there should be a wait of around 10 seconds before setting m.read. That allows the user to click on the up arrow and jump to m.fully_read without m.read getting set to something the user didn't read. |
It should be trivial to provide the option for rooms to open at their readmarker rather than most recent message, by default. Surprised someone hasn't implemented it already. The default will continue to be to show most recent msgs though. |
See #1851 on how Telegram does this. |
An aside, but I've also noticed responding to the current unread being shown will remove the button allowing you to browse back to first unread... I suppose it is assumed that those other posts are then considered read. 🤔 |
Related to #1418 |
The same popular request has been made more recently for element-android, maybe it should be considered as a valid issue for element-meta? Anyway, even if it wasn't set as the default behavior, it would be a great improvement. |
Any updates? This is a common setting in other messengers, like Telegram. Related: element-hq/element-android#3036 |
Just wanted to add how important this is. It's hard to convince people to leave Signal for example for Element/Matrix when they are used to this feature which is so convenient. |
Right now, when you open a room, Riot shows the most recent post. This leads to confusing situations where it's hard to tell what's read and what's not.
The user also gets two navigation buttons: one to scroll up to the first unread message, and another to scroll down to the most recent message.
I would like to remove the "scroll up" button altogether and, instead, go to the first unread message when you open a room; then simply have a "scroll down" button that would:
The text was updated successfully, but these errors were encountered: