107878 - Search UI: Hide Label column, shouldn't be available in search.

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[laurel]

Using oct 31 commercial trunk build

Label column should not be available in search messages UI results pane.

Comment 1

[laurel]

Using dec13 commercial trunk: label now doesn't show by default, but is
available in the search results pane column widget...I believe we agreed it
shouldn't be available at all.

Comment 2

[jglick]

I have it listed in the "Future" section of the Label spec. I suppose for 
reasons regarding allowing users to change the label in the search results list.

http://www.mozilla.org/mailnews/specs/labels/

Comment 3

[laurel]

Well, search results seems to sort okay on the Labels column when displayed. I
don't know what the current decision should be, if there's some other reason to
make sure it's hidden.

Comment 4

[Håkan Waara]

I have a one-liner to just hide the column, please review.

Comment 5

[Håkan Waara]

Attachment: Fix

Hide the label column.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 84930 [details] [diff] [review]
Fix

r=biesi

Comment 7

[David :Bienvenu]

I see no reason to do this - if the user wants to show the label column, I think
that's OK. I think it would be better to update the spec, unless there's some
reason the label column is undesirable/broken.

Comment 8

[jglick]

If you want to allow Label column in the Search window that is fine, but we need 
to make sure that if the user applies or changes a Label from the Search window, 
it is visible in the Main Mail window as well.

Comment 9

[David :Bienvenu]

we're just showing the label right now, not allowing you to change it. But I
think we should be going in the direction of allowing you to change it, and, as
you say, making sure the change is reflected in other views.

Comment 10

[Håkan Waara]

Please, the purpose of this little tree is to show the search results, not
organize your email. That's what the thread pane is for, and that's why we have
the "Open Message Folder" and "File" buttons in there -- to allow the user to go
further and display, organize and do whatever to the search results.

Let's not bloat this window with 'management' stuff, it should be easy to just
search for an email, find it, and go to that folder in the thread pane.

I can understand if you want the label column to show, but not if you want to
duplicate the thread pane in there. We need to make the distinction between
Search and Management of emails.

The reason I think Priority, Label et al should not be shown (at least not by
default) in this pane is because by default it should be very simple to find
emails and go to that folder. If you want additional rows, you can enable them,
but let's at least make it usable by default.  My 2c.

Comment 11

[David :Bienvenu]

Actually, we want you to be able to do as much as possible in the search results
window, and we've put a fair amount of effort into making that possible. If you
have lots of folders, and you want to operate on messages across folders, search
is the easiest way to do that. For a single folder, you can usually just use
quick search or sorting, but if you want to, say, delete all the messages from
sender XXX in all your folders, search is the easiest way to do that.

Comment 12

[Håkan Waara]

No, that's exactly why we need after-the-fact filtering.

Comment 13

[jglick]

I agree that Label doesn't need to be shown by default. I don't feel strongly 
either way if its available or not as an optional column (since you can't 
add/change a Label from here anyway).

As for not allowing users to add/change a Label from the Search window as a 
future feature, I disagree. Yes, we don't want Search to be a duplication of the 
full Mail window. But having a limited set of the most like actions a user might 
want to do with a search result is good. Generally, when someone does a search, 
they are looking for something (or things) in particular. When they get the 
search results, there's a high probability of them wanting to tag that message 
for future reference in some way. Labels are a good way to do that.

Comment 14

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 15

[Mike Cowperthwaite]

Bug 66970 comment 8 & 9 indicate that "Label" should be part of a context menu created for the search message window, if that's ever done.  Any reason this 
bug shouldn't be WontFix'd?

Comment 16

[Karsten Düsterloh]

David doesn't want this fix for TB and I don't want it for SM -> WONTFIX.