1612055 - Default order of thread pane columns changed: all iconic columns first (Thread, Starred, Attachments, Read, Junk Status /spam), then text columns: error-prone, useless UI.

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect, P1)

Description

[Jean-Philippe MENGUAL]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

Upgrade my nightly

The problem is that now, the status of the message (read and spam) are in the 3 first columns.

While the read status may be useful for some users, the spam score is a pain for a blind people, because the voice speaks it, but a basic users has no idea about what is this number.

Actual results:

Could you put this info rather on the last column please?

Or making the change of columns order accessible (today, impossible without a mouse).

Thanks

Regards

Comment 1

[Alex ARNAUD]

I confirm the issue and now Orca says "unread 0 object etc" or "unread 100 object etc". 0 or 100 are the spam score.

As nowadays most of the users as the dedicated folder for spam, I suggest to drop the spam column for the default display.

Note that the blind people has no way to drop or change the column order with the keyboard. See bug 370437 .

Best regards.

Comment 2

[Magnus Melin [:mkmelin]]

I think this is related to the fixes mozilla-central did for the column order. Agreed what's shown now is annoying also for users in general.

Comment 3

[Wayne Mery (:wsmwk)]

bug# ?

Comment 4

[Thomas Lamprecht]

Hopping on this thread as my "issue" is related, similar to OP I had the same dislike with the new ordering, especially as I sometimes click the SPAM "Fire" icon by mistake when I want to expand or collapse a thread, the placement is really bad UX, IMO.

But anyway, I thought well just move them and be done, but that is not a workaround because every new start of Thunderbird moves it back to the original positions.
So in addition to fixing that UX default issue, I think that it would additional help a lot if the thread pane should remember customized column order, e.g., saved in ones profile.

Comment 5

[Thomas D. (:thomas8)]

In combination with bug 1622255 (custom order not remembered, resets to initial 'false' default at every start of TB), this is a significant UX failure, highly error-prone, useless-UI. Read column now almost totally unusable, too easy to miss and then your read messages end up in spam (violating ux-error-prevention). Having all icon columns together does not make them easier to tell apart imo, so whilst this looks superficially neater, it's probably disadvantageous.

Also, I have never customized icon columns to the front (so it's like the initial default which Daily comes with), but "Restore column order" puts them back between text columns (which is now another default which Daily comes with). Having two competing "defaults" is clearly irritating UX, also bad for support.

So whilst this doesn't break the application, I'd think it's serious enough to warrant looking into this sooner rather than later.

Comment 6

[Thomas D. (:thomas8)]

@aleca: ^^ pls see my comment 5

This messes up our default UI in message list, any ideas how to fix this and/or bug 1622255?

(In reply to Magnus Melin [:mkmelin] from comment #2)

I think this is related to the fixes mozilla-central did for the column order. Agreed what's shown now is annoying also for users in general.

Magnus, (as Wayne tried to ask in comment 3): Do you have a bug number for the mozilla-central change which broke this for TB?

Comment 7

[Alessandro Castellani [:aleca]]

I haven't had the time to look into this or bug 1622255, but I suspect they might be related and fixable by identifying the common regression.
I see if I have some capacity next week for bug 1622255, but definitely this should be fixed before 78.

Comment 8

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Bogus "out of the box" order (fake default) with all icon columns first, and 'Read' next to 'Spam'

So this is the bogus / pseudo default order which TB keeps reverting to, stubbornly ignoring both user settings and the intended, real default order (available via "Restore column order").

Comment 9

[Thomas D. (:thomas8)]

Alex ARNAUD and Jean-Philippe MENGUAL, thank you for reporting this. The issue has several aspects. I have moved the screen reader accessibility aspect of the "Junk Status" column to:
Bug 1643467 - Improve screen reader experience of 'Junk status' column in thread pane / message list

(In reply to Jean-Philippe MENGUAL from comment #0)

While the read status may be useful for some users, the spam score is a pain for a blind people, because the voice speaks it, but a basic users has no idea about what is this number.

(In reply to Alex ARNAUD from comment #1)

I confirm the issue and now Orca says "unread 0 object etc" or "unread 100 object etc". 0 or 100 are the spam score.

Let's fix that in Bug 1643467.

As nowadays most of the users as the dedicated folder for spam, I suggest to drop the spam column for the default display.

No, the spam column is actually called "Junk Status" (which blind users won't know because it's not accessible), and clicking on the flame icon in that column will change the junk status from "Not Junk" to "Junk" or vice versa. So that's useful functionality for people to sort through their inbox and mark spams, or to sort through their Junk folder and un-junk false positives.

Note that the blind people has no way to drop or change the column order with the keyboard. See bug 370437 .

Yeah, that's bad, sorry for that. Inherited from XUL element which has never been accessible.

Comment 10

[Jorg K (CEST = GMT+2)]

Hmm, I have an add-on that adds a custom column. And that's not working now :-(

Comment 11

[Alessandro Castellani [:aleca]]

Maybe regressed by bug 1607575?

Comment 12

[Alessandro Castellani [:aleca]]

Attachment: 1612055-column-order.diff

This restores the ability to reorder columns, which now persist on restart by applying the changes introduced in bug 1607575.

Things to do which I'm not sure how:

• Update the comment of _saveColumnStates() which reference the old and deleted restoreNaturalOrder() method.
• Define a better default column order. I tried applying the style="-moz-box-ordinal-group: 1;" attribute but that doesn't seem to affect the order of the columns.

Pinging Kirk Steuber on the patch to ask for his insight.

Comment 13

[Robin Steuber (they/them) [:bytesized]]

Comment on attachment 9154380 [details] [diff] [review]
1612055-column-order.diff

Edit: Sorry, I don't know why my markdown didn't render in this message. It works in the "Preview" tab :(

Hmm, I feel like I need to give a disclaimer that I only worked in this area of the codebase briefly. I'll do my best to help, but I won't be offended if you want to get help from someone that works on XUL. That being said, I spent some time re-reading the regressing patch, and I think remember it pretty well, so as long as not too much else has changed, I should be able to help.

It looks like your current patch works because the elements that you are setting `.ordinal` on are instances of `MozTreecol`, so [this setter](https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/toolkit/content/widgets/tree.js#385) is activated, which sets `element.style.MozBoxOrdinalGroup`. This seems correct to me. We currently want to use that setter rather than setting `element.style.MozBoxOrdinalGroup` directly, since the setter also sets the `ordinal` attribute, which allows us to use XUL attribute persistence.

Regarding `restoreNaturalOrder()`, if you need it, you should be able to use the [replacement in `MozTree`](https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/toolkit/content/widgets/tree.js#1138), like this:
```Javascript
tree._ensureColumnOrder(tree.NATURAL_ORDER);
```
([source line](https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/toolkit/content/widgets/tree.js#228))

As for defining a default column order, specifying ordinal attributes on the `MozTreecol`s should continue to work because of [this shim](https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/toolkit/content/widgets/tree.js#380-382) ([example](https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/browser/components/places/content/places.xhtml#384-385)). It should probably be noted, however, that this may not play nicely with `_ensureColumnOrder(tree.NATURAL_ORDER)`. I believe that function restores the columns to the DOM ordering. In fact, once the columns have been reordered, I don't think there is any way of determining their original `ordinal` values. So if you want to change the default ordering, you might want to actually re-order the elements in the original XHTML source.

If you haven't already looked at it, you might be interested in [this patch](https://phabricator.services.mozilla.com/D59763) where I did something similar to what it looks like you are doing here. The context is that, in a previous patch, I wrote a script to convert all instances of `element.ordinal` to `element.style.MozBoxOrdinalGroup`. That ended up breaking `MozTree`s for multiple reasons. So in this patch, I fix up `MozTree` to be able to work after the removal of XUL ordinal support.

Hopefully that helps. Let me know if you need anything else.

Comment 14

[Alessandro Castellani [:aleca]]

Thank you so much for the detailed explanation, that was really helpful.

It looks like your current patch works because the elements that you are setting .ordinal on are instances of MozTreecol

Correct, that's why I'm using the ordinal setter as I saw what you updated in that patch, I'm glad I got it right.

Regarding restoreNaturalOrder(), if you need it, you should be able to use the [replacement in MozTree]

We're not using that method anywhere (I'm 99% sure 😅️), but I was wondering if you could read this comment here and shed some light on it. Probably it's outdated and can be removed: https://searchfox.org/comm-central/rev/b3dc7ad59deb6d0e37499ed167d93c467fb1ccb0/mail/base/content/folderDisplay.js#751

So if you want to change the default ordering, you might want to actually re-order the elements in the original XHTML source.

Ah, interesting, that is very straightforward and simpler than using attributes.
I'll try.

Cheers

Comment 15

[Alessandro Castellani [:aleca]]

Speaking about default orders, what do you guys think about this:

/--------------------------------------------------------------------------------------------/
| Thread | Favourite | Read | Subject | Correspondents | Attachment | Spam | Date |
/--------------------------------------------------------------------------------------------/

Comment 16

[Jean-Philippe MENGUAL]

Hi,

(In reply to Alessandro Castellani (:aleca) from comment #15)

Speaking about default orders, what do you guys think about this:

/--------------------------------------------------------------------------------------------/
| Thread | Favourite | Read | Subject | Correspondents | Attachment | Spam | Date |
/--------------------------------------------------------------------------------------------/

It nearly mathces to the traditional order in Thunderbird, indeed, so would be right. To set some improvements according to users habits (on other clients) and accessibility, I would suggest this alternative:

/--------------------------------------------------------------------------------------------/
| Thread | | Read | Favourite | Attachment | Correspondents | Subject | Date | Spam |
/--------------------------------------------------------------------------------------------/

Regards

Comment 17

[Robin Steuber (they/them) [:bytesized]]

(In reply to Alessandro Castellani (:aleca) from comment #14)

I was wondering if you could read this comment here and shed some light on it. Probably it's outdated and can be removed: https://searchfox.org/comm-central/rev/b3dc7ad59deb6d0e37499ed167d93c467fb1ccb0/mail/base/content/folderDisplay.js#751

Huh. Well, I've read the comment through a couple of times. That interface is now called TreeColumn rather than nsITreeColumn, but it otherwise seems like a reasonably accurate description of column positioning and how it relates to index and ordinal. But I'm not entirely sure why the comment is where it is. I thought I would take a look through the history to see if it used to be more relevant. As far as I can tell, that comment was first checked in in this commit. To me, that just makes things more confusing. Currently, the function at least uses ordinal, which makes the comment seem kinda related. But it didn't even touch ordinal when it was first checked in.

I went back to the bug for the patch, thinking that maybe I could find an earlier origin that the code had been moved from, or some sort of explanation. I didn't read through the whole bug, because it is rather lengthy and seems mostly unrelated to the question at hand. But I did find the first draft of the patch that added the comment. And it reveals that that comment was in the function back when it was just a function name with the additional comment // XXX nop for now.

So I'm not sure what to tell you exactly. I think the comment is accurate. But it doesn't really seem to belong there and there doesn't even seem to be a good historical reason why it is there rather than somewhere else. It can probably be moved or removed.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #15)

Speaking about default orders, what do you guys think about this:

/--------------------------------------------------------------------------------------------/
| Thread | Favourite | Read | Subject | Correspondents | Attachment | Spam | Date |
/--------------------------------------------------------------------------------------------/

I don't like it, because it's less useful than the current default order, which I believe was carefully designed.
This is the current default column order:

Thread	Starred	Attachments	Subject	Read	Correspondents	Junk Status	Date
/	*	📎	Re: [Bug 1612055]	o	John Doe	🔥	5/6/2020, 12:00 AM

Rationale of column order wrt proposed changes:
Columns are ordered so as to allow for a fast and intuitive message handling workflow:

• easily identify messages with attachments (attachment column in front). That's important, and attachments are associated with message subject (current order), not with correspondents (so that wouldn't look like an intuitive order to me).
• after reading subject (at least) --> mark read. Imo that's slightly more natural in terms of direction than having to go back to the start of subject to mark read after reading it. Read column isn't very important except for toggling the status, because non-bold is the stronger indicator for read, so read column doesn't deserve front position where it would just distract.
• after checking (subject and) correspondent --> mark spam, because most spams are associated with unknown senders.
• having Starred and Read next to each other isn't a good idea because that makes both of them easier to miss, which is error-prone.
• current spread distribution of clickable small icon columns
  • allows for muscle memory to associate function of column with its position
  • easily identify column status (as opposed to bundling different small columns together)
  • avoid mis-clicks (ux-error-prevention).

Unless there are compelling advantages of changing the existing default column order, I wouldn't touch it. No complaints so far (not a good argument, but still true), and users can always customize. Any changes should explain their rationale, because this is a very exposed and sensitive area.

Comment 19

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #18)
Sorry, premature comment commit. I'm still editing comment 18.

Comment 20

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #18)
Please refer to my updated comment 18 for detailed reasons in favor of the existing default column order.
We shouldn't change that imo.

Comment 21

[Alessandro Castellani [:aleca]]

Unless there are compelling advantages of changing the existing default column order, I wouldn't touch it. No complaints so far (not a good argument, but still true), and users can always customize. Any changes should explain their rationale, because this is a very exposed and sensitive area.

I like your proposed ordering, and I personally don't have a strong opinion on specific columns since they can all be reordered.
My proposal was to optimize the row for screen readers and visually impaired users.

Maybe we should ask our users which info are more important for them, since those users are primarily the type of users that can't easily (or maybe can't do it at all) change the order of columns to fit their needs.

I think this is a unique scenario we should optimize for them, since any other user can update the order as they want.

Comment 22

[Magnus Melin [:mkmelin]]

Comment on attachment 9154380 [details] [diff] [review]
1612055-column-order.diff

Review of attachment 9154380 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, r=mkmelin
Maybe you still want to address comment 17

Comment 23

[Magnus Melin [:mkmelin]]

Regarding column order, I think we still need to optimize for the average user. I would consider dropping "read" status from the default columns though, since it's duplicated information (we have bolding too).

Comment 24

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #23)

Regarding column order, I think we still need to optimize for the average user. I would consider dropping "read" status from the default columns though, since it's duplicated information (we have bolding too).

Please don't. It's not just a status display column, it's a per-message toggle button, the only efficient way of toggling read status on or off with mouse, especially for marking messages unread again when they were prematurely marked read automatically after few seconds of display (adjustable timer). It also allows changing read status of many messages efficiently (even without having to display them).

Comment 25

[Magnus Melin [:mkmelin]]

You can do all that by keyboard presses too, and for the most part normal usage is that one would not change the read status of a message manually, but just let it become marked read when it's read. So all I'm saying is I doubt it's very useful for the majority of people. Some people could want it, but we have many of such options. Anyway, not this bug.

Comment 26

[Thomas Lamprecht]

| (In reply to Magnus Melin [:mkmelin] from comment #23)

Regarding column order, I think we still need to optimize for the average user. I would consider dropping "read" status from the default columns though, since it's duplicated information (we have bolding too).

The read state allows also easy sorting for unread messages, so IMO valuable for new users. Further, I do not think one should expect new users to know keyboard shortcuts - so I'd rather say that this is an argument for keeping it as default.

(In reply to Thomas D. from comment #18)

Unless there are compelling advantages of changing the existing default column order, I wouldn't touch it.

FWIW: A big +1 from my side here.

Comment 27

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #21)

I like your proposed ordering

FTR, I just proposed to keep the current default order (before this bug occured), because it looks carefully designed to be maximally intuitive and efficient.

My proposal was to optimize the row for screen readers and visually impaired users. [snip]
I think this is a unique scenario we should optimize for them, since any other user can update the order as they want.

I have serious doubts on that approach, which (with all respect) seems upside-down: I think we must fix accessibility problems by making things accessible, not by rearranging everyone's UI to favor screenreaders and the small group of their users, and then expect the majority of regular users to customize their UI for a useful UX.

Comment 28

[Wayne Mery (:wsmwk)]

I'm going to make an exception on not weighing in on UI issues.

A. Jean-Philippe If bug 1643467 is fixed, you would have much less concern about putting the spam score near the front? "the spam score is a pain for a blind people, because the voice speaks it, but a basic users has no idea about what is this number.

B. Generally I'm inclined to say don't change the order of things unless we have requests calling for it, or metrics. And full disclosure as a keyboard-centric user I don't have a strong history for using and clicking around the UI - like the junk and read column - in part because my message volume is such that even when I am using the mouse I hate moving the mouse to action buttons. However, if I did use the mouse more, I think I'd want to have most of the columns in I'd click in close together, such as junk and read. This is a long way to say I'm inclined to say change the order - having all these small "status" columns up front as Alex suggests is a cleaner, less busy look and is less work for mouse navigation.

C. I'm not sure we can assume a) the previous existing order is very carefully designed (AFAIK there have been very few user case studies in the history of Thunderbird) and b) that after 15? years in that state that usage patterns or needs haven't changed, and it isn't due for an update.

Comment 29

[Thomas D. (:thomas8)]

OT:

(In reply to Wayne Mery (:wsmwk) from comment #28)

A. Jean-Philippe If bug 1643467 is fixed, you would have much less concern about putting the spam score near the front? "the spam score is a pain for a blind people, because the voice speaks it, but a basic users has no idea about what is this number.
B. ... However, if I did use the mouse more, I think I'd want to have most of the columns in I'd click in close together, such as junk and read. This is a long way to say I'm inclined to say change the order - having all these small "status" columns up front as Alex suggests is a cleaner, less busy look and is less work for mouse navigation.

You do realize that nobody on this bug has requested putting all icon columns to the front, right?
That's just the accidental bogus status that this bug is about, as seen in attachment 9154295 [details].
Having small click targets of "junk and read" icon columns "close together" would be highly error-prone with dataloss dangers.

C. I'm not sure we can assume a) the previous existing order is very carefully designed (AFAIK there have been very few user case studies in the history of Thunderbird) and b) that after 15? years in that state that usage patterns or needs haven't changed, and it isn't due for an update.

As always, I have provided detailed reasons (comment 18) why I think the current design makes sense, hence assuming "carefully designed" (which appears generally possible to certain extents even without user case studies). Anecdotal support from a real user in comment 26.
Of course, usage patterns might have changed, and updates might do good; I just think that changes to such exposed parts of the UI might be better handled in their own dedicated bug which lays out the rationale of the change, either based on careful design considerations with pros and cons, or perhaps based on case studies (where just counting usage will NOT be enough, but that's another story).

Anyway, as Magnus said, all those details are not part of this bug, sorry for the noise.

Comment 30

[Wayne Mery (:wsmwk)]

agreed, separate bug is appropriate.

Comment 31

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #28)

all these small "status" columns

For the avoidance of doubt, given that the Read column has already been misunderstood on this bug as a passive status display column: Starred, Read and Junk Status are not just status display icons, they are also convenient in-place status toggle buttons for each message allowing efficient mouse action going down the list.

Comment 32

[Jean-Philippe MENGUAL]

Hi,

(In reply to Wayne Mery (:wsmwk) from comment #28)

I'm going to make an exception on not weighing in on UI issues.

A. Jean-Philippe If bug 1643467 is fixed, you would have much less concern about putting the spam score near the front? "the spam score is a pain for a blind people, because the voice speaks it, but a basic users has no idea about what is this number.

Yes. If another info than the number 0 or 100 is transmitted to the accessibility stack, with a significant word, any user knows about it and it is less confusing. We could debate about UX but would become accesible anyway.

B. Generally I'm inclined to say don't change the order of things unless we have requests calling for it, or metrics. And full disclosure as a keyboard-centric user I don't have a strong history for using and clicking around the UI - like the junk and read column - in part because my message volume is such that even when I am using the mouse I hate moving the mouse to action buttons. However, if I did use the mouse more, I think I'd want to have most of the columns in I'd click in close together, such as junk and read. This is a long way to say I'm inclined to say change the order - having all these small "status" columns up front as Alex suggests is a cleaner, less busy look and is less work for mouse navigation.

C. I'm not sure we can assume a) the previous existing order is very carefully designed (AFAIK there have been very few user case studies in the history of Thunderbird) and b) that after 15? years in that state that usage patterns or needs haven't changed, and it isn't due for an update.

Yes, that is why I suggested the order seen in other clients. But it makes part of things users can suit with if infomration is accessible (not for a blind user, but any user needing an easy-to-understand text, eg. dys, fresh beginners, etc)

Best regards

e

Comment 33

[Alessandro Castellani [:aleca]]

Attachment: 1612055-column-order.diff

Comment update as per comment 17

I think we should land this as it consequentially fixes bug 1622255, and we can continue the discussion in follow up bugs, by prioritizing the accessibility of those icons.

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b5f9aca0d0a9
Restore default order of thread pane columns after bug 1607575. r=mkmelin

Comment 35

[Thomas D. (:thomas8)]

Comment on attachment 9155014 [details] [diff] [review]
1612055-column-order.diff

This should go into 78.

[Approval Request Comment]
Regression caused by (bug #): 1607575
User impact if declined: Order of columns in message reader keeps reverting into a useless and error-prone state (all icon columns first, Read toggle icon next to Junk toggle icon).
Testing completed (on c-c, etc.): ?
Risk to taking this patch (and alternatives if risky): Low.

Comment 37

[Wayne Mery (:wsmwk)]

Comment on attachment 9155014 [details] [diff] [review]
1612055-column-order.diff

Approved for beta

Comment 38

[Geoff Lankow (:darktrojan)]

Thunderbird 78.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/2240fa33634c