Remove the column picker widget from the message columns

NEW
Unassigned

Status

SeaMonkey
MailNews: Message Display
--
enhancement
16 years ago
3 years ago

People

(Reporter: djst, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 1

16 years ago
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.
Depends on: 148545

Comment 2

16 years ago
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

16 years ago
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

16 years ago
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

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

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

Comment 6

16 years ago
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

16 years ago
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.
(Reporter)

Comment 8

16 years ago
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.)
(Reporter)

Comment 9

16 years ago
Since no one with the right knowledge of UI can step up and knock me down, I'm
confirming this rfe as NEW. 
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

15 years ago
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.
(Reporter)

Comment 11

15 years ago
> 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

15 years ago
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.
(Reporter)

Comment 13

15 years ago
Created attachment 122484 [details]
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

15 years ago
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

15 years ago
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.

Updated

14 years ago
Blocks: 212789

Comment 16

14 years ago
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

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

Comment 18

14 years ago
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

14 years ago
(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

14 years ago
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

14 years ago
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

14 years ago
How would you stop the columns moving when you hide the scrollbar?

Comment 23

14 years ago
Hmm, good point, I have to think about it a little bit more.
Product: Browser → Seamonkey

Comment 24

13 years ago
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|

Updated

13 years ago
No longer blocks: 212789

Updated

13 years ago
Assignee: sspitzer → mail

Comment 25

13 years ago
Mike, could you have a look at this?

(Others: Mike is the foundation's user experience expert)
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 ;)
(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

12 years ago
(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.
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.
Assignee: mail → nobody
QA Contact: olgam → message-display

Comment 30

3 years ago
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).
You need to log in before you can comment on or make changes to this bug.