286194 - feature: mail delete behavior with thread view enabled

Status: RESOLVED DUPLICATE of bug 65111

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Axel Bock]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 (MOOX M2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 (MOOX M2)

I just sorted through my mailing lists, which are displayed with thread view
enabled. I intended to delete uninteresting threads completely, so I marked them
via shift-cursor-down and pressed DEL. 

Expected result: The marked threads are completely (!) deleted.
Real result: Only the "first" message of the threads was deleted.
Proposition: If a folded thread is "deleted", the whole thread should go away.

Reproducible: Always

Steps to Reproduce:
1. enable thread view
2. fold all threads
3. mark some threads, easiest with shift+cursor key
4. press DEL

Actual Results:  
Only the "first" thread message was deleted from all marked threads. the rest
stayed.

Expected Results:  
The marked threads should be gone completely.

Comment 1

[Don Russell]

I don't like this suggestion... :-) (no offense, SOMETHING's needed)

I use threaded-view and often have a thread "folded" or collapsed so only the
oldest message in the thread is viewable....  in the bottom pane, the message is
displayed and I press "delete" if it's not of interest. I wouldn't want (nor
expect) that the entire thread be deleted.

However, the reason I'm *here* is because some for of "delete thread" is needed.

If I select an individual message, and right click, the context menu has an
option for "delete message". If more than one message is selected, the option
says "delete selected messages".

In thread view, it'd be nice to also have a "delete thread" option.

Or perhaps a odifier for the delete key...

DEL - delete selected messages (may be 1 or more)
ALT-DEL - delete thread

Or something similar.

And that option doesn't need to be restricted to only be available in thtread
view, thuogh that will be the most intuiitive.... but it could be available in
any view.

Thanks,
Don

Comment 2

[Don Russell]

I'm withdrawing my comments. I've now learned how to select an entire thread and
delete it....

I like the way it works, I think it's great.

No changes are needed on my behalf. :-)

Cheers,
Don Russell

Comment 3

[Jan Van Bruaene]

While I'll try using 'Select all in Thread (CRTL-SHFT-A)' + DEL,
I've found Apple's Mail.App a nice way to deal with threads:
You automatically select the entire thread first (and get an overview
of who is participating in the thread); only when you arrow-down 
do you enter the thread. 
Deleting the thread can happen in one click. I can provide screenshots
if needed. 
 

Comment 4

[Jan Van Bruaene]

Update [Fedora 3 / Thunderbird - version 1.0.2-1.3.2 (20050324)]
1. Menu driven (Edit -> Select -> Thread) works.
2. The short cut (CTRL+SHIFT+A) doesn't work.

Comment 5

[Conrad Schilbe]

You can select the thread "Bubble" to the left of the thread entry. This selects
all messages in the thread. Then pressing Del will remove all messages in that
thread.

I still aggree with the original poster and think that selecting the folded
thread and pressing Del should remove all messages in the thread. It is the
assumed functionality.



(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0 (MOOX M2)
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0 (MOOX M2)
> 
> I just sorted through my mailing lists, which are displayed with thread view
> enabled. I intended to delete uninteresting threads completely, so I marked them
> via shift-cursor-down and pressed DEL. 
> 
> Expected result: The marked threads are completely (!) deleted.
> Real result: Only the "first" message of the threads was deleted.
> Proposition: If a folded thread is "deleted", the whole thread should go away.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. enable thread view
> 2. fold all threads
> 3. mark some threads, easiest with shift+cursor key
> 4. press DEL
> 
> Actual Results:  
> Only the "first" thread message was deleted from all marked threads. the rest
> stayed.
> 
> Expected Results:  
> The marked threads should be gone completely.

Comment 6

[Bart Samwel]

When I read the Linux Kernel mailing list, I read what interests me for about 100 threads, then press Shift+Home to select everything from my current position to the start, and then press Delete. To my surprise, this doesn't delete the collapsed thread messages, and to add insult to injury I lose my current position so that I have to scan all the way down again to see where I was. The way I expectat it to work is that when I select everything between my cursor and the top of the list, it selects the collapsed messages as well -- it's a range select, and even collapsed items are within the range, in my opinion. Making it behave like that would definitely make my life a lot easier.

Comment 7

[Mike Cowperthwaite]

Seamonkey bug 65111.

As noted there, you can select an entire thread by clicking on the Thread icon, altho this will expand the thread.  You can select multiple threads by Ctrl-clicking on multiple thread icons.

Comment 8

[Mike Cowperthwaite]

*** Bug 362829 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

*** Bug 323302 has been marked as a duplicate of this bug. ***

Comment 10

[David Feldman]

I also agree with the original poster (and the suggestion to mimic Mail.app). 

Here's another rationale for having Delete delete the whole thread: with a thread collapsed, its item in the message list represents the thread itself rather than the first or last message. One expects Delete to delete the selected object - which in this case is the whole thread.

I also do like Mail.app's behavior of listing all the messages in a thread when its collapsed item is selected. It's useful and underscores the whole thread-is-selected thing.

Comment 11

[David Feldman]

Couple other thoughts:

I wonder if this is properly classified as a selection issue rather than a deletion one. For example, selecting a thread and then filing via Nostagly or dragging to a folder only affects the most recent message, and to my mind it's the same issue, i.e. the thread itself being selected.

Also, one other advantage to showing the thread's constituent messages when the thread is selected is that you see how long the thread is. I don't currently see any other way of determining that for a collapsed thread (short of expanding it).

Comment 12

[Don Russell]

(In reply to comment #10)
> with a
> thread collapsed, its item in the message list represents the thread itself
> rather than the first or last message. One expects Delete to delete the
> selected object - which in this case is the whole thread.

I disagree with this thinking... The problem is: The item in such a list actually represents one thing: The individual message. You WANT it to represent the entire thread and NOT the individual message. So, depending on view, you want that message to represent different things: 1 - the message, or 2 - the thread. 

A folder, or the whole collection of folders is nothing more than a collection of individual messages. The collection of messages may be viewed in different ways, simple chronological order, grouped by date, grouped by message-id/thread, etc.

Taking your view above, if you group mail by date so you have "today", "yesterday", "last week" etc groupings, do you expect that if you delete the first message from "last week" to delete all messages from "last week"?

The "selection" of data has to be consistent regardless of the "view" in order to be intuitive or predictable. You're saying that the first message in a thread represents all messages in that thread and so, if deleted, should cause the entire thread to be deleted. But that relationship ceases when I'm not in "thread view"? Why? The messages are still related. Only their view of them has changed. If I select a message halfway through a thread, should it also represent the remainder of the thread? No... I think this leads to a very confusing interface and one that will lead to messages being deleted accidentally.

I think it works fine as it is... (See comment #2) but, I would support some changes in the way things can be *selected*.... 

The context menu of a message item already has "Delete Message"... I'd like to see "Delete Thread" as well, regardless of the view. Why do I have to be in "thread view" to delete a thread?

Changing the view must not change selection behavior. (Except with how shift+right-click works... that's different, based on physical presentation)

I often read collapsed threads... read a message and delete it, the next one is visible.... I'd be annoyed (polite) if the whole thread were deleted... 

OK... in the time it took me to write this I have the following selection suggestion regarding Delete...

Del key - (simple delete) delete explicitly selected messages, (a single message, or additional ones as selected by shift-right-click, or ctl-right-click)

Alt+Del - (Alternate delete) Delete all messages of the current group. i.e. You're in thread view:  delete the entire thread of the message selected, regardless of it's position in the thread: first, last, other. In "sort by sender" view, Alt-Del deletes all messages from that sender, etc

Ctl+Del - (Controlled delete) A popup to allow the user to effectively select the grouping then delete as if Alt+Del we done, based on the selected grouping. i.e. I may not be in thread view, but want to delete all messages of "this" thread... CTL+Del, I select "by thread..." and all items of that thread are deleted. 

My 2 cents. :-)

Comment 13

[Luke Morey]

I can't think of another mail application that doesn't delete a collapsed thread when you press delete.  Any suggestions?  Here's my comment from the equivalent seamonkey bug 65111 comment 46 (from way back when there was no Thunderbird):

This is how it feels in a folder with a lot of threads.

  + thread one
    thread two
  + thread three
  + thread four

Highlight all 4 threads, press delete.  Now you see

  + thread one
    thread three
  + thread four

Highlight all 3 threads, press delete.  Now you see

  + thread one
    thread four

Highlight 2 remaining threads, press delete.  Now you see

  + thread one

Still not all gone.  Now multiply that process 50 times for a large folder with
a lot of threads.  It just ain't right.

"Dataloss keybinding"?  Well, we're talking about the delete key, which is
intended to lose data, however you cut it.  At the moment it just deletes a
weird-ass subset of what you were actually trying to delete.

Are there any other mail clients that don't treat a selected, collapsed thread
as a whole?

Comment 14

[David Feldman]

(In reply to comment #12)
> I disagree with this thinking... The problem is: The item in such a list
> actually represents one thing: The individual message. You WANT it to represent
> the entire thread and NOT the individual message. So, depending on view, you
> want that message to represent different things: 1 - the message, or 2 - the
> thread. 

I think I understand what you're saying, but disagree. To begin with, I think you're equating "items in the list" with "messages," something I'm not taking as a given. So where you say "you want that message to represent different things," I would say, "you want items in the list to represent different things." It may sound like I'm splitting hairs but I think it's an important distinction. To elaborate:

Ideally, in any list or tree each item should represent some type of coherent object. In this case, that object could be a message or a group of messages (i.e. a container). In a tree, it's expected that deleting a container node deletes the container and its contents. In most cases, no one would dispute this behavior - because the container node represents nothing but the container.  Thunderbird breaks this notion, and that's the source of our problem: when you organize by thread, the "thread" item represents *two* very different objects: the first message in the thread, and the thread itself (the container). I think it is this problem of dual representation that we need to address.

Mail.app solves this by making the thread container represent only a container: if you click on it, you see a list of the thread's messages instead of any individual message. I can't think of a solution that represents the individual message instead, because to have the hierarchy you have to have the container.

> Taking your view above, if you group mail by date so you have "today",
> "yesterday", "last week" etc groupings, do you expect that if you delete the
> first message from "last week" to delete all messages from "last week"?

Yes and no. Once again, if the "last week" container and the first message from last week are the same list item, you have a problem of representation. Instead, the first message should be the first sub-item of the "last week" container. So deleting it only deletes that message, with no confusion. The "last week" container is only a container, so deleting it deletes everything from last week, again with no confusion. (One could argue that allowing the user to delete everything from last week that easily is a problem, and it might be. I believe Outlook solves this by making the groups a visually distinct kind of list item that can't be deleted.)

> The "selection" of data has to be consistent regardless of the "view" in order
> to be intuitive or predictable. You're saying that the first message in a
> thread represents all messages in that thread and so, if deleted, should cause
> the entire thread to be deleted. 

Again, I'm saying the first message in a thread and the thread itself should be separate list items.

Comment 15

[David Feldman]

Now that I'm using Thunderbird 2b as my main email client, I'm finding the current behavior more and more irritating and unexpected. Here are a few other examples of why it's inconsistent with expectations of list behavior.

* Select multiple items in the message list and hit Delete. They all get deleted...unless on or more is a thread, in which case you end up deleting all the single messages and one message from each thread.

* Select an item in the message list and drag to a folder. It gets moved there...unless it's a thread, in which case you're left with the rest of the thread. With multiple messages you have the same issue as above.

Comment 16

[Don Russell]

I just do not see a problem... to delete a thread, I click the "balloon" to select the whole thread, and click delete. I moved the "balloon" column heading over to the left where it is more convenient for me.

Admittedly, that is two clicks instead of one which your proposed behavior would have. To me that is simply not inconvenient enough to warrant a behavior change. In fact, I might even consider it a bona fide feature... a way of confirming the intention.

The argument that you do not know of another e-mail client that behaves this way is not very compelling... are there standards that T-Bird is not adhering to? I am all for diversity. That is why there are different e-mail clients... they behave differently. Some people like this, some people like that. Vive la difference! :-) 

As I mentioned in Comment #12 I am in favor of a selection method that works consistently in the different views... 

To me, "thread view" is nothing special and should not be deleted in a way that differs from any other grouping. 

Comment 17

[David Feldman]

> I just do not see a problem... to delete a thread, I click the "balloon" to
> select the whole thread, and click delete. I moved the "balloon" column heading
> over to the left where it is more convenient for me.

Having the balloon (and Cmd-Shift-A) helps, certainly, but doesn't
address the root usability problem. Each item in a list/tree should
represent exactly one object. Doing things that way drastically reduces
ambiguity and confusion because the user can predict what will happen
when she manipulates the list item, and because actions taken on the
item predictably affect one object every time.

The current Thunderbird approach has thread items representing two
objects - the thread, and a message in it. So sometimes actions affect
the thread, and sometimes the message. The problem is bad when dealing
with one item, but especially difficult when trying to work with
multiple items.

> Admittedly, that is two clicks instead of one which your proposed behavior
> would have. To me that is simply not inconvenient enough to warrant a behavior
> change. In fact, I might even consider it a bona fide feature... a way of
> confirming the intention.

Granted, part of my problem with the particular behavior is that I do
find the extra clicks/keystrokes inconvenient because when I'm dealing
with a collapsed thread I want to take action on the entire thread. But
I do see a real usability issue here too, as described above, and I do
continue to get bitten by unexpected behavior while working with threads.

> The argument that you do not know of another e-mail client that behaves this
> way is not very compelling... are there standards that T-Bird is not adhering
> to? 

I agree that such an argument isn't compelling; certainly we shouldn't
be doing things the way everyone else does if there's a better way. If
there are standard I'm working off of, they pertain to the list control
itself...but even there I'm talking more about predictability than
standards.

That said, most rules and practices of UI design have exceptions. The
"one object per item" rule I'm advocating almost certainly has
situations to which it doesn't apply - generally, those in which the
drop in predictability is offset by an even greater increase in
efficiency, or learnability, etc. I guess I don't see that being the
case here though. With the behavior I'm suggesting, it still only takes
a click/keystroke to switch from first message to thread or vice versa.

> As I mentioned in Comment #12 I am in favor of a selection method that works
> consistently in the different views... To me, "thread view" is nothing special and should not be deleted in a way that
> differs from any other grouping. 

Actually, at least in 2b2, the thread view *does* differ from the other groupings. There, each grouping is represented by a top-level tree item with a distinct appearance that cannot be deleted. In other words, it comes close to representing a single object (the group). I say "comes close" because sometimes it still seems to represent the first message in the group (for example, if you drag it to a folder).

What I'm advocating is something similar (and very close to what Apple Mail does): when the message list is organized by thread, each thread's item in the list represents the thread and only the thread. Dragging, deleting, or otherwise manipulating that item affects all messages in the thread (among other things, note that shift-selecting in the message list then works as expected). Right arrow (or a click in the disclosure triangle) expands the thread and selects the first item (message). Left arrow (or the disclosure triangle) collapses the thread and, if not already selected, selects the top-level thread item. Ideally, when that item is selected some sort of preview of the whole thread appears in the message pane.

Comment 18

[Don Russell]

I think this still comes down to an issue of how items (individual e-mail messages) are selected. Thread view is "just another view" of the same information.

In a plain chronological ordered list of items I selected two different e-mail messages. (Ctl-Click or Shift-Click etc)

Then I mouse-down on one of the highlighted messages and drag them to another folder.... lo and behold, guess what happened? The entire collection of selected items was NOT dragged... only the individual item I happened to choose from the group of two was moved.

This means there is a "selection issue" with T-Bird.... right now the behavior is consistent, even if undesirable. i.e. In the example above, why was one message left behind when it was clearly selected?

Doing "special processing" for thread view is just wrong philosophically from an object oriented point of view. Now, if we can agree that the selection process in general needs work, that is another issue altogether.

If I select multiple messages and drag them somewhere... ALL selected items should be dragged... that is expected, even implied, extremely intuitive.

So, an intuitive method for selecting an entire thread is needed... and that selection does not need to be restricted to being available only in thread view.

Once the selection issue is solved, so is your thread-delete issue... delete will deleted selected items, just as the drag/drop method above dragged/dropped the selected messages.

I am repeating myself... these are all things I said in comment #12 above. :-)

I think I have contributed all I can to this discussion. Not to be dismissive, but I have no control over the code.... I am not prepared to make any code changes in this case, so it is left up to the T-Bird people or others taking advantage of open source to make any changes. Hopefully they see this dialog and take the whole discussion into account.

PS.. regarding the multiple select/ drag-drop issue.. I work around it by selecting the messages and then using the context menu and select move... clumsy, but it works.