Closed Bug 1686379 Opened 4 years ago Closed 4 years ago

Provide an option to restore the old Compose window layout. The new one has terrible usability.

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: diamondavocado22, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Thunderbird 78 introduced a "redesigned compose window".

For me this is not an improvement and makes the usability of the window much worse. For example, adding a recipient via "CC" now requires you to press shift+tab five times to select "CC" and four times to select "BCC".

Furthermore, you can no longer change (for example) the "CC" list to "BCC" as you could previously; you have to create a whole new BCC line and cut/paste the recipient list.

These changes make composing an email more onerous and represent very poor usability for what seems like very little (if any) benefit.

Please provide an option to restore the previous/classic compose layout.

(In reply to diamondavocado22 from comment #0)

Thunderbird 78 introduced a "redesigned compose window".
For me this is not an improvement and makes the usability of the window much worse. For example, adding a recipient via "CC" now requires you to press shift+tab five times to select "CC" and four times to select "BCC".

Hi diamondavocado22 (nice name!), thank you for your feedback.
Indeed, for message replies, that's what it currently takes using keyboard only. For new messages, it's a bit better: CC requires 3x Shift+Tab, and BCC only 2x Shift+Tab from To-field, which has focus initially. You can keep holding Shift while doing the Shift keypresses, works even with one hand (left thumb and forefinger). Yeah, it's a bit cumbersome...

Please bear with us while we are working on several ways to optimize that scenario:

  • Bug 1667692 - Explore implementing keyboard shortcuts to show and focus important address rows (To, CC, BCC): Ctrl+Shift+T, Ctrl+Shift+C, Ctrl+Shift+B (like gmail) - I'll mark yours as a duplicate of that.
  • Bug 1616514 - Provide a way of showing Cc and Bcc addressing rows automatically when starting to write a message (esp. for enterprise)

In the meantime, I recomment the following workaround: Add a placeholder auto-CC address in account settings (e.g. invalid address "cc"):

≡ > Account Settings > YourAccount > Copies & Folders > (*check this option:*) [x] CC these email addresses: [cc ]

Now every composition on this account will have the CC field automatically open, with the invalid placeholder address, which is easy to delete (2x Backspace). Your tab-back-into CC cycle will now be reduced to 2x Shift+Tab, much better...

Furthermore, you can no longer change (for example) the "CC" list to "BCC" as you could previously; you have to create a whole new BCC line and cut/paste the recipient list.

Yes you can, or rather, NO, that's not how you do it... ;-)
Please refer to documentation how to change the type of existing recipients (e.g. via context menu of selected recipient items):
https://support.mozilla.org/en-US/kb/addressing-email#w_changing-recipient-type-how-to-move-recipients-to-another-address-field
Cutting the recipient list sounds wrong if it implies that you created recipients in the wrong row; that's a false transfer of TB 68 muscle memory.
In TB 78, type your To-recipients in To row, open CC-row (click on CC disclosure button, or shift+tab...) and type your CC-recipients directly into CC row.

These changes make composing an email more onerous and represent very poor usability for what seems like very little (if any) benefit.

It's just a muscle memory thing. Other users felt the same initially and have realized after a bit of re-training that the new design is actually way more efficient and transparent, especially when it comes to acting on multiple recipients simultaneously (copy/paste/delete/change type). The poor usability was in TB 68 where any actions on multiple recipients were extremely onerous, as you always had to do them one by one.
It's not only more efficient, it's also safer, as recipient items will guard against accidental changes to a recipient's address.

Please provide an option to restore the previous/classic compose layout.

Given the substantial UX benefits, we have no intentions of reverting this design decision, sorry! (wontfix)
But we're still working on improvements! :-)

Btw, restoring an option for a single-column layout which looks similar to the traditional design is bug 1635207.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
See Also: → 1635207, 1616514

This bug is not a duplicate. It may be a WONTFIX as :thomas8 suggests, but that's not up to me to decide.

My 2 cents on the matter: At the moment, the balance of benefits-to-detriments still weighs in favor of the previous design. The pills mechanism rough around the edges, with a lot of annoying, unexpected or undesirable behavior, and with some of the issues probably not even formally reported here on BMO. Still, at this point it is perhaps unreasonable to expect to just make the old design available again, as much as it pains me to admit.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

@ Thomas D. (:thomas8)

Thank you for the helpful and considered reply.

The workaround of defining a default CC address is a bit clunky and inelegant so although it may help someone, I probably won't use it.

I'm still not sure how changing the recipient type is easier in this new version.

Quite often I will "BCC" someone and then, on second thought, decide I'd actually prefer them to be a "CC" instead.

In the old design, while focused on the CC list, you would:

  1. Hit Shift+Tab (highlighting the "To/From/BCC" switcher thing to the left of the recipient list)
  2. Hit the down arrow to change the recipients from "CC" to "BCC"

To do the same thing in the new version, you have to:

  1. Hit Ctrl+A to select all CC recipients
  2. Hit Ctrl+X
  3. Hit Shift+Tab four times to highlight the "BCC" button
  4. Hit Return
  5. Hit Ctrl+V

I understand you could also use the context menu key at step 3 (then hit "B") but I think it's fair to say it's more cumbersome to reach and fewer people use it than regular function keys.

What would be so bad about having some options like the following?

• ☑ Always display the CC and BCC rows
• ☑ Use classic "To/From/BCC" switcher

That wouldn't require reverting the new design, only augmenting it, and wouldn't require getting rid of the pill style recipients.

Sorry, I just saw your related bug https://bugzilla.mozilla.org/show_bug.cgi?id=1616514 which I assume would care of my first option suggestion:
• ☑ Always display the CC and BCC rows

I would really like my section option suggestion to be considered, however:
• ☑ Use classic "To/From/BCC" switcher

Should I create a new enhancement bug for this specifically?

Also finally I meant to say I often change "CC" to "BCC" and not the other way around which is why my instructions were written that way.

re : Quite often I will "BCC" someone and then, on second thought, decide I'd actually prefer them to be a "CC" instead.
There is no need to copy and paste.

Right click on email address pill and select the option you desire. This is two clicks and therefore exactly the same as the old version where you would select the 'Bcc' to see drop down and select 'Cc'. So that 'classic' type of option is still available, you just right click on the email address instead of the 'Bcc'. This is a memory skill requirement.

If using keyboard, select the pill, press the right click key (on my keyboard it is on the bottom right next to the Ctrl key) then either press B key or use the arrow keys to select and press 'Enter'.

(In reply to diamondavocado22 from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0".

Furthermore, you can no longer change (for example) the "CC" list to "BCC" as you could previously; you have to create a whole new BCC line and cut/paste the recipient list.

You can:

  • right click Recipient Pill (or a selection of multiple recipients) and choose Move To CC (or BCC as required)
    or
  • drag and drop

The fact that you can do on multiple recipients at once is quite effective.

(In reply to Eyal Rozenberg from comment #2)

This bug is not a duplicate. It may be a WONTFIX as :thomas8 suggests, but that's not up to me to decide.
My 2 cents on the matter: At the moment, the balance of benefits-to-detriments still weighs in favor of the previous design.

I disagree with you on the matter, the new implementation (Pill principle) is much more efficient and user friendly than previous implementation, especially once you pass the very small learning curve when switching over. My understanding is that the team will continue to improve it over time, unfortunately not all we would like nor as fast...

The pills mechanism rough around the edges, with a lot of annoying, unexpected or undesirable behavior, and with some of the issues probably not even formally reported here on BMO.

All reproducible issues shall be registered individually in BMO, so they can be discussed and fixed where possible. A lot have already been reported and fixed so far. If there aren't reported/registered there is no chance for annoyances they cause to disappear ;-)

The recent implementation of drag and drop help quite much, and more improvements are coming... it is a step by step process...

The old design is unlikely to come back for sure... especially in regards of improvements brought by the new one.

Give it a chance (long term)...

I disagree with you on the matter

Well, it's at least in part a matter of personal preference, I suppose.

the new implementation (Pill principle) is much more efficient

I'm not quite sure what you mean. What efficiency measure are you using to make that claim? Also, lack-of-annoyance and efficiency are related, but not the same thing.

and user friendly than previous implementation, especially once you pass the very small learning curve when switching over.

But that's a bit like saying that you need to learn to like it... anyway, some of the problematic behavior is also by design. For example, I can't take a line of CC addresses and make the BCC using a pull-down menu.

Again, I'm not saying that I expect the old behavior to be restored. But I am saying I don't believe pills should have been enabled by default in v78.

(In reply to Anje from comment #5)

Right click on email address pill and select the option you desire. This is two clicks and therefore exactly the same as the old version where you would select the 'Bcc' to see drop down and select 'Cc'.

I navigate almost exclusively with the keyboard. I believe this is massively more efficient than reaching for the mouse, especially in an environment such as an email client where you are typing most of the time.

I totally understand that many people don't do this, but when Thunderbird is your main or only email driver in an enterprise setting (as it is for me) then efficiency becomes highly imporant. After all, isn't that why keyboard shortcuts exist?

If using keyboard, select the pill, press the right click key (on my keyboard it is on the bottom right next to the Ctrl key) then either press B key or use the arrow keys to select and press 'Enter'.

I did already touch on this in my comment above:

I understand you could also use the context menu key at step 3 (then hit "B") but I think it's fair to say it's more cumbersome to reach and fewer people use it than regular function keys.

Regarding the "pills" situation, @Richard, @Eyal: my own opinion is that I don't mind the pills at all.
However I think it's off-topic for this post.

My argument (and this topic) really has nothing to do with the pills themselves. Rather it's simply that using "CC" and "BCC" - and especially switching between them - has become a lot more cumbersome. I write emails all day every day using CC and BCC and it's definitely affected efficiency.

What do you think would be the best way to focus discussion on the "To/CC/BCC" switcher? Should I raise a separate enhancement request or is this thread still a place for discussion on that?

I see no reason why the pills can't co-exist with the classic To/CC/BCC switcher.

+1 for this to get fixed. I also work in an enterprise environment and make extensive use of the CC and BCC fields while driving my use primarily via the keyboard and have lost efficiency by having to continually stop, grab the mouse, navigate over, and open the fields that I need nearly every single time I am going to compose an emal

I think that it is reasonable to at least provide an option to make the fields configurable to always appear (even if it is not the default method.) For me, it also functions as a sanity check to always check those fields (especially when I want them to be empty) as a check that a message is not going to the wrong people on the CC and BCC lines.

Let's be clear - this bug is specifically about creating an option to restore the old Compose window layout.
That is not going to happen.

Everything else is not relevant in this bug, although it does clarify why the enhancement request was made in the first place.

re : using "CC" and "BCC" - and especially switching between them - has become a lot more cumbersome.

There is no issue in navigation as already explained. It is not more cumbersome or more clicks, in fact it is the reverse.
The problem is just a question of memory learning. It's like learning to drive on the left and then needing to drive on the right. It seems weird at first until you practise for a while. So it appears cumbersome because you need to learn the new process, that does not mean it is cumbersome.

re:I think that it is reasonable to at least provide an option to make the fields configurable to always appear
Agree.
That would be a completely separate bug report and one has already been created. See bug 1616514.
Options to auto have eg: Cc displayed, there is work in the pipeline and that topic is being discussed in that bug report.
However, currently use a workaround by setting the Account Settings > Copies & Folders to Cc your email address. Not ideal, but it works.

As time goes by there is likely to be many improvements.
But there is not going to be an option to restore the old compose window layout.

(In reply to Michael Shulman from comment #10)

+1 for this to get fixed. I also work in an enterprise environment and make extensive use of the CC and BCC fields while driving my use primarily via the keyboard and have lost efficiency by having to continually stop, grab the mouse, navigate over, and open the fields that I need nearly every single time I am going to compose an emal

I think that it is reasonable to at least provide an option to make the fields configurable to always appear (even if it is not the default method.) For me, it also functions as a sanity check to always check those fields (especially when I want them to be empty) as a check that a message is not going to the wrong people on the CC and BCC lines.

This particular issue is to be followed in already existing and opened bug 1616514, which for the specific enhancement you referring to, this bug is a duplicate for it.

(In reply to Eyal Rozenberg from comment #8)

I disagree with you on the matter

Well, it's at least in part a matter of personal preference, I suppose.

I think you are partially right on this one.

the new implementation (Pill principle) is much more efficient
I'm not quite sure what you mean. What efficiency measure are you using to make that claim? Also, lack-of-annoyance and efficiency are related, but not the same thing.

For my use case, and TB end-users I provide support for, it seems the new system is much more convivial. Also from experience I can tell the the old recipient compose design was putting off a lot of new user to Thunderbird especially those accustomed to the way things works in Outlook, Gmail and alternative email clients... which behave much more like the new design.

and user friendly than previous implementation, especially once you pass the very small learning curve when switching over.
But that's a bit like saying that you need to learn to like it... anyway, some of the problematic behaviour is also by design. For example, I can't take a line of CC addresses and make the BCC using a pull-down menu.

This is false, you can select multiple recipients pills and drag/drop them in BCC or right click Move to BCC... so what is the problem with doing it this way (apart fro the shortcut issues)?

Again, I'm not saying that I expect the old behavior to be restored. But I am saying I don't believe pills should have been enabled by default in v78.

I can understand that the Pill system is not to the taste of everyone... but most email client out there function this way so why not Thunderbird to ease transition for end-users and new comers?

Also as Thomas D. has indicated, improvements are underway, more can be suggested.

At the mean time, if you see room for improvement file enhancement request on BMO and provide concrete proposal that may be discussed and implemented or not.

re : I can't take a line of CC addresses and make the BCC using a pull-down menu.

Starting at either end of list of 'pills', press and hold down 'Shift' and use arrow keys to move through the 'pills' which get highlighted, press right click key (or use 'Shift + F10') and then press 'B'.

A nice improvement would be: if there are 'pills' and you right click in the eg: TO field, but not on a specific pill, you should be able to select 'Select All' to highlight and get focus. But currently the 'Select All' option is greyed out.
I'll have to see if someone has mentioned this in a bug and if not then raise the issue.

I've reaised this as a bug for enhancement to faciliate quicker mass selection. bug 1686949

@RichardLeger:

For my use case, and TB end-users I provide support for, it seems the new system is much more convivial.

That's a fair point, but - that's one group of users; and likely, users with less experience who needed your support.

Also from experience I can tell the the old recipient compose design was putting off a lot of new user to Thunderbird especially those accustomed to the way things works in Outlook, Gmail and alternative email clients... which behave much more like the new design.

So, this is a "vicious cycle": Outlook and GMail install certain habits, and then there's pressure to apply/enforce them in applications which don't follow those habits.

I can understand that the Pill system is not to the taste of everyone... but most email client out there function this way so why not Thunderbird to ease transition for end-users and new comers?

  1. Because it wasn't ready yet.
  2. Because existing users should not be disadvantaged for an ease-the-transition feature.
  3. Because the closer TB becomes to, say, MS Outlook or GMail, the less a transition is significant.
  4. Because attracting new users should be a secondary objective to developing/maintaining a quality application.

Actually, (4.) is even more significant. The UI/UX design seems to be consciously being shifted towards when newbie users with no experience would expect from a web page or mobile phone application. And not just as optional "kiddie wheels", but an inescapable default.

For example, I can't take a line of CC addresses and make the BCC using a pull-down menu.
This is false, you can select multiple recipients pills and drag/drop them in BCC or right click Move to BCC... so what is the problem with doing it this way (apart fro the shortcut issues)?

  1. That's not what I want to do. If the way to do things wasn't an issue, then a design change wouldn't make sense in the first place
  2. More actions are necessary for the same effect.
  3. This won't work if I haven't already clicked on enabling the CC or BCC rows, so yet another action necessary for the same effect.
  4. Mouse selection of pills still doesn't work just right, especially in multi-line settings with long lines, and/or when combining keyboard and mouse interaction. It's unpredictable to the extent that I often just avoid it completely, use a text editor, then paste the addresses for pillification.
  5. It prevents the extension of TB's functionality to set addresses or header lines to other headers, including custom headers. The previous UI lent itself towards such an extension - as well as, possibly, the editing of other generated header lines, but unfortunately that never materialized. It certainly won't materialize on top of pills and with the CC and BCC buttons.

@Anje:

Starting at either end of list of 'pills', press and hold down 'Shift' and use arrow keys to move through the 'pills' which get highlighted, press right click key (or use 'Shift + F10') and then press 'B'.

But that's not what I wanted to do, plus it means I have to press something many times, and remember one or two shortcuts which I hadn't needed to remember.

re : But I am saying I don't believe pills should have been enabled by default in v78.

That is the design for 78 and the way forward, so there is no point in debating whether you or I would have liked an option to keep the old method. It's not going to happen, so no point is wasting time over it.

I'm certain there are insufficient means to maintain both.
I'm absolutely certain this 'pill' design was around for several betas and would have been discussed on the merits of this design for resolving various issues. I'm sure there are going to be more improvements and enhancements as people come forward with suggestions for consideration and developers work on the ideas.

Personally, I liked the old design, but then I also have the choice of using version 68* .

I would rather have had the option to keep the look of the old Folder Pane as from my point of view that is now about as bad as it could get. Fortunately, thunderbird does allow userChrome.css and so I've fixed that problem.

For those who say it's just as easy, or easier, to change recipient types in the new design, here's a direct comparison:

Example: changing a list of recipients from BCC to CC while writing an email

Thunderbird 68:

  1. Shift+Tab (focuses Subject line)
  2. Shift+Tab (focuses BCC recipient list)
  3. Shift+Tab (focuses To/From/BCC switcher)
  4. Up arrow (changes BCC to CC)
    Total: 4 keystrokes, no function keys or context menus

Thunderbird 78:

  1. Shift+Tab (focuses Subject line)
  2. Shift+Tab (focuses BCC recipient list)
  3. Ctrl+A (selects all recipients)
  4. Shift+F10 (opens context menu)
  5. C (highlights "Copy")
  6. C (highlights "Move to CC")
  7. Return (moves recipients to CC)
    Total: 7 keystrokes, function keys and context menu navigation needed

I've created a separate enhancement request for discussion of the To/From/BCC switcher, independent of discussion of the pills.

See bug 1687117.

Thomas,

As this specific bug relate to the return of old compose interface which won't happen, it could be set as WONTFIX.

Other issues reported and discussed here can be followed in the separate dedicated bugs where relevant:
Bug 1667692
Bug 1616514
Bug 1687117
Bug 1686949
Bug 1635207

Cheers,
Richard

Flags: needinfo?(bugzilla2007)

Appreciation, Philosophy & Net Results

First of all, thank you very much everyone for their contributions.
We are all working towards the same goal: To make Thunderbird better.
I'm appreciative of your feedback and I believe listening to users is very important, as well as vice versa, for users to listen to the core team and give us and changes in the application we love an honest chance.

Imo, it's important to acknowledge that:

  • Change is inevitable for software to evolve and survive.
  • Change may come with some pain of transition, but after that, things will be better than before!
  • No single person will have the full "true" picture or the only one way forward, so cooperation and sharing insights/experiences/proposals is generally helpful and wanted. Both users and developers can overlook important aspects!
  • Successful projects need to strike a balance between input and output, listening and leading...

I think we've shared a lot here and this is what I'm taking home:

  • There's a lot of myths and misunderstandings about the old and the new design. "Good old times" aren't as good as they seem, and the benefits of the "new" are quite radically underestimated.
  • We must continue striving for improvements of the new design wrt ux-efficiency and keyboard access. I've always been at the forefront of that, but it's not a one-man show, and opinions tend to vary even between the experts, and it's much more complex than meets the eye when it comes to things keyboard for an international software with localizations.

Thanks much to Richard Leger and Anje for helping to sort things out here, rectify some of the myths and highlight where we are and what's still on (further improvements) and what's not on (reverting to the old design). Richard's comment 18 is pivotal.

Bug management and triage

Then in terms of bug management and leadership, there's that time when triage needs to call the shots.
I'm the last person to shoot down legitimate requests, but when there's ample evidence that there's nothing left to do after careful consideration, and related ongoing improvements have been filed and pointed out, there's no use wasting everyone's time with endless discussion.

I'll do one last round through comment 0 before I take this to conclusion; there's not too much new in the other comments and/or they have already been addressed.

(In reply to diamondavocado22 from comment #0)

Thunderbird 78 introduced a "redesigned compose window".
For me this is not an improvement and makes the usability of the window much worse. For example, adding a recipient via "CC" now requires you to press shift+tab five times to select "CC" and four times to select "BCC".

This will be addressed in Bug 1667692, reducing that action to a single keyboard shortcut.
Also note that you'll do that action maximally once for each composition, as opposed to TB 68 where depending on workflow, you may need to re-select the correct type many times when adding recipients of different types later.

Some easily overlooked shortcomings of the addressing area in TB 68

Furthermore, you can no longer change (for example) the "CC" list to "BCC" [in TB 78] as you could previously [in TB 68]; you have to create a whole new BCC line and cut/paste the recipient list.

There's a number of errors in this statement, especially the wrong insinuation that it was just a snap in TB 68 to change an entire CC list, which was actually the biggest ux-efficiency bottleneck as the number of steps required would multiply with the number of recipients you'd want to change, as Richard Leger was explaining somewhere with a detailed click/keypress count. Copy/cut/paste of an entire list of existing recipients within your composition was not even possible in TB 68 unless doing them one by one. Also, it was only kind of easy if you wanted to change the last recipient via keyboard. Given that recipients of different types could be mixed in all sorts of ways (with no way to prevent sich mixups when you wanted to add e.g. another To-recipient after already having your Cc/Bcc's set, try it!), there was very little transparency/overview about the different groups/types of recipients, who's in and who's out. You could even think that you've Bcc'ed someone, but a bit further down the list where you didn't check, maybe the same person would be CC'ed. That can still happen, but now you just have to check To and CC fields as opposed to checking every single recipient. Having to "create a whole new BCC line" is a surprising thing to say against TB 78, because in TB 68 you'd have to create new BCC lines for each and every recipient, and that would only work well when your last recipient happens to have the right flavor, apart from the inevitable mixups mentioned. This statement also ignores that TB 78 provides ways to change as many selected recipients as you like in one go to a flavor of your choice via context menu. For changing single recipient, same number of keypresses/clicks as before; for multiple: save clicks/keypresses multiplied by number of recipients changed.

Some more planned improvements

That said, we are still working on improving things and ux-efficiency here:

Bug 1616514 seeks to provide a way of starting compositions with CC/BCC fields automatically open. Not everybody wants that, and again, opinions on the degree of control which we should give to users vary (myself usually in favor of more control; others worried about the alleged "cost" of more fine-grained implementations).

Bug 1687432 seeks to provide a simple keyboard shortcut dedicated to moving selected recipients to another field easily, between To/Cc/Bcc. If it was my decision, I'd just have long keypress on T/B/C (non-localized, international shortcut) on selected recipients to move them into the respective fields.

These changes make composing an email more onerous and represent very poor usability for what seems like very little (if any) benefit.

We're still working on the "rough corners" and when these works are finished, the ux-efficiency will be pretty amazing!

Benefits of the new design

Already now, the benefits of the new design are massive in many ways.

  • click and keypress counts reduced by magnitudes for any action on multiple recipients
  • maximum transparency about the groups of recipients per type (To/CC/Bcc)
  • show more recipients at a glance via horizontal arrangement (yeah, ymmv) without the need to extend the header area.
  • ux-error-prevention by protecting each recipient as a unit/item against accidental changes
  • many simple ways of moving recipients around and changing their type, including drag and drop
  • powerful shortcuts, e.g. Ctrl+A to select all recipients of same type, Ctrl+A (2x) to select all recipients of all types (try that in TB 68 for 50 recipients!!!)
  • smart keyboard behaviour: Many long-press keyboard actions come with "breaks" for your own good: Let's say you're deleting pills in the BCC field with Backspace (which works faster than ever before with auto-select, one keypress to delete each recipient), and you just hold down Backspace. It'll first stop when BCC is empty. Let go of Backspace, and deliberately press it once again: It'll conveniently delete the empty BCC row, without eating into CC (as it would in TB 68). Let go and press again, now you can continue deleting stuff on CC. It'll never delete more than you can reasonably expect, no matter how long you press that key. That's what I call perfect keyboard efficiency.

One thing which users might miss is the orderly way in which recipients were lined up in a single column, which is easier for mass mails to see who's in and who's not. We have Bug 1635207 for exploring a display option to that effect.

Evaluating the key request of this bug

Please provide an option to restore the previous/classic compose layout.

As others have said, we cannot and we will not do that for a number of reasons. We're not going to revert all the benefits, nor the code (you have no idea how much work this involves!), and the maintenance burden for keeping both options would be way too massive without any tangible benefit. Just keeping the type selector on the left of recipients is logically impossible in the new design, that only works for single recipients when they all have their own type tag as in TB 68: You cannot re-label the entire CC-container as BCC because then you'd no longer have a CC-container. The logic is different now: You have one stable slot for each recipient type (like a letterbox with regular and priority mail slots), and you insert your recipients into the right slot, so that unlimited recipients of the same type are automatically and conveniently grouped together.

Bug Resolution:

WONTFIX (with shares of INVALID and DUPLICATE) per current summary - we cannot and will not restore the old design of TB 68.
We're working to improve the current implementation in dedicated bugs.

Status: REOPENED → RESOLVED
Closed: 4 years ago → 4 years ago
Flags: needinfo?(bugzilla2007)
Resolution: --- → WONTFIX
See Also: → 1667692, 1687117, 1686949
You need to log in before you can comment on or make changes to this bug.