436769 - Auto "mark as read" is over-eager

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Jay Levitt]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008053104 Minefield/3.0pre
Build Identifier: 3.0a2pre (2008060103)

If I have two messages unread in my inbox:

1. Buy cheap viagra!  Canoe J. Skyscraper
2. Just saying hi     Mom

With #1 selected, I press "J", and it marks it as junk, and moves it to my Junk folder.  #2 is now selected, which means that N seconds later, #2 gets marked as read.

Relevant settings:

Account -> Server Settings
  * Server type: IMAP server
  * When I delete a message: Remove it immediately
Account -> Junk Settings
  * Move new junk messages to "Junk" folder
Preferences -> Advanced -> General
  * Wait 2 seconds before marking a message as read


Reproducible: Always

Comment 1

[Biju]

WFM in WinXP version 3.0a2pre (2008060803)

Comment 2

[Kent James (:rkent)]

You don't really say what you expect to happen. The new message is selected, and as you requested marked as read after a few seconds. Do you really want it to NOT be marked as read in that case?

It seems to me this is working as designed. I can confirm that it behaves as described, but I do not think it is a problem.

Comment 3

[Jay Levitt]

Well, Windows behaves differently, as Biju reported, so Mac and Windows can't both be WAD.

I'd want it to behave like the Windows version, and NOT mark the message as read.  Performing an action on one message shouldn't have the effect of marking the next message read!  Yes, it's displaying it to me, but that's not what I asked it to do either.   

I've seen this in a few other cases on the Mac, though I can't seem to find the exact steps to duplicate; it probably involves using Quick Search, changing the view of the current folder, switching folders, etc.  In general, the Mac version seems to be more aggressive about selecting a message from the list, and thus marking it read; Windows, IIRC, left you with no selected message (maybe focused but not selected?).

Comment 4

[Kent James (:rkent)]

I'm also running windows, and it works the same way as reported for me.

I don't think there is a really good resolution for this. In my work style, I typically do a triage run through the INBOX, plus I use a tag for the "i'm done with this message" indication (while some people, probably those interested in this bug, use "read" for that purpose). So the requested behavior would be annoying for my style, as I want to quickly scan and read all of my messages.

Perhaps you could modify this to an enhancement, and request a preference to change the default behavior. There is some precedence for this - if you manually mark a message as read, it stays selected but does not get marked read after the delay time.

The direction that I would like to see happen is that all bug triage steps, including marking as junk, leave the current message in the view as long as the view is still open, but crossed off so that it is visually clear that it has been processed and will no longer appear. The main working view is a saved search that does not display messages that have been "processed", be it marked as junk, tagged "filed" or with some time-delay.

Comment 5

[Biju]

(In reply to comment #1)
> WFM in WinXP version 3.0a2pre (2008060803)
Sorry I am wrong, I assumed Bug 75866 regressed, WinXP behave the same way as described on comment 0. And it is not a bug, ie TB works as designed. 


But this looks like you are looking for an enhancement like following

======== mail mark read options ========

[X] Automatically mark message as read after [  ] seconds
    [ ] mark as read, only if user deliberately select a mail

===============================

I dont know how quick mozilla will fix this in TB, 
so you can ask somebody to make an extension for it.

here is the sample code which will stop marking a message read.
see bug 75866 comment 52

WARNING!!! dont install the extension there, it for old TB
So it may corrupt the new TB profile. 
And you may LOOSE all your MAILS !!!

Comment 6

[Jay Levitt]

I disagree strongly with that change: This is not an enhancement request, and it is not a good candidate for an extension or a preference (at least not phrased that way).  If MailCo thinks Thunderbird should behave this way, then let them say so; if not, it is a bug.  It's a central UI issue: Do you want Thunderbird to give you as much momentum as possible when zipping through your inbox, or do you want Thunderbird to preserve mail as unread when it's not sure you've read it?

I found the other fail case I was looking for:

Failcase #2

- Set your two-second "mark read" timer
- Switch View to "unread"
- Read an unread message
- After two seconds, mark it as unread again
- Switch View to "All"
- That message will be selected and, thus, marked as read again

I don't know if it's the same underlying bug/misfeature, but it's the same poor experience: I have to watch Thunderbird like a, er, hawk, or my e-mail will disappear into the great sea of already-read mail.

And Failcase #3:

- Settings: view=unread, 2-second "mark read" timer, junk=move to junk folder
- Read the second-to-last message
- Decide to mark it as unread
- Read the last message
- Decide it's junk
- When that gets moved to the Junk folder, the selection switches to the PREVIOUS message
- Which then gets marked read two seconds later.

So in these two cases, Thunderbird is explicitly overriding something you just told it to do, because it forgot.  That's about as intuitive as clicking "unsubscribe" on a mailing list, then discovering that they automatically opt in everyone who visits their web site... including people who visit their web site by clicking the unsubscribe button.  

Kent, it sounds like you use a proactive tag to say that you're "done" with an e-mail, right?  So if the behavior changed, and marking a message as "Junk" didn't mark the following message read, how would that change your workflow?  It seems to me that you'd still mark it as "done", so you'd still be happy, right?

Or are you saying you go once through the unread items, tag them or don't tag them, and then they don't "disappear" until you've tagged them, so you no longer care about their read status?

It's a tough problem, true.  The problem is that "displaying the message" has two sets of semantics:

1. If I read the previous message, and selected "next", clearly I want to see the next message, and have the normal semantics

2. If I read the previous message and marked it "junk", I was making a decision about THAT message.  I may be working through my inbox, and thus wanting to see the next message; or, I may have been looking only at the previous message, and not wanting any interaction with the message before it.

I certainly can't think of cases where I'd want Failcases #2 or #3 to happen; Kent, is that true even with your workflow?

Comment 7

[Kent James (:rkent)]

> 
> So in these two cases, Thunderbird is explicitly overriding something you just
> told it to do

Yes, because you initiated a new action, so it reverted to its default behavior, which is to mark a message read after 2 seconds.

Jay, why don't you just increase you timeout if this bothers you?

> Kent, it sounds like you use a proactive tag to say that you're "done" with an
> e-mail, right?  So if the behavior changed, and marking a message as "Junk"
> didn't mark the following message read, how would that change your workflow?

If I want to mark the message next read, which I typically do, then your proposed change would prevent that, and force me to take some other action to mark it as read. In the best case, if there was a keyboard shortcut, then you've just added an extra keystroke to me experience. I'm not aware of a shortcut to mark as read (though there may be one). This is not a change I would support for my usage.

> It seems to me that you'd still mark it as "done", so you'd still be happy,
> right?

No, because I often leave it in the inbox, read but unfiled, which means I need to do further review of the message before it is done.

> Or are you saying you go once through the unread items, tag them or don't tag
> them, and then they don't "disappear" until you've tagged them, so you no
> longer care about their read status?
> 

They disappear from my main view (which is a virtual search folder on the Inbox with "Tag DoesntContain filed" as the filter) when I tag them as "filed". Currently this only happens when you leave the view. I am proposing in bug 430847 that the messages remain in the view as long as it is open, but be marked as no longer matching.

> 
> I certainly can't think of cases where I'd want Failcases #2 or #3 to happen;
> Kent, is that true even with your workflow?
>

I very rarely mark messages as unread, which is an essential feature of the two cases you gave.

Jay, I'm not sure what you want. What you seem to want is for the default behavior to change to match your work style - and you specifically exclude the possibility of allowing the existing style as an option. If that is your request, then I recommend WONTFIX as the resolution. But I've probably misunderstood you.

Comment 8

[Jay Levitt]

> Jay, why don't you just increase you timeout if this bothers you?

That'd actually make it worse.  The problem is that, with my workflow, I sometimes mark messages as junk, and don't *care* about the next message.  I don't want to do anything with it.  But TB is going to do something regardless of what I want; if the timeout were 10 seconds, I'd have to wait around for 11 seconds so I could say "No!  Don't mark it read!"

> I'm not aware of a
> shortcut to mark as read (though there may be one).

Just so you know, it's "M"; but you're right, we shouldn't turn your one keystroke into two.

>> I certainly can't think of cases where I'd want Failcases #2 or #3 to happen;
>> Kent, is that true even with your workflow?

>I very rarely mark messages as unread, which is an essential feature of the two
>cases you gave.

True enough.  So, at least, it sounds that fixing those two cases wouldn't affect you.  True?

> and you specifically exclude the
> possibility of allowing the existing style as an option

I don't want to preclude your work style at all; I'd just rather find a design that gives the right semantics in all cases (or at least most of them).  I'd hate to see TB go down the Path of a Million Checkboxes; it'd go from an e-mail app to an E-Mail Application Development Framework.  (See, e.g., MyLifeOrganized, or worse, Eclipse.)  I tend to think "make it a preference" should be a last resort.

Maybe there is no such design, and this has to be either a preference request or a WONTFIX, but I think it's too early to give up that way.  I mean, we've had some great fixes on 7-year-old bugs lately... maybe we should let this steep for a few years... :)

Meanwhile, I'd like to know if anyone thinks that my failcase #2 and #3 are desireable behavior in ANY circumstance.  If they're not, then I'll put them in a separate bug, and we can turn failcase #1 back into an enhancement debate, since it's clearly a contentious and non-trivial UI issue.

Comment 9

[Wayne Mery (:wsmwk)]

For starters let's level set that this is not as a confirmed bug or ENH. Jay correctly (correctly I would suggest) filed this bug as UNCOnfirmed given the current behavior is working as designed. And we typically don't confirm ENH requests, especially ones without a defined scope and solution.  In that context I suggest that Biju probably should not have confirmed the bug.

To be productive we know that marking junk must advance to the next message. So should we special case only "mark as junk?"  Is a bigger perspective helpful?  IOW for functions that advance to the next message, under what conditions should the now selected message not be marked as read as per the preference interval - delete, mark junk, ...?  Never? Do we define such events that will trigger auto read as only keyboard navigation or clicks?  

Is there a solution that covers all use cases, is reasonable workflow for everyone, and follows what everyone believes is an easily understood standard?

Comment 10

[Jay Levitt]

Well, can it be WAD if it behaves differently on Mac vs. Windows?  Maybe it can; the "standard" UI metaphors differ between platforms.  That said...

Warning: meandering musing ahead.

I think the basic problem is that "mark read after N seconds" is really an imprecise proxy for "yes, I saw, and I'm done with that".  In the non-software world, if someone's reading you a list of things, you occasionally nod, or grunt, or make eye contact, and that means "yep, got that, next".  I've always thought that gaze-tracking would be a neat addition to Growl, but other than that, we don't have this option.

Google Reader has an interesting solution: If you scroll past something, you've read it (unless you go back and mark it unread).  That doesn't work for Thunderbird's three-pane interface, but I think this supports my tacit-acknowledgement metaphor.

Back to Thunderbird, "time passes" can mean two very different things:

1. Thunderbird has shown me an e-mail, I have read it, and I don't intend to take any explicit action on it; I'm done with it.

2. Thunderbird has shown me an e-mail, and I'm not looking.

It's really, really hard to distinguish those two cases.  We had a related problem when AOL went to a multi-window interface, back when users paid by the minute. We used to pay content providers per-minute royalties, which was easy, when only one window was open.  But with multiple windows, which one were you really looking at, if any?  Were you idle?  Did you have one window on top, but it was a small one, so it didn't obscure the one you were actually reading, which was lower in the Z-order?  etc.  I don't remember any good solutions.

I suspect that Thunderbird could make some distinctions between #1 and #2 by heuristics: Is there a scroll bar in the message, and if so, have you used it?  How did you arrive at the current message?  What's your current "pace" of reading?  What window is on top?  What did you do last time?

But those are imperfect heuristics, and would probably be a nightmare of non-deterministic user confusion.

A different approach would be making the state change of the current message more visibly explicit, especially while it's pending.  This approach says that the problem isn't whether or not Thunderbird marks a message read; it's whether it surprises you by doing so.  We don't mind hitting keys to make the computer do things, as long as we're expecting it.  (Otherwise, we'd all love autoscroll, right?)  Google Reader gets that for free due to the single-window scrolling metaphor, but I imagine there are things that Thunderbird could do.  

Right now, the only visible indication of a message's state is in the list pane; if it's bold, it's unread.  On the Mac, "selection" is indicated by a dark grey bar in a zebra-striped grey-and-white list, so it doesn't jump out at you.  (IIRC, on Windows, it's blue, right?)  And the text is black. On my calibrated 21" LCD monitor, I have a hard time telling if a message is bold or not; sometimes, I mark a message read and unread just to see which state it's in.

And that's just the list pane.  If you're actually paying attention to the message pane, you'll get no visual clues at all.

I'm not a UI designer, so I don't know what would help.  Web 2.0 apps often do a yellow-highlight-then-fade action to show you "this just changed, but you don't have to acknowledge that".  That'd be way too busy, but make it gives someone an idea?  

Likewise, the common metaphor for "something is about to happen" is a throbber/spinner.  Again, too busy.  But the idea is there.

I think, if TB goes this route, that:

* Visual cues should show up in the message pane, as well as the list pane, and the two cues should be consistent, though not necessarily identical.

* They should show up *before* the message gets marked as read; some visual equivalent to a "countdown", telling you "if you do nothing, this message gets marked as read".  

At the moment, my workaround is this: every time I mark a message as junk, or switch folders, quick-searches or views, I instinctively mark a message read and unread.  That way, I know that Thunderbird is "relaxed", and so am I.  I think that's telling.

You want to be able to safely look away from Thunderbird, and know that you're not losing information by doing so.  Currently, in GTD terms, it's not a "trusted system", and it should be.

Thoughts, anyone?

Comment 11

[Wayne Mery (:wsmwk)]

I fail to see the conclusion that Mac and windows are different. It might help others if you restated *your* problem in standard format like the following  
  STR  
  expected results
  actual results
because your initial comment didn't state the problem, only the conditions, and the summary has changed twice since then - and I don't think the summary matches what you are seeking. At the very least it is vague.

As for your issue, do you have a preferred solution or workflow?

note: the hard time distinguishing bold and unbold messages is  Bug 352833

Comment 12

[Magnus Melin [:mkmelin]]

I think we should close this bug.
The logic has changed a lot since it was opened. I don't know if any issue remains, but if it does, please open a new bug for that with steps to reproduce using http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/