844475 - When selecting multiple messages, archive and delete buttons should use the same position and visibility as when selecting a single message

Status: ASSIGNED

(Thunderbird :: Message Reader UI, defect)

Description

When selecting multiple messages, the area above the message summaries shows two buttons:

[Archive] [Delete]

There are two problems here:
- [Archive] is also displayed when the button is removed for the single-message view.
- The order is fixed. When the single-message view is customized to look like [Reply] [Forward] [Junk] [Delete] [Archive], the delete and archive buttons are swapped when selecting multiple messages.

The archive and delete buttons should keep the visibility and relative position when selecting multiple messages.

Comment 2

[Ben Bucksch (:BenB)]

Attachment: Single email

Screenshot from https://thunderbird.topicbox.com/groups/ux/T5b86ff2aace9a787-Mca7526cba780ac95a272fd0a

Comment 3

[Ben Bucksch (:BenB)]

Attachment: Thread - buttons moved

Comment 4

[Ben Bucksch (:BenB)]

Poster wrote:
When quickly skipping through mails, this has lead me to accidentally delete mails multiple times.

In my opinion the buttons should not switch places, for thread vs single mail view.

Comment 6

[jdien07]

For such a readily fixed bug with so much salience, it seems unfortunate that this has been left unaddressed for thirteen (!) years. Could someone at least set a priority for it?

Joe

Comment 7

[Wayne Mery (:wsmwk)]

For such a readily fixed bug

Not necessarily. From bug 1893394 comment 4, "See also [draft patch] https://phabricator.services.mozilla.com/D208719#7165423, last sentence." which states: "This UI has been like this for ages so changing the order will for sure create a waterfall of bug reports of users used to the previous one. We will rebuild the thread view UI later in the future."

In other words, a thoughtful, holistic, future proof approach is most desired.

Comment 11

[Gavin Stokes]

The button collection should remain static, with inapplicable buttons being greyed out. Controls should not simply disappear when they're in applicable. This is a longstanding UI standard, for several reasons. Users learn

1. The function exists
2. Where it resides
3. That some conditions must be satisfied for it to be applicable

The solution is pretty simple, as far as I can see: Keep all the buttons all the time, and enable/disable them as appropriate.

Comment 12

[jdien07]

That's an argument for never changing anything ever again. I agree with Gavin. It's a UI standard expected behavior. Someone will always complain about anything. You have to focus on what will work for most people.

Comment 13

[Anje]

Senario of current situation:
When people use 'threading' and move down the Message List to delete several emails in succession, they may have many single emails in a row followed by a 'thread'. The mouse is fairly static and clicking on delete becomes an auto reflex operation, which when it's in same location is not a problem, but when the 'thread' is selected and the user auto clicks but instead of a delete, the 'Archive' option is selected.

If this is an imap gmail account, the 'labels' get removed and the entire thread of emails get archived in the 'All Mail' folder.
If you do not subscribe to see the 'All Mail' folder because it doubles the space used on computer, then access to those emails seems to be lost. Emails appear to be deleted, user may even think they are deleted, but then wonder why they are not in the Trash and why they seem to have disappeared into the ether. Logging on to the gmail webmail account and trying to locate the emails with no labels in the 'All Mail' folder is not as simple as it sounds because most may well be deliberately archived.
Even if the emails are still in an Archive imap folder, it now involves additional work load to correct the situation.
Doing this is not productive and causes a problem with work throughput.

Alternatively, if many emails are 'threads' and you are selecting to 'Archive' but then have a few single emails, you will accidentally click on the 'Delete' button.

Either way, it's very unproductive , time consuming and can be a very real issue if this is not discovered before you Exit Thunderbird. User may have the setting to 'Empty Deleted on Exit' selected. There is a real case for accidental data loss.

In the Support Forum have come across both of the above senarios on various occasions over the years.

I'm advising people:
if it becomes a real issue the workaround is remove the threading first, then sort by subject to group emails of same thread. Not the best solution as it increases the number of clicks - not good for RSI issues.

As Thunderbird is undergoing many improvements in design etc, it's encouraging to hear "We will rebuild the thread view UI later in the future".
Please forgive me if I cause some upset but that statement does come across as a bit dismissive of a genuine problem with the current design.
'Later in the future' does come across to readers like MAÑANA, the (indefinite) future.

Is it possible to clarify as to when a rebuild of that particular part of the thread UI is expected to be included in a major release ?

Comment 16

[jdien07]

It sounds like the only way to get this to happen is for the community to speak up, given all the years that have gone by. Is there some way we could set up a poll or otherwise vote for this to be a priority?

Comment 17

[Anje]

(In reply to jdien07 from comment #16)

It sounds like the only way to get this to happen is for the community to speak up, given all the years that have gone by. Is there some way we could set up a poll or otherwise vote for this to be a priority?

When working quickly and using threaded preference, the jumping sideways of the 'Archive' button to the vacated space previously used by the 'Delete' button causes all kinds of issues.

I think there are plenty of people who have for many years found the current design to be below an expected standard. This bug alone has several comments by different people and there are several duplicate reports of this bug.
In addition, Wayne has also posted a link to the 'connect' forum where people have also posted their complaints on this problem with the current design.

There were problems back in version 38.2:
https://support.mozilla.org/en-US/questions/1084546

Comment 18

[Hans Dijkema]

I filed this report bug 893394 about 2 years ago. I still would like this UI behaviour to be more consistent.

Comment 19

[Derrick Charbonnet]

All that needs to happen is for the two buttons on the Thread View to be moved to the left one button width. They do not need to switch places.

Comment 20

[Derrick Charbonnet]

The "Archive" button on the Thread view could be moved an additional space left which would put it in the same place as the Single view.

Comment 21

[jdien07]

Fixing it could be done trivially in so many ways, and yet in the thirteen years it has been reported, no one has even set a Priority level for it yet. It's literally not even on the to-do list.

Comment 22

[Wayne Mery (:wsmwk)]

Thank you for all the suggestions. However, the work can happen only after design has been done as previously mentioned in https://phabricator.services.mozilla.com/D208719#7165423. The bug will be updated when it reaches the top of the (currently long) list to be scheduled and prioritized. Until then, more questions or comments will not help.

Comment 23

[Alessandro Castellani [:aleca]]

Thank you all for the feedback and for raising this issue.
I'll take this and offer some UX improvements woth our designers input.
Apologies for the delay

Comment 24

[jdien07]

(In reply to Alessandro Castellani [:aleca] from comment #23)

Thank you all for the feedback and for raising this issue.
I'll take this and offer some UX improvements woth our designers input.
Apologies for the delay

Thanks so much! :)

Comment 25

[Alessandro Castellani [:aleca]]

Attachment: Bug 844475 - Synchronize the style and position of some of the buttons on the multimessage view. r=#thunderbird-front-end-reviewers

Comment 26

[Alessandro Castellani [:aleca]]

All right, here's a quick recap of the initial action plan.
In my patch I will introduce these changes:

• Show the following buttons in the following order: [Archive] [Spam] [Delete] [More] [Star]
• The style of the buttons will respect the customization of the message header for single messages (icons, icons + text, only text)
• The [Star] button will only be active if all the messages of the thread are starred (same behavior of collapsed thread/card)

We could add many more things to this but this is just an intermediary improvement to mitigate some annoying UX we've had for too long.
During the year we will implement a proper conversation view so the entire multi message view as it is will be rebuilt, bringing proper consistency and sanity of actions between single and multi message.

Thank you all for your feedback and your patience.

Comment 27

[Alessandro Castellani [:aleca]]

I ended up simplifying a bit this patch in order to land it faster.

I excluded from this patch:

• Adding the Spam button. This is a bit more complicated as counting the spam score of each selected message and making a decision on how to handle when some messages are marked as spam and others are not creates some performance issues.
• Showing the More button. The context menu of the thread is pretty big and it's not as straightforward as I thought bringing it into the multimessage view.

These exclusions are just temporary since we're working on the new database and conversation view, which will bring a unified and consistent UI no matter if the user selects a single or multiple messages, or a thread.

More work to improve this will happen through the year, but for now, adding the star button and synchronizing the style is a good step forward.
Once we allow customizing the actions in the message header we will also do that for the multiemessage view.