Closed Bug 954815 Opened 10 years ago Closed 10 years ago

Unread ruler confusing when coming back to conversation with no new messages

Categories

(Instantbird Graveyard :: Conversation, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: benediktp, Assigned: aleth)

Details

Attachments

(1 file, 2 obsolete files)

*** Original post on bio 1380 at 2012-04-16 10:23:00 UTC ***

The unread ruler is only moved when there were new messages between now and previous focusing of the conversation.

If there were no new messages, I run into the following problem: coming back to the window and still finding it there makes me look at the messages below only to notice that I already know them.

I think we should remove it if the ruler and all 'new' messages were visible before already.
*** Original post on bio 1380 at 2012-04-17 09:07:11 UTC ***

It's probably not that easy to track whether the user has scrolled past the ruler.

Simpler alternatives up for discussion (apart from the current behaviour):

- remove the ruler whenever the window loses focus

- remove the ruler whenever the window loses focus and the ruler is visible on the screen
*** Original post on bio 1380 at 2012-04-17 09:39:19 UTC ***

(In reply to comment #1)
> It's probably not that easy to track whether the user has scrolled past the
> ruler.
> 
> Simpler alternatives up for discussion (apart from the current behaviour):
> 
> - remove the ruler whenever the window loses focus
> 
> - remove the ruler whenever the window loses focus and the ruler is visible on
> the screen


I should have written:

"I think we should remove it if the ruler and all 'new' messages were visible
_at once_ already."

i.e. your second case with the condition that the conversation wasn't scrolled up.
*** Original post on bio 1380 at 2012-04-17 10:16:09 UTC ***

Another alternative:
- remove the ruler when the window gains focus again but the "unread" messages have actually been read already. (This avoids the visual distraction of the content of a window loosing focus jumping around.)
*** Original post on bio 1380 at 2012-04-17 15:51:20 UTC ***

(In reply to comment #3)
> Another alternative:
> - remove the ruler when the window gains focus again but the "unread" messages
> have actually been read already. (This avoids the visual distraction of the
> content of a window loosing focus jumping around.)

I'm not sure this is a good idea because if the idea of this bug is to avoid a window that has lost focus having a visible unread ruler until there are actually new messages again, then this will not help (e.g. if a window is partially covered). And I suspect it would be less distracting to remove it when one is switching _away_ from the window as the user's attention is already elsewhere.
*** Original post on bio 1380 at 2012-04-17 15:59:44 UTC ***

(In reply to comment #4)

> the user's attention is already elsewhere.

The user's attention is elsewhere until something moves ;).

Note: I don't mind much either way, so don't take the above comment as a strong objection.
*** Original post on bio 1380 at 2012-04-17 16:03:00 UTC ***

(In reply to comment #5)
> (In reply to comment #4)
> 
> > the user's attention is already elsewhere.
> 
> The user's attention is elsewhere until something moves ;).
> 
> Note: I don't mind much either way, so don't take the above comment as a strong
> objection.

It's the sort of thing that needs experimentation ;) I wasn't sure about what to do when I put in the current behaviour. The argument for the current behaviour is that you wouldn't lose the ruler if you came back to your PC, IB had focus, but you switched away to check your email or something first before looking at new messages.
*** Original post on bio 1380 at 2012-04-17 16:35:04 UTC ***

(In reply to comment #1)
> It's probably not that easy to track whether the user has scrolled past the
> ruler.
> 
> Simpler alternatives up for discussion (apart from the current behaviour):
> 
> - remove the ruler whenever the window loses focus

Personally I'd like this, but I'd be OK with when the window gains focus again too.
Attached patch Patch (obsolete) — Splinter Review
*** Original post on bio 1380 as attmnt 1371 at 2012-04-18 23:47:00 UTC ***

This removes the ruler if it is visible when the window loses focus.

Removing the ruler when the window gains focus doesn't add movement when switching away from the window, but it doesn't actually fix the issue Mic originally complained about ("when I see an unread ruler I think there are new messages") and seemed odd in testing.

To avoid visible movement I suspect the current behaviour is best.

This patch seems an improvement, but I'm not 100% sure about the visibility-testing if clause (in a sense it would be more consistent to always remove the ruler, but when it's not on the screen it's more jarring to potentially see messages move).
Attachment #8353124 - Flags: review?(benediktp)
*** Original post on bio 1380 at 2012-04-19 00:09:04 UTC ***

(to clarify, by "current behaviour" I meant that from bug 954293 (bio 860), not this patch)
Attached patch Alternative patch (obsolete) — Splinter Review
*** Original post on bio 1380 as attmnt 1406 at 2012-04-26 12:43:00 UTC ***

Alternative patch that simply removes the ruler when the window loses focus. I think this is probably more consistent behaviour for the user.

Having used this for a while, I think either this patch or the other one is a definite improvement over the present behaviour.

Leaving the choice up to the reviewer :)
Attachment #8353159 - Flags: review?(benediktp)
Assignee: nobody → aleth
Status: NEW → ASSIGNED
*** Original post on bio 1380 as attmnt 1462 at 2012-05-11 09:42:00 UTC ***

I've used this patch for a while and it seemed to work as I expected. The code looks fine, too. I attached a new diff, with line numbers matching the file on HG now, so the patch should apply easily. If there's a way to make hg import an otherwise good patch that has just wrong line numbers, don't hesitate to let me know.

Thanks for fixing this!
Attachment #8353215 - Flags: review+
Comment on attachment 8353124 [details] [diff] [review]
Patch

*** Original change on bio 1380 attmnt 1371 at 2012-05-11 09:42:48 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353124 - Attachment is obsolete: true
Attachment #8353124 - Flags: review?(benediktp)
Comment on attachment 8353159 [details] [diff] [review]
Alternative patch

*** Original change on bio 1380 attmnt 1406 at 2012-05-11 09:42:48 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353159 - Attachment is obsolete: true
Attachment #8353159 - Flags: review?(benediktp)
Whiteboard: [checkin-needed]
*** Original post on bio 1380 at 2012-05-16 15:58:32 UTC ***

https://hg.instantbird.org/instantbird/rev/1167b92422a8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [checkin-needed]
Target Milestone: --- → 1.2
You need to log in before you can comment on or make changes to this bug.