Returning to stream narrow after reply marks all stream messages read #2091

Open
kamalmarhubi opened this Issue Oct 20, 2016 · 6 comments

Projects

None yet

3 participants

@kamalmarhubi
kamalmarhubi commented Oct 20, 2016 edited

Rough steps:

  1. narrow to stream with s
  2. see interesting message, narrow to topic with s
  3. reply at end of topic (r, typey-type, <enter>)
  4. return to stream narrow with s

Expected outcome: to be returned to my position before the topic narrow (step 2).

Actual outcome: returned to bottom of stream, with all intervening messages marked read.

Background: I'm often catching up on several hundred messages. I skim through the a few stream views, and hit S to narrow to a topic if I want to reply. After replying, hitting s to go back to the stream narrow drops me to the bottom of the stream and marks all messages in between as read.

I would prefer to go back to where I was before the topic narrow, and find losing my unread state frustrating.

This is different from the home view, where hitting escape after replying brings you back to where you were.

(I may have some of the behaviors mixed up because the "state machine" isn't super simple or intuitive.)

@timabbott
Member

Hi @kamalmarhubi! Thanks for the detailedissue report; this aspect of the interaction experience is super important to us. I think it'd be helpful for you to read the discussion in this document: http://zulip.readthedocs.io/en/latest/pointer.html, which explains in detail the current Zulip behavior, and then try to reproduce the behavior you describe with that understanding. I think there are two possibilities for what is happening:

  • The app is behaving as expected currently, which means that if you read the last topic in a stream via a topic narrow and then return to the stream narrow, it will place your cursor at the bottom (because the messages in the stream had all been read), which is not the behavior you expect and something we can talk about how to improve (I do kinda feel like we should have a real way to "go back" there). I can imagine the behavior of returning to the narrow going to the end if there are no unread messages left being confusing and resulting in one feeling like one lost unread state when one didn't.
  • There is a bug where the app isn't following the behavior described in that document, that is causing us to incorrectly mark messages as read. I'd be somewhat surprised if that was the case, because I've never heard this reported before and we haven't made changes I can think of the relevant codepath, but regressions happen, especially with subtle logic like this, and I'd very much like to find a bug of this form if there is one.
@kamalmarhubi

one feeling like one lost unread state when one didn't.

Not sure if I'm getting you here, but I had ~180 messages unread in the stream before hitting s after replying. The message I replied to was indeed the last in the stream, but at no point did any of the intervening 180 messages show on my screen.

@timabbott timabbott added the bug label Oct 20, 2016
@timabbott timabbott added this to the Candidates for next roadmap milestone Oct 20, 2016
@timabbott
Member

Oh, I see, I'd misunderstood the flow you were describing. This issue is actually a design bug in the navigation model described in that doc. The s hotkey, by design, narrows to the stream, keeping whatever message you have selected focused. When you can see the bottom whitespace at the end of a particular view, we mark everything in that view as read. These two combine badly: if you were on the last message in the stream within a topic narrow, it places you at the bottom of the stream and marks things as unread improperly (because you've reached the bottom of the stream).

This is a really interesting issue! There's not an easy way to fix this without making the product's high-level navigation logic more complicated. The best idea I have for how to change the navigation logic is to have the s key borrow the escape key's logic for returning to the stream in the event that the stream has unread messages that are older than the current cursor, and basically take you back to the first unread message in the stream, which feels a bit hackish but would solve this problem in a way that I think doesn't introduce any new ones.

I don't think this would be a super hard code change to implement. @showell what do you think of that proposed solution?

Huge thanks @kamalmarhubi for reporting this!

@showell
Contributor
showell commented Oct 21, 2016

So my opinion on read/unread is that we should always err on the side of not marking messages as read. If you neglect to mark a message as read, you only inconvenience the user by forcing them to re-read some messages or scroll more. If you mistakenly mark a message as read, then the consequences can be more severe--they may miss out on something important, including something that they may need to follow up on.

My opinion on this specific issue is that we shouldn't change the navigation, but we should change the read/unread logic. But I'm not completely averse to the workaround that TIm suggests, because it's basically in line with my philosophy--maybe his proposed navigation would be sub-optimal for some users, but it's an acceptable tradeoff (to me) to prevent the issue that @kamalmarhubi raises.

@showell
Contributor
showell commented Oct 21, 2016

If we go with the approach of fixing the read/unread logic, then I think our rule should be to only mark messages that are actually visible on the page as read. I'm a bit surprised it doesn't work this way already. Is it possible that internally we are being correct about which messages we mark read/unread but we're advancing the pointer too aggressively (possibly due to a bug)?

@kamalmarhubi

Huge thanks @kamalmarhubi for reporting this!

I noticed reports here always get carefully read, so I decided to report anything I find. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment