163398 - Remove the column picker widget from the message columns

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[David Tenser [:djst]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020818
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020818

The column picker widget in mail/news should be removed. It is pretty useless
once bug 148545 is fixed.

This bug depends on bug 148545 (Right-clicking a column header should list
available columns instead of using context menu for an item).

Reproducible: Always

Steps to Reproduce:
1.
2.s
3.

Actual Results:  
sdas

Expected Results:  
sad

Comment 1

[David Tenser [:djst]]

OT: I don't like that I couldn't clean up the bug report before it was submitted
to the database. The "Steps to Reproduce" is completely useless for many bug
reports.

Comment 2

[Daniel Wang]

Reporter, I disagree with you on that the column picker is useless.
The column picker is more intuitive than right clicking (a usability
test should confirm this). Recommand wontfix.

Comment 3

[Kyle Yuan]

Reporter: you can use this url http://bugzilla.mozilla.org/enter_bug.cgi to 
report a bug. It has a more simple form.

Comment 4

[Alex Bishop]

I also disagree with this RFE. Some trees (intentionally) don't have column
pickers and if all the cloumn pickers were removed the user would have to
right-click on each set of column headers to find out if the columns could be,
er, picked.

I also agree with Daniel that a context menu is not as intuitive as the column
picker (there's evidence that people are having enough trouble finding the
column picker as it is - see bug 160905).

This doesn't mean that I disagree with bug 148145 (on the contrary, I agree with
it).

Comment 5

[Alex Bishop]

> This doesn't mean that I disagree with bug 148145...

Yeah, you knew which bug I meant really. ;-) (Bug 148545)

Comment 6

[David Tenser [:djst]]

Daniel, can you give me a link to these usability tests? I fail to understand
how users would find it easier to use this clearly non-standard colunm picker
widget instead of right-clicking the columns, which is standard behavior, at
least on every Microsoft product I've tested, and they should know about usability.

If usability tests show that the column picker widget is useful, I don't
understand why other programs haven't implemented it already. The users who
wants to change the columns should know that right clicking on the columns is
the standard behavior.

Comment 7

[Sander]

Agreeing with comment 2 and 4 and also recommending wontfix - I have never
right-clicked any column-headers to get options on which columns to show (and
this is in fact not even possible in explorer, access or find in windows 98 -
making me assume this is win2k/XP behaviour only), while on the other hand the
functionality of the current column-picker widget was intuitively obvious to me.

Comment 8

[David Tenser [:djst]]

Sander, you can't even change the columns in Win98 Explorer. It it was possible,
right-clicking on the columns would be the way to do it. Try it in Outlook
Express, if you have that program installed. I understand if you don't. :) 

Bug 148545 is the important bug to fix. This bug is just to make the UI less
cluttered. In fact, the column-picker widget also takes up valuable space for
the columns themselves, which for example is a problem in the Sidebar panel.

CC'ing mpt. What's your opinion? Isn't a context menu the standard behavior or
am I way out there?

(Kyle Yuan, thanks for the tip about the simplified bug report page.)

Comment 9

[David Tenser [:djst]]

Since no one with the right knowledge of UI can step up and knock me down, I'm
confirming this rfe as NEW. 

Comment 10

[Roman R.]

The argument that the column picker wastes space is invalid because it is hardly
wider than the scrollbar, and it could probably be made the same width as the
scrollbar. Nevertheless, I agree that the context menu should do what the column
picker does.

Comment 11

[David Tenser [:djst]]

> The argument that the column picker wastes space is invalid

My folder pane doesn't need a vertical scrollbar, so the column picker really
does waste space for the columns. Also, removing it would make the UI look a bit
cleaner.

Comment 12

[Roman R.]

The only case that I can think of when the folder pane wouldn't need a vertical
scrollbar is when you have just several messages in the folder. In that case, I
think, you can just open each message to see additional information. Your case
is not typical, IMO.

When I first noticed the picker, it didn't seem to clutter the UI. On the
contrary, it prompted me to click on it. That's how I learned how configure
columns in TB. I don't this is a big deal. If it stays, it's OK, and if goes and
its functionality is transferred to the context menu, it is also fine with me.
There are bigger problems with the program.

Comment 13

[David Tenser [:djst]]

Attachment: Screenshot of mail window with useless widgets

As you see in this screenshot, there is no vertical scrollbar for the folder
pane to the left, so this column picker widget does indeed waste horizontal
space for the folder pane.

Comment 14

[Roman R.]

Hmm... I haven't even noticed the picker in the left pane, and the when
mentioned the folder pane, I was actually looking at the message pane. You are
right, it does waste space in the folder page.

Comment 15

[Pham]

David, standard is good, but I never discovered right-click column=list until I
saw this bug. Column pickers let me see that I can click on something.

Comment 16

[Stef Walter]

I'm working on bug 212789 this affects the horizontal scrolling functionality
quite a bit. Whether the column picker is in our out, has a large effect on the
scrolling code for the tree: 

 - Where it goes in a horizontally scrolling tree
 - The size (right now it's wider than a scrollbar)
 - Whether it scrolls or not etc... 

It's a bit of an oddball, but I don't mind coding around it as long as there's a
consensus. 

Comment 17

[Jan Varga [:janv]]

Neil, what do you think?
It would make the tree widget layout simplier, especially for horizontal scrolling

Comment 18

[[e-mail]]

Well, in the case of the folder pane, I think it would be nice if the tree
should be able to draw its full width even if it has a column picker. As it is,
if your theme's column picker is wider than a scrollbar then it's wasting a few
pixels even when the scrollbar is required.

In the case of the thread pane, I want to be able to hide the 40% of the columns
that I don't use without having to scroll them out of view - as I only show 5
messages in the thread pane at once a horizontal scrollbar would waste space.

Comment 19

[Jan Varga [:janv]]

(In reply to comment #18)
> Well, in the case of the folder pane, I think it would be nice if the tree
> should be able to draw its full width even if it has a column picker. As it is,
> if your theme's column picker is wider than a scrollbar then it's wasting a few
> pixels even when the scrollbar is required.

that's bug 119115

> 
> In the case of the thread pane, I want to be able to hide the 40% of the columns
> that I don't use without having to scroll them out of view - as I only show 5
> messages in the thread pane at once a horizontal scrollbar would waste space.

We're not going to change the thread pane behaviour, we just propose column
picker removal. The same functionality would be achieved via context menu.

Note, that horizontal scrolling only works if columns are not flexible.

Comment 20

[[e-mail]]

Hmm... I've just thought of a potential problem. You see, my rightmost column,
the junk column, is fixed only slightly wider than the scrollbar, so I need the
column picker to ensure that it doesn't get hidden under the scrollbar.

Comment 21

[Jan Varga [:janv]]

I guess, in the new tree widget layout, the scrollbar would take column picker's
place.

col0|col1|col2|^ - up arrow
               |
               |
               |
               | - down arrow
<------------->C - scroll corner

Comment 22

[[e-mail]]

How would you stop the columns moving when you hide the scrollbar?

Comment 23

[Jan Varga [:janv]]

Hmm, good point, I have to think about it a little bit more.

Comment 24

[:aceman]

I also don't like that the column picker takes space in the folder pane. I would
suggest that the last column's content spans also under the column picker. Like
this:

columntitle1|columntitle2|^|  (<- the picker)
content_Col1|contentsOfCol2|
content_Col1|contentsOfCol2|

Comment 25

[Jens Bannmann]

Mike, could you have a look at this?

(Others: Mike is the foundation's user experience expert)

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

I'd suggest that you examine this question from the perspective of attempting to provide a UI that both meets user expectations and provides a way to accomplish common tasks.

Adding/removing columns to the mailbox/folder pane at the left seems like a very uncommon task, and the widget doesn't need to be there since it's not a primary UI function.

Adding/removing columns to the mail header pane at the right, otoh, is a fairly frequent task to assist a user with sorting and organizing a mailbox. Bug 148545 would provide a secondary UI mechanism to get at this common function, but I'd expect there to be a good number of users (trained from use of Netscape and other mail clients) who would look for this widget in this pane.

I'd recommend partial wontfix, I guess ;)

Comment 27

[Mark Banner (:standard8)]

(In reply to comment #26)
> Adding/removing columns to the mailbox/folder pane at the left seems like a
> very uncommon task, and the widget doesn't need to be there since it's not a
> primary UI function.

My comment here would be that yes it is uncommon and I wouldn't mind the widget being removed but we must still provide a way to add in the existing extra columns - I use them a lot, and I absolutely hate it when I have to use thunderbird and I can't add those columns (total mails/folder size) in.

Comment 28

[Karsten Düsterloh]

(In reply to comment #26)
> Adding/removing columns to the mailbox/folder pane at the left seems
> like a very uncommon task, and the widget doesn't need to be there since
> it's not a primary UI function.

I beg to differ, especially if you have more than one column. Eg., I use name/unread/total and occasionally use the columnpicker to show the size column.
(But that's just my usecase - and in my usecase, I have quite a number of open mail and news folders, so the scrollbar is shown also.)

> Bug 148545 would provide a secondary UI mechanism

In my experience, (right-click) context menus are very obscure for non-tech-savvy users, so this shouldn't be the only way of getting that functionality.

In toto, the "problem" here can be solved very simply in the userChrome.css, just by adding the rule

  #folderTree treecolpicker {display: none}

IMO, the functional gain of having a _visible_ columnpicker is much higher than the loss of estate in lowly used profiles - so I'm for WONTFIX also.

Comment 29

[Mike Beltzner [:beltzner, not reading bugmail]]

Right-clicking is starting to transition from the gesture repetoire of the uber-geek into the common user. We're seeing it used more and more in OS X and Windows as an only-path to "associated tasks", and evidence is showing that in client apps its becoming a more familiar gesture.

Ultimately I have little say in suite-related decisions, although I'm happy to contribute. In addition to my thoughts in comment 26, I'd add the point that while  the real estate taken by this widget is teeny-weeny, every pixel of space taken up by some element ends up distracting the user. The argument shouldn't ever be for removing UI, it should be for adding it in the first place.

What problem is this trying to solve? Presenting an unread count? Do we think an unread count is something that users frequently toggle on/off, or set once and forget? One answer implies a tool for flipping that switch, the other implies a pref (or even better, a default based on what we think is best for users.)

My feeling is that unread count is something we should either display or not display. Same with the other columns in the left-hand pane. The right-hand pane, otoh, is something where the columns used result in different support for search and filtering behaviour by the user, and as such, a tool in the UI for flipping those switches seems like a good approach.

Comment 30

[:aceman]

For reference, my comment 24 was already implemented in some other bug.

Also, Thunderbird allows right-clicking the column headers to show the menu with columns to pick (the same one as clicking the picker will). But the picker is still there as the rightclick feature had to be specifically coded. I think it would make sense to implement it directly in the <tree> XUL element. Showing context menu for a row when clicking on the headers is strange and also causes problems in Firefox dialogs (like it also sorts in addition to showing menu).

Comment 31

[Frank-Rainer Grahl (:frg)]

With the xul tree and Gecko going the way of the dodo lets call this wont fix. No one is working on enhancements to the xul tree and the picker is the standard way to do this. It will not block adding additional functionality like TB did.