Changing type of address (to, cc, etc)
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: mozilla, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36
Steps to reproduce:
Composing a message, particularly replying, and want to change the type for some addresses (e.g. to -> cc, cc -> to, etc) in 79b2
Actual results:
It is now required that you delete and re-add an address to change the type of the address - you can't even drag/drop it
Expected results:
The previous mechanism was far simpler, plus, I'm now required to tab twice to get to the subject line instead of just once. The latter is a minor nit, but gratuitous ui changes that make things worse instead of better are a pet peeve.
|
||
Comment 1•4 years ago
|
||
Good progress on this in bug 1601749
|
||
Comment 2•4 years ago
|
||
(In reply to Alan Batie from comment #0)
It is now required that you delete and re-add an address to change the type of the address - you can't even drag/drop it
You can just select, use context menu to move to a specific field.
|
||
Comment 3•4 years ago
•
|
||
(In reply to Alan Batie from comment #0)
Hey Alan, allow me to elaborate a bit to address your concerns.
As Magnus pointed out, you can now easily select multiple recipients and change their recipient type in one go using selection context menu.
Composing a message, particularly replying, and want to change the type for some addresses (e.g. to -> cc, cc -> to, etc) in 79b2
Good news for you: Changing the type of "some addresses" has just become significantly easier than before!
Minimal steps count for changing 10 non-adjacent recipients from To -> CC:
-
TB68 (one recipient text per row, mixed types):
- Mouse: 20 clicks (10x 2 clicks, one to open type dropdown, one to select new flavor), plus scrolling and and mouse target hassles.
- Keyboard: 60 keypresses (10x 6 keypresses, shift+Tab, Alt+cursor down, cursor down, Enter, tab, tab)
- Both selection and action steps are proportionately increasing with the number of recipients.
-
TB78 (multiple recipient items - aka pills - per row, grouped by type):
- Mouse: 12 clicks = 40% less clicks! (10x 1 click to Ctrl+select recipients, right-click on recipients selection to get context menu, click "Move to CC" - you have just changed the type of a potentially unlimited number of recipients with only 2 clicks)
- Keyboard: 22 keypresses = 63% less keypresses! (10x 2 keypresses to select recipients with cursor-left, spacebar; 1 keypress to open context menu on selection, 1 keypress to trigger "Move to CC")
- Only selection steps are proportionately increasing with the number of non-adjacent recipients. Action steps are never more than 2 via selected recipients context menu, regardless of number of recipients.
So generally speaking (ignoring the fixed 2 action steps), for changing type (To/Cc/Bcc) of non-adjacent recipients, we have reduced selection steps by 50% for mouse, and by 67% for keyboard (for non-adjacent recipients). For adjacent or all recipients it's even less steps, e.g. we have Ctrl+A - select all recipients of same type; another Ctrl+A will then select all recipients of entire recipient area). You can even select recipients of different types and move them in one go. Altogether, that's a considerable gain in ux-efficiency.
It is now required that you delete and re-add an address to change the type of the address - you can't even drag/drop it
As Wayne said, drag and drop will be implemented, as well as even more efficiency/methods for selecting multiple recipients.
The previous mechanism was far simpler
CLEARLY NOT per above steps count, and quite the opposite: Previously, it was way more difficult because recipients of the same type were not even reliably grouped together.
plus, I'm now required to tab twice to get to the subject line instead of just once.
Yeah, that's a bit arguable, but I think it is meant to ease the creation of subsequent recipient pills using tab at a very low cost.
On the other hand, tabbing through the recipient area used to have one stop per recipient (potentially unlimited number of stops), whereas now it's maximally 2 stops per typed row.
Description
•