Open Bug 749036 Opened 8 years ago Updated 6 years ago

"T" keyboard shortcut menu at Go | Next | Unread Thread needs to indicate it marks the currently viewed thread as read

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: damokles4-bugs, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, ux-consistency, ux-control)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Jumped from first mail of a completely unread thread to the next unread thread using keystroke "t"


Actual results:

the unread thread was marked read


Expected results:

the unread thread should be kept unread (to read later) because there already is a function "mark thread unread" (keystroke "r").
(In reply to Friedrich Strohmaier from comment #0)
In Linux builds, keystroke "R" is for marking read, not for marking unread. See Message ➝ Mark.
(In reply to Hashem Masoud from comment #1)
> (In reply to Friedrich Strohmaier from comment #0)
> In Linux builds, keystroke "R" is for marking read, not for marking unread.
> See Message ➝ Mark.

Of course You're right. Was an errorous hour (i.e. too late). 
"Mark unread" doesn't make any sense here.
This is working as designed, since forever - its's just not completely documented as far as I know.  http://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts
Summary: thread marked read using "t" to jump to next unread thread → thread is marked read when using "t" to jump to next unread thread
Hmmm. I don't regularly use threads, but I tend to agree with reporter that forcing the whole thread read via just using a keyboard shortcut (T) that's simply labelled "Go to next unread thread" in the menu comes as a surprise, especially because there's a convenient single-letter keyboard shortcut (R) to "Mark Thread as Read".

Moreover, threads are internally force-sorted oldest msg first (which makes some sense), so using T to jump between unread threads will always show the oldest (original) msg first. I don't see how we could tell if a user wants the whole thread force-marked read after barely looking at the first msg for 1 second.

Finally, it's also surprisingly ux-inconsistent, if compared with similar functions, e.g.
N = go to next unread message
...which does just that, without forcing read (set mark-read-delay to 10 seconds to ensure you're not seeing artefacts from automatical marking read on display).
While you could argue that in this case it's much more likely that this single msg has actually been looked at!
In fact, *all* other shortcuts from "Go" menu do not force the message into "read" status if "Automatically mark messages as read" is deactivated or configured to delay.

So my questions are:
1) How would I jump from one unread thread to the next one *without* marking all of the first thread read? (no way)
2) Is 1 a plausible and legitimite usecase, and more ux-consistent with similar behaviour of N shortcut? (suppose yes)
3) Would it be all too hard for users of T shortcut to press R subsequently if they want the whole thread read before moving on? (dont know, maybe yes for those who got used to the current behaviour)
4) Given the impasse between 2 and 3 (ux-consistency and legitimate different usecase vs. traditional comfort of current ux-inconsistent behaviour for unknown number of users), shouldn't this undocumented feature (automatically mark thread read when going to next thread with T) at least have a hidden pref to turn it off, given the fine-grained prefs we provide for automatical marking read (the granularity of which has been increased after TB2!)?

The reason why this isn't documented in keyboard shortcuts is that there is no clue in the UI that this particular shortcut includes another function (mark thread read), and I would never have guessed that... But yes, documentation should reflect status quo.
Summary: thread is marked read when using "t" to jump to next unread thread → thread is marked read when using "t" keyboard shortcut to jump to next unread thread
Summary: thread is marked read when using "t" keyboard shortcut to jump to next unread thread → Entire thread is force-marked "read" when using "T" keyboard shortcut to "go to next unread thread" [jump]
(In reply to Wayne Mery (:wsmwk) from comment #3)
> This is working as designed, since forever - its's just not completely
> documented as far as I know. 
> http://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts

I've updated the keyboard shortcuts documentation to reflect the status quo.
Thanks for the ping.
At least,
Severity: normal → minor
OS: Linux → All
Hardware: x86 → All
Version: 11 → Trunk
(In reply to Thomas D. from comment #4)
> Hmmm. I don't regularly use threads, but I tend to agree with reporter that
> forcing the whole thread read via just using a keyboard shortcut (T) that's
> simply labelled "Go to next unread thread" in the menu comes as a surprise,
> especially because there's a convenient single-letter keyboard shortcut (R)
> to "Mark Thread as Read".
> 
> Moreover, threads are internally force-sorted oldest msg first (which makes
> some sense), so using T to jump between unread threads will always show the
> oldest (original) msg first. I don't see how we could tell if a user wants
> the whole thread force-marked read after barely looking at the first msg for
> 1 second.

makes total sense in news, where often looking at the first post reveals whether you care or don't care about a thread.
 
> Finally, it's also surprisingly ux-inconsistent, if compared with similar
> functions, e.g.
> N = go to next unread message
> ...which does just that, without forcing read (set mark-read-delay to 10
> seconds to ensure you're not seeing artefacts from automatical marking read
> on display).
> While you could argue that in this case it's much more likely that this
> single msg has actually been looked at!
> In fact, *all* other shortcuts from "Go" menu do not force the message into
> "read" status if "Automatically mark messages as read" is deactivated or
> configured to delay.

perhaps "T" evolved a long time ago from being just "go to to next thread" to "mark read and go ...", and never got moved out of the Go menu.

> So my questions are:
> 1) How would I jump from one unread thread to the next one *without* marking
> all of the first thread read? (no way)
>
> 2) Is 1 a plausible and legitimite usecase, and more ux-consistent with
> similar behaviour of N shortcut? (suppose yes)
perhaps the measure of whether users care might be, is there an existing bug report asking for it?


> 3) Would it be all too hard for users of T shortcut to press R subsequently
> if they want the whole thread read before moving on? (dont know, maybe yes
> for those who got used to the current behaviour)
I seem to recall having to do just that in a news reader from long ago.
(being non-committal) I'm not sure whether I'd like that.

> 4) Given the impasse between 2 and 3 (ux-consistency and legitimate
> different usecase vs. traditional comfort of current ux-inconsistent
> behaviour for unknown number of users), shouldn't this undocumented feature
> (automatically mark thread read when going to next thread with T) at least
> have a hidden pref to turn it off, given the fine-grained prefs we provide
> for automatical marking read (the granularity of which has been increased
> after TB2!)?
hidden pref is unlikely to fly. I'd sooner look for another key to do the "Go to next unread thread" 

> The reason why this isn't documented in keyboard shortcuts is that there is
> no clue in the UI that this particular shortcut includes another function
> (mark thread read), and I would never have guessed that
probably well known for people who use threaded view

>But yes, documentation should reflect status quo.
indeed. thanks for the update
(In reply to Thomas D. from comment #6)
> At least,
Scrap that. (I was thinking if at least we could have a tooltip on the menu item, like "Mark Thread as Read and Go To Next Thread", but then, there's no precedence for tooltips on menus, as they are usually self-explanatory).

(In reply to Wayne Mery (:wsmwk) from comment #7)
> makes total sense in news, where often looking at the first post reveals
> whether you care or don't care about a thread.

Sure. Somewhat neglected on my mental map as I rarely use it.

> perhaps the measure of whether users care might be, is there an existing bug
> report asking for it?

Well, there is one now :), but touché, apparently this has never caused any problems from time immemorial.

> I seem to recall having to do just that in a news reader from long ago.
> (being non-committal) I'm not sure whether I'd like that.

That's what prefs are for ;)
 
> hidden pref is unlikely to fly. I'd sooner look for another key to do the
> "Go to next unread thread" 

I don't see how that would solve this little problem?

> >But yes, documentation should reflect status quo.
> indeed. thanks for the update

Most welcome. If up-to-date and well-looked-after, a keyboard shortcut page might well serve as a compact mini-reference of the more frequent/important functions of a software (which will typically have shortcuts)... More so if we can link to how-to articles from there...
(In reply to Thomas D. from comment #8)
> (In reply to Wayne Mery (:wsmwk) from comment #7)
> > hidden pref is unlikely to fly. I'd sooner look for another key to do the
> > "Go to next unread thread" 
> 
> I don't see how that would solve this little problem?

well, there currently is no "go to next unread thread" without marking as read.  i.e. what you wrote earlier ... "1) How would I jump from one unread thread to the next one *without* marking all of the first thread read? (no way)". I found Bug 316736 covers this issue - shortcut needed for 'Go To Next Unread Thread' without marking the thread's messages as read.

This fits with bwinton who offered on IRC "I wouldn't want to change the behaviour of the existing key, but updating the menu item and finding a new key that did what the current menu item claims to do seems like a reasonable idea. Perhaps morph the bug title into that?" 

I am therefore morphing this bug 749036 to fixing the wording of T in the menu.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Component: General → Mail Window Front End
Ever confirmed: true
Summary: Entire thread is force-marked "read" when using "T" keyboard shortcut to "go to next unread thread" [jump] → "T" keyboard shortcut menu at Go | Next | Unread Thread needs to indicate it marks the thread as read
Whiteboard: [good first bug]
I'd suggest to change the behavior of T to not mark all of the current thread as unread. 

There's an easy workaround to press R (=Mark thread as Read) before, and outside news usage it hardly makes sense. I dunno about others but for heavy traffic newsgroups i just click around to see that i need an when i'm done i mark the whole *group* as read.

Blake, what do you think?
Flags: needinfo?(bwinton)
Summary: "T" keyboard shortcut menu at Go | Next | Unread Thread needs to indicate it marks the thread as read → "T" keyboard shortcut menu at Go | Next | Unread Thread needs to indicate it marks the currently viewed thread as read
Whiteboard: [good first bug]
Well, I'm not really fond of the workaround, since there's no reasonable way for people to discover it.

I thought for a second about using the "Mark as read when displayed" pref to toggle between behaviour, but I don't really think that's well correlated.

What about Shift-T to move without marking as read?  It appears to be unused, and it wouldn't break anyone's muscle memory…
Flags: needinfo?(bwinton)
"R" for mark thread as read is indicated in the menus, so it's not that undiscoverable considering you already discovered the go to next shortcut.

Shift-T to move without still leaves the dangerous hotkey, withouth any warning in the UI.
(In reply to Blake Winton (:bwinton) from comment #11)
> Well, I'm not really fond of the workaround, since there's no reasonable way
> for people to discover it.

I have mixed feelings at the moment. I wonder if this is only addressing a consistency issue, i.e. that we try to avoid one key shortcuts that change/delete data. And there is no documentation here that suggests many users accidentally hit t, and continue to do so after first bitten. I think many, many people use "t", so I wonder if we should be patient before acting. 

> What about Shift-T to move without marking as read?  It appears to be
> unused, and it wouldn't break anyone's muscle memory…

Might work. And we would "gain" a key "t" to jump to next thread. I would like that. But still stymied by my thinking noted above.
(In reply to Wayne Mery (:wsmwk) from comment #13)
> (In reply to Blake Winton (:bwinton) from comment #11)
>> Well, I'm not really fond of the workaround, since there's no reasonable way
>> for people to discover it.

> I have mixed feelings at the moment. I wonder if this is only addressing a
> consistency issue, i.e. that we try to avoid one key shortcuts that
> change/delete data. And there is no documentation here that suggests many
> users accidentally hit t, and continue to do so after first bitten. I think
> many, many people use "t", so I wonder if we should be patient before
> acting. 

From my point of view it's not too difficult to just win without loosing anything:
Leaving "t" alone as it is:
If Your assumption maches and really many people use "t" without complaints,
well, what about considering this as a vote by feet?
Otherwise if only few or even noone does use it - who cares, if it stays
untouched?

>> What about Shift-T to move without marking as read?  It appears to be
>> unused, and it wouldn't break anyone's muscle memory…

> Might work. And we would "gain" a key "t" to jump to next thread.

That's indeed my - the bug reporters - favorite..

> I would like that. But still stymied by my thinking noted above.

Apparently there are not many people beeing bitten, because of doing things
similar than I do. So having the opportunity at all, to do the jump without
changing the state by hitting "shift t" (or change that by own means) will
solve a general issue without hurting anyone's workflow.

btw. great to see this issue moving on :o))
See Also: → 316736
Keywords: dataloss
You need to log in before you can comment on or make changes to this bug.