Skip to content
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

Difficult to avoid messages getting marked as read #10886

Open
WesleyAC opened this issue Nov 24, 2018 · 27 comments · May be fixed by #16313
Open

Difficult to avoid messages getting marked as read #10886

WesleyAC opened this issue Nov 24, 2018 · 27 comments · May be fixed by #16313
Labels
area: left sidebar (ui) Left sidebar buttons/interactions excluding popovers area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) difficult Issues which we expect to be quite difficult post release Issues to focus attention on after the current major release priority: high UX UX improvements to an existing workflow.

Comments

@WesleyAC
Copy link
Contributor

WesleyAC commented Nov 24, 2018

There are several things about Zulip's UI that make it hard to avoid messages getting marked as read (or at least, make it feel this way - I am unsure of the exact semantics of marking messages as read). This is related to, but distinct from #5462 and #2676. Specific problems that I have:

Main page/All messages UI

When I load the main page, it defaults to the "All messages". At first, I thought that this loaded the next unread message. This is incorrect - it loads the last read message, AFAICT. However, if I inadvertently scroll down on the main page, it will being to mark messages as "read". This forces me to either read them then (often without the context I want), or to ignore them, and risk missing things.

Fix:

Either by default or with an option, replace the main page with a page that shows something more like the mobile Zulip default view. That is, a list of all streams with unread messages, and the title of all topics in each stream (with the number of unread messages next to it). This solves two problems:

  1. It would prevent me from being stressed about accidentally marking messages as read when I load Zulip
  2. It would allow me to see the titles of new topics in streams that I don't want to click on, due to "Streams with unread messages" (below)

I don't know anyone who finds the "All Messages" view useful, and loading it stresses me out due to the number of times I've inadvertently scrolled and marked a message as read by mistake.

Streams with unread messages

Clicking on a stream on the left hand navbar results in a message from that stream getting marked as read. AFAICT, it's the oldest message, which makes this worse - I often have things that I want to respond to, but need to spend a fair amount of time on, so I keep them unread. Once that becomes the oldest thing in a stream, I can no longer click on the stream in the left hand nav, because doing so will result in the topic or message that I want to reply to being marked as read.

Fix:

By default, highlight the most recent read message when clicking on a stream in the left hand nav. Add an option to make clicking on a stream leave the main view blank, but show the list of topic names in the stream.

Private messages

When someone sends me a private message while I have unread private messages, IIRC clicking "Private Messages" on the left nav will mark my oldest private message as read. This is often undesirable. The workflow that I have now is - if I have unread PMs and see that someone has sent me a PM (but I want to leave the old PMs unread), I look at who sent me the message in the popup notification, and search for their name on the right hand nav and click on it, so that it will narrow to just that PM. This is not a great workflow, particularly when I didn't notice the notification, and need to scroll through the entire right nav to see who has a number badge next to their name.

Fix:

Clicking on "Private Messages" in the left nav should highlight the last read message not the last unread message. Additionally, there should be an option to make clicking "Private Messages" show nothing in the main page, but instead simply expand the list of recent people. I would vastly prefer this UI, but understand that it might annoy some people, hence the suggestion for an option.

@WesleyAC
Copy link
Contributor Author

WesleyAC commented Nov 26, 2018

Another one of these I noticed today:

When I have my private messages selected, the list of people who I have PMs with goes off the screen, and I cannot scroll down (possibly a separate bug? edit: #1991). So to see anything that isn't a private message, I have to click "all messages", which marks my oldest unread message as read (really not what I want). I guess I could also either close zulip and open the main page again, or type stream:something into the search bar, but I usually don't think to do either of these things.

@timabbott
Copy link
Sponsor Member

@WesleyAC thanks for the feedback, it's helpful! The reason we originally designed Zulip this way was for consistency -- if you click on a stream where all the messages ever sent are unread, for example, we have no message to highlight. I think it was a mistake, but inconsistent behavior leads to its own problems, and at least the current behavior is consistent and correct.

I have been planning to eventually move Zulip to "highlight last read message", but that model adds some significant complexity (e.g. in places with only unread messages, in order to achieve this, we need a way to have the selected message be in a special area off the top of the feed, even if there are unread messages present).

This is a larger project which is unlikely to happen without a skilled contributor motivated to make it happen; the key piece that would unblock my spending time on this transition is someone doing the work to make having the selection on the top-of-feed area (the thing with the black "Z") work. (A potential semi-workaround is to star messages you didn't want marked read, but obviously that's not a happy solution.)

@timabbott timabbott added priority: high difficult Issues which we expect to be quite difficult labels Nov 28, 2018
@rishig
Copy link
Member

rishig commented Nov 28, 2018

Completely agree with your characterization of the problem!

Either by default or with an option, replace the main page with a page that shows something more like the mobile Zulip default view. That is, a list of all streams with unread messages, and the title of all topics in each stream (with the number of unread messages next to it).

This is my favorite solution so far.

@WesleyAC
Copy link
Contributor Author

Thanks for the response, @timabbott! Great to hear that this is being thought about and worked on, and I appreciate the context on why this is difficult :)

Regarding the solution of making the main page more like the mobile version - is that something that is more feasible? Should I create a separate bug for that?

Thanks!

@timabbott
Copy link
Sponsor Member

timabbott commented Nov 29, 2018

There's definitely an issue around somewhere for that, and it's also on our potentially high-value large projects radar, so need to do that.

@gnprice
Copy link
Member

gnprice commented Mar 2, 2019

Here's another experience that falls under this issue's title:

Search results

When I do a search, I'm typically looking for a specific old conversation I have in mind. But if I have unread messages and some of them happen to match the search query, they show up in the results... and then scrolling through the results to find the conversation I want goes and marks those messages read, which may be scattered across a wide range of different conversations.

If I don't want to risk completely losing those conversations (i.e. never becoming aware of them, because they got marked as read before I looked at them), this means I have to carefully inspect all the messages I'm scrolling past, watching for unread markers, making sure to spot them before they disappear.

Doing that is pretty much incompatible with a high-quality search experience -- I'm spending more effort preventing the search flow from causing me data loss than I am actually looking at the results I was looking for.

The simplest fix would be to make a search narrow simply not cause messages to get marked as read. I think I do pretty much never want messages to get read by virtue of seeing them in search results -- I only ever want that when reading in a more coherently threaded context. Not sure what to do about showing unread-markers (which then don't go away, unlike in other narrows), or not showing them (making it look like they're all already read, which could be misleading or confusing.)

@rishig
Copy link
Member

rishig commented Mar 2, 2019

Agreed that we should just not mark messages as read in search.

@rishig
Copy link
Member

rishig commented Jun 6, 2019

Is it worth opening another issue for "don't mark messages as read in search"? That and mobile unreads view can be independent efforts.

@gnprice
Copy link
Member

gnprice commented Jun 12, 2019

Is it worth opening another issue for "don't mark messages as read in search"?

Hmm, I'd say that answering that question, and then acting to make the issue tracker be the way you think it best for it to be, sounds like something you should feel empowered to just do. 😉

In any case, I went and cloned that bit as a new issue: #12556

That and mobile unreads view can be independent efforts.

Do you perhaps want to have an issue for that effort, too? (Or find an existing one and link it here?) An earlier comment asked about that, too:

Regarding the solution of making the main page more like the mobile version - is that something that is more feasible? Should I create a separate bug for that?

This issue's title and description are about a problem, not a solution, and I count at least three different solutions discussed above for different aspects of the problem. If you want to turn this into the thread for that particular solution, that's also up to you, but I'd recommend making that explicit.

@timabbott
Copy link
Sponsor Member

For mobile unreads view, there's #11994 open.

@mlncn
Copy link
Contributor

mlncn commented Jun 18, 2019

See also #12518

@amartin3225
Copy link

I would also find an improvement in this behavior very useful for my organization, particularly with private messages. Clicking on "Private messages" should not mark any messages as read - as noted above this allows you to leave a certain conversation as unread until you are able to respond to it, but continue to respond to a different conversation that is in progress.

@amartin3225
Copy link

I have another important use case to add to this ticket - if a user has the Zulip window maximized on a high resolution display and has unread private messages from several users (e.g. more than 3 different users), clicking on "Private messages" causes ALL of the messages from all of the users to immediately be marked as read (because the display happens to be large enough to display all of them at once). This makes it very difficult to note which users had unread messages that you now need to review or to selectively choose to look at some of them now but not others. I confirmed that if you make the Zulip window smaller, this behavior does not occur. Can this behavior be changed as part of this ticket, e.g. would the "highlight last read message" behavior mentioned above cause it to NOT mark any of these messages as read?

@amartin3225
Copy link

Another use case to add - with Zulip in the foreground, it will often automatically scroll down and mark messages as read when the Windows computer is locked, which is undesirable

@timabbott
Copy link
Sponsor Member

Another use case to add - with Zulip in the foreground, it will often automatically scroll down and mark messages as read when the Windows computer is locked, which is undesirable

That certainly shouldn't happen! The logic is very carefully written to not scroll down more than a screen without user input. My guess is there's some sort of bug that's triggering a "scroll_to_end" event, potentially a resize event triggered by a change of monitor or similar, if one's only seeing it on lock/unlock?

@Gittenburg Gittenburg added the UX UX improvements to an existing workflow. label Jul 9, 2020
@N-litened
Copy link

This is definitely a major issue for me, and the opposite of “don’t miss an important conversation” selling point of Zulip.

I think the best way to fix it would be — to mark messages automatically as read only when I am inside an individual topic (or PM conversation), when I have the whole context of discussion. When I am in an “all messages” view, or when I am in a “stream” view, or in “search” view, no messages should be marked as read.

What if I read a non-active stream as a whole, should I enter each topic to mark messages as read? No, below all messages there should be a button “mark all topics as read” — to confirm that I indeed read all of the topics above.

I think this behavior would be very consistent, and would reinforce Zulip’s strengths in supporting long asynchronous conversations.

@timabbott
Copy link
Sponsor Member

I think this is certainly viable as an option. I'd to some extent to prefer to focus on the solution of taking you to the last read message rather than the first unread, which I think @ryanreh99 was doing some work on, but it could be sensible to do both.

@amartin3225
Copy link

I've noticed this problem recently where I'll be viewing a different message (e.g. typing a private message to User A) and a private message from User B will come in and I'll see it show up grayed out at the bottom of the window. I do not want to read it now as I need to finish what I was typing to User A, so I finish doing that and send the message. Later, I notice that the message from User B has already been marked as read and I've forgotten about it since it did not stay as unread (I would normally click Private messages and then select User B to read the message when I am ready).

ryanreh99 added a commit to ryanreh99/zulip that referenced this issue Sep 7, 2020
For narrows where we select the first unread message
on activation, we also `force_rerender` the message
list which causes the message to get reselected.

Thus when the `MessageList.select_id` is called for
the first time, `previously_selected` is -1. However,
due to this rerender on selecting the message again
the previously selected message and our to be selected
message is the same.

On passing this information to the `message_selected.zulip`
event, the event handler in `message_scroll.js` tries to
mark the message as read. The message is marked on the
second event instead of the first as the previously
selected message is -1.

Fixes zulip#10886.
ryanreh99 added a commit to ryanreh99/zulip that referenced this issue Sep 13, 2020
For narrows where we select the first unread message,
on activation we have to select it. And on our initial
selection was also `force_rerender` the message list
which causes the message to get reselected.

When `MessageList.select_id` is called for the first time,
`previously_selected_id` is -1. However, because the rerender
function call is before the event trigger, `select_id` is
called again this time with `previously_selected_id` have the
same id as the to be selected message and this selection event
gets triggered before our first time's selection.

This above case only occurs only for narrow activation or
when a message is selected again by clicking on it (message
is already read for this case).

For the All Messages view we have similar logic where, since
opts does not contain `force_rerender` we pass `mark_read`
as false (which was previously unused) which skips the
"message_selected.zulip" event in `message_scroll.js`.

Fixes zulip#10886.
ryanreh99 added a commit to ryanreh99/zulip that referenced this issue Sep 13, 2020
For narrows where we select the first unread message,
on activation we have to select it. And on our initial
selection was also `force_rerender` the message list
which causes the message to get reselected.

When `MessageList.select_id` is called for the first time,
`previously_selected_id` is -1. However, because the rerender
function call is before the event trigger, `select_id` is
called again this time with `previously_selected_id` have the
same id as the to be selected message and this selection event
gets triggered before our first time's selection.

This above case only occurs only for narrow activation or
when a message is selected again by clicking on it (message
is already read for this case).

For the All Messages view we have similar logic where, since
opts does not contain `force_rerender` we pass `mark_read`
as false (which was previously unused) which skips the
"message_selected.zulip" event in `message_scroll.js`.

Fixes zulip#10886.
@tomgw
Copy link

tomgw commented Oct 19, 2020

A bit late in the discussion but it seems relevant here: I addressed the same problem in my question in the Zulip community when it was answered by @showell with a rewrite of calc_can_mark_messages_read() in static/js/filter.js.
In short: with one boolean you can avoid messages being marked as read in interleaved view (i.e. when selecting a Stream, All messages, or Private messages).
There is however no UI interface for toggling this boolean for an organization or a user.
Nevertheless, it works perfectly for me to only mark messages as read when I am in a topic or in a specific PM list for one person/group.

@timabbott timabbott added the post release Issues to focus attention on after the current major release label Apr 9, 2021
ryanreh99 added a commit to ryanreh99/zulip that referenced this issue May 20, 2021
On activating a narrow we always mark the first message it selects
as read, which is usually the first unread message. This behaviour
is unwanted.

The flow is as follows:
* On activating the narrow we call the `MessageList.select_id`
  method along with a `force_rerender` param.
  Here event = {
                 id: X,
                 previously_selected_id: -1,
		 ...
	       }
  where X = the first unread message id to be selected.

* Due to this `force_rerender` field, we first call the
  `rerender` method and then trigger our custom event handler
  (`message_selected.zulip`) which is responsible for marking
  message as read.

* However, due to this call path: `this.select_id` >
  `this.rerender` > `this.rerender_view` > `this.redo_selection`
  > `this.select_id`, the `message_selected.zulip` event gets
  triggered with event as = {
	                      id: X,
                              previously_selected_id: X,
		              ...
	                    }

* Thus the second selection event gets triggered before the
  first one having the current and previous id equal to "X".

This above `id = previously_selected_id` consition only occurs
for narrow activation (due to the `force_rerender` flag) or
when a message is selected again by clicking on it (message
is already read in this case).

For the All Messages view we have similar logic where, we pass
`mark_read` as false (which was previously unused) which skips
the "message_selected.zulip" event in `message_scroll.js`.

Work towards zulip#10886.
@RalfJung
Copy link

Clicking on a stream on the left hand navbar results in a message from that stream getting marked as read. AFAICT, it's the oldest message, which makes this worse - I often have things that I want to respond to, but need to spend a fair amount of time on, so I keep them unread. Once that becomes the oldest thing in a stream, I can no longer click on the stream in the left hand nav, because doing so will result in the topic or message that I want to reply to being marked as read.

This is a problem I ran into quite often the last weeks. :) So indeed it'd be great to find some solution here. Only marking messages as read in the per-topic view sounds good to me, but will probably be surprising to some people.

@vincentbernat
Copy link

I often miss messages because I have a tab left open in zulip on private messages but I am away. When the tab is not a foreground, but I have selected the private conversation with someone, the messages received on this conversation are automatically marked as read. Looking at the source code, I see no mention of visibilityState or visibilityChange. Maybe messages shouldn't marked as read when there is no interaction at all (scrolling even when at bottom, typing, but not moving away to another user).

I don't get this kind of issues in Slack, but I don't know what they do differently.

@gnprice
Copy link
Member

gnprice commented Jul 12, 2023

The three items in the original issue description have all been fixed:

  • The default view is the inbox-style "Recent conversations" view, not "All messages".
  • Going to a stream via the left sidebar no longer marks a message as read.
  • Clicking on "Direct messages" (the new "Private messages") in the left sidebar no longer changes the message-list pane at all — it just expands a list of DM conversations in the left sidebar. But even if you hit the "interleaved view" icon to the right of those words, to go to the interleaved view of direct messages, that doesn't mark a message as read either.

Thanks @WesleyAC for raising them!

It seems we lost track of this thread and didn't cross-reference it when we made those changes. I believe the latter two happened sometime in the last year or so, but I don't see them in the Zulip Server 7 or Zulip Server 6 release blog posts, so I'm not sure when they happened. Anyway, closing now.

I often miss messages because I have a tab left open in zulip on private messages but I am away. When the tab is not a foreground, but I have selected the private conversation with someone, the messages received on this conversation are automatically marked as read.

Yeah. @vincentbernat this would be good to file as its own fresh issue.

@gnprice gnprice closed this as completed Jul 12, 2023
@laurynmm
Copy link
Collaborator

Noting here that interleaved views will (should) mark the first message as unread unless the user has changed their display setting for automatically marking messages as read: https://zulip.com/help/marking-messages-as-read#configure-whether-messages-are-automatically-marked-as-read.

There is an issue where the mark as read automatically behavior is inconsistent: #26021.

@gnprice
Copy link
Member

gnprice commented Jul 12, 2023

Noting here that interleaved views will (should) mark the first message as unread unless the user has changed their display setting

Hmm, I see — thanks for catching that. I guess this should stay open, then. I've set that setting and therefore have not encountered this problem in some time 🙂

@vincentbernat the behavior you described would still be good to file as its own fresh issue.

@gnprice gnprice reopened this Jul 12, 2023
@RalfJung
Copy link

RalfJung commented Jul 13, 2023

Going to a stream via the left sidebar no longer marks a message as read.

Cannot confirm. When I click a stream, the "unread" counter decrements by one. When I then scroll around more messages are marked as read. So it is still hard to navigate streams while preserving "unread" state.

EDIT: Ah, I found "automatically mark as read - conversations". That seems to help. :)

@laurynmm
Copy link
Collaborator

Yes, to be clear, there is now (in Zulip 7.0 release) a per-user setting that allows users to set when messages are automatically marked as read.

The options are:

  • Never, and in this case the user has to always manually mark messages as read
  • Only in conversation views, and in this case messages are only marked as read in a particular stream/topic view or a particular direct message conversation. The views that contain multiple conversations (a stream view, all direct messages view, search views, all messages view) do not mark as read with this setting.
  • Always, and in this case messages are marked read in those interleaved views mentioned in the bullet point above.

Here's the documentation for marking messages as read in the help center: https://zulip.com/help/marking-messages-as-read. It's noted in the Zulip 7.0 blog post under the Release highlights / New and improved workflows section.

While existing Zulip users will have to go in and configure this setting, organization admins can set this as the default for new users joining the organization (if they want to); see configure default settings for new users documentation.


I agree that the pinned tab marking messages as read should be reported as a separate issue. I'll note that that issue might be fixed by the work I'm doing to fix #26021.

I don't know if this issue should remain open as the "per-user" setting does allow the control to not mark messages in interleaved views as read.

@gnprice
Copy link
Member

gnprice commented Jul 13, 2023

I think as long as the default settings are giving people this experience, the problem is still present and the issue should remain open.

Specifically, one of the three items in the original report still applies, namely "Streams with unread messages":

Clicking on a stream on the left hand navbar results in a message from that stream getting marked as read.

That is a pretty common thing to want to do, so I think this is still a significant issue for many users who haven't discovered the setting.

(On default settings, if you specifically go to the "All messages" view or the interleaved-DMs view, those will also start marking messages as read. But because "All messages" was replaced as the default view by "Recent conversations", and because clicking "Direct messages" in the left sidebar to try to navigate to the DM you just got now just opens a section in the left sidebar and doesn't navigate to an interleaved view, I think those two UX problems from the original report have been solved.)

@laurynmm laurynmm added area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) area: left sidebar (ui) Left sidebar buttons/interactions excluding popovers and removed area: message feed (uncategorized) labels Sep 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: left sidebar (ui) Left sidebar buttons/interactions excluding popovers area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) difficult Issues which we expect to be quite difficult post release Issues to focus attention on after the current major release priority: high UX UX improvements to an existing workflow.
Projects
None yet
Development

Successfully merging a pull request may close this issue.