749036 - Remove "T" keyboard shortcut from Go navigation and hamburger app menu (Next | Unread Thread unreversably marks the currently viewed thread as read)

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Friedrich Strohmaier]

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").

Comment 1

[Hashem Masoud]

(In reply to Friedrich Strohmaier from comment #0)
In Linux builds, keystroke "R" is for marking read, not for marking unread. See Message ➝ Mark.

Comment 2

[Friedrich Strohmaier]

(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.

Comment 3

[Wayne Mery (:wsmwk)]

This is working as designed, since forever - it's just not completely documented as far as I know.  http://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts

Comment 4

[Thomas D. (:thomas8)]

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.

Comment 5

[Thomas D. (:thomas8)]

(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.

Comment 6

[Thomas D. (:thomas8)]

At least,

Comment 7

[Wayne Mery (:wsmwk)]

(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

Comment 8

[Thomas D. (:thomas8)]

(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...

Comment 9

[Wayne Mery (:wsmwk)]

(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.

Comment 10

[Magnus Melin [:mkmelin]]

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?

Comment 11

[Blake Winton (:bwinton) (:☕️)]

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…

Comment 12

[Magnus Melin [:mkmelin]]

"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.

Comment 13

[Wayne Mery (:wsmwk)]

(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.

Comment 14

[Wayne Mery (:wsmwk)]

Rather hard to sift getsatisfaction for anecdotal information. 

https://www.google.com/search?num=20&safe=off&client=firefox-nightly&hs=SFE&rls=org.mozilla%3Aen-US%3Aunofficial&q=mark+read+thread+%22t%22+OR+key+OR+shortcut+-automatically+-junk+-font+site%3Agetsatisfaction.com%2Fmozilla_messaging&oq=mark+read+thread+%22t%22+OR+key+OR+shortcut+-automatically+-junk+-font+site%3Agetsatisfaction.com%2Fmozilla_messaging&gs_l=serp.3...14870.25828.0.30167.13.13.0.0.0.0.114.325.3j1.4.0....0...1c.1.19.serp.iTPieXRLacY
mark read thread "t" OR key OR shortcut -automatically -junk -font site:getsatisfaction.com/mozilla_messaging

Comment 15

[Friedrich Strohmaier]

(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))

Comment 16

[Wayne Mery (:wsmwk)]

Summary now really matches what is expressed in comment 9. "T" simply doesn't belong there since it's not a navigation-only key.

Comment 17

[Magnus Melin [:mkmelin]]

I still think T shouldn't do two things (mark read and move to next unread thread). Doesn't seem like a behaviour really needing to be optimized through one-key access. I also think the current behaviour is just a bug. Didn't really find where this is done though.

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #17)

I still think T shouldn't do two things (mark read and move to next unread thread).

Maybe. But that ship clearly sailed a long time ago and people obviously like it (including me) - we don't have lots of people (heck, not even a few) complaining about it.

So why break it? Make a new key and make everyone happy except the purists (which I sometimes am too) who don't like overloaded functions.

Comment 19

[Magnus Melin [:mkmelin]]

(In reply to Wayne Mery (:wsmwk) from comment #18)

So why break it? Make a new key and make everyone happy except the purists (which I sometimes am too) who don't like overloaded functions.

There are only so many single-key things we can do. To have something accessible it needs to be put in the UI and you can't really have an UI item "go to next and mark current thread as read"

Comment 20

[Friedrich Strohmaier]

(In reply to Magnus Melin [:mkmelin] from comment #19)

There are only so many single-key things we can do. To have something accessible it needs to be put in the UI and you can't really have an UI item "go to next and mark current thread as read"

What about the other way round:
put it in menu
Message -> Mark -> Thread read, jump next
sorry, don't have english GUI at hand..

Not perfect, but at least at the location of it's sisters.
P.S.: still alive ;-)

Comment 21

[Wayne Mery (:wsmwk)]

"Go" in hamburger does not exist in current beta. But it still does in menu bar.