The current Composer Window UI is poor, especially on Linux, but OS X and Windows as well. This is a meta bug to track the progress of the three implementations. Currently, we only have mockups for OS X, here: https://pancake.io/42b819/TBComposerMergeNew5.html https://pancake.io/42b819/TBComposerMergeNew4.html https://pancake.io/42b819/TBComposerInsetMerge.html I will create Linux ones next. Goal: To create a lighter, easier to use, more ascetically pleasant UI for the Compose window.

Not creating other mockups (probably obvious by now). The styles are close enough on each platform that I'd rather just finish the actual thing and screenshot it later.

Related to bug #668998 (duplicate of this) If You really consider less lines in addressing wigdet, You may try to make it similar to my Stationery add-on (or its spinoff "Address Widget Lines" add-on) - I made it user-configurable, so users can set initial number of lines. And more importantly, user can resize it to just one lime, maximizing space for email body. I personally on home machine use 1.5 lines (yes, one and half), and on work machine 2.5 lines. Extra half of line let me see there is something more, and if I'm interested I always can resize or scroll. But what I'm wanting the most, is ability to enter more than one address in line - this way it will really reduce space and make it more ergonomic. I mean one line for "To" addresses, then next line for "CC" or "BCC" addresses.

(In reply to Arivald from comment #3) > Related to bug #668998 (duplicate of this) > > If You really consider less lines in addressing wigdet, You may try to make > it similar to my Stationery add-on (or its spinoff "Address Widget Lines" > add-on) - I made it user-configurable, so users can set initial number of > lines. > And more importantly, user can resize it to just one lime, maximizing space > for email body. > > I personally on home machine use 1.5 lines (yes, one and half), and on work > machine 2.5 lines. Extra half of line let me see there is something more, > and if I'm interested I always can resize or scroll. > > But what I'm wanting the most, is ability to enter more than one address in > line - this way it will really reduce space and make it more ergonomic. > I mean one line for "To" addresses, then next line for "CC" or "BCC" > addresses. This is already possible with the compose UI. Users can easily alter the amount of rows, including the ability for one row. It can also be expanded to more than 3.

Ok, You right, now resizing is possible. I didn't noticed it earlier, because I always have Stationery enabled. But it was really annoying back then to always have at least 4 lines. Still, other issues apply (configure initial number of lines and more than one address in line).

(In reply to Josiah Bruner [:JosiahOne] from comment #4) > (In reply to Arivald from comment #3) > > Related to bug #668998 (duplicate of this) > > > > If You really consider less lines in addressing wigdet, You may try to make > > it similar to my Stationery add-on (or its spinoff "Address Widget Lines" > > add-on) - I made it user-configurable, so users can set initial number of > > lines. Informed by Arivald's addon (thanks for that!), my patch in Bug 425451 (released TB24) introduced a hidden pref mail.compose.addresswidget.numRowsShownDefault=3 Unfortunately Blake wasn't willing at the time to expose this pref in the Options UI, see Bug 425451 comment 22. > > And more importantly, user can resize it to just one lime, maximizing space > > for email body. Fixed in Bug 425451. > > But what I'm wanting the most, is ability to enter more than one address in > > line - this way it will really reduce space and make it more ergonomic. While you *can* actually enter multiple comma-separated addresses into a single address line, they will currently be restructured (when leaving the field) as single lines with one address per row. More below... > > I mean one line for "To" addresses, then next line for "CC" or "BCC" > > addresses. > This is already possible with the compose UI. Users can easily alter the > amount of rows, including the ability for one row. It can also be expanded > to more than 3. I think what Arivald really wants for address widget is to do as all other mailers do, just permanently list address of each type (To/CC/BCC etc.) in one row per type (which will really reduce space and make this more ergonomic and easier to mass-change types, copy, paste, delete etc.). That's Bug 440377 (currently 7 duplicates and 14 votes).

So it has been discussed in other bugs that the design on Linux and Windows may need some changing, as text fields take on the tendency of appearing "disabled" because of darker gray backgrounds. We don't have this issue on OS X, since we have a pretty much white background anyway. (See attached screenshot - The To: button doesn't currently look like that on Trunk, but it will within a few weeks) There are two ideas proposed for Linux and Windows: - Add a white background to all text fields (without borders). * Pros - Text fields will be identifiable as such * Cons - Having white strips may look a little odd. - Make the entire header background on Windows and Linux white, making it appear a little more like the OS X one. * Pros - Would automatically "lighten" the design. - Would make text fields identifiable as such. * Cons - Platform themes may cause issues if we use a white background (especially on Linux) I'll try to get mockups later today or tomorrow.

So here's what the compose window would look like if we used a white background on Aero. Looks pretty good actually. Definitely helps with the fields, and looks quite nice, since the white goes with the body color.

Here's what it looks like on Classic. Unfortunately not quite as nice looking, but not look totally hideous either. It does go with the body color, making it look like one element, which is nice.

(I don't have an XP machine, so I can't test on that, but Aero and Classic should give someone a pretty decent idea of the concept)

So here's what it looks like if we make each field have a white background even with no border... Not good. Definitely won't work. I think we should try the white background on the entire header, but people should feel free to keep leaving suggestions.

Linux is going to be the hard one to pull off though with a white background. On dark themes it may cause issues. I'll have mockups later...

(In reply to Josiah Bruner [:JosiahOne] from comment #8) > Created attachment 8373021 [details] > > So here's what the compose window would look like if we used a white > background on Aero. Looks pretty good actually. Definitely helps with the > fields, and looks quite nice, since the white goes with the body color. I consider having UI the same color as entry fields the main problem here. BTW: That's how Windows 3.0 was. If the non-entry UI elements were e.g. slightly "less white" (i.e. light gray), then there would be a better "structure" to the overall appearance (see e.g. this bugzilla page). Possibly Related: I don't know if this is part of the changes Josiah made, but it seems the ability to vertically resize the To/Subject section was removed. This is a major loss for users who have more than 3-5 recipients. They need a good way of seeing a larger part of the list of recipients.

(In reply to Peter Lairo from comment #13) > Possibly Related: I don't know if this is part of the changes Josiah made, > but it seems the ability to vertically resize the To/Subject section was > removed. This is a major loss for users who have more than 3-5 recipients. > They need a good way of seeing a larger part of the list of recipients. This is still there. But the separator was moved below the format toolbar.

This uses a very light gray background on Aero instead of white, though the difference it subtle. However, with the gray + the separator, I believe things are divided quite well.

(In reply to Josiah Bruner [:JosiahOne] from comment #14) > the separator was moved below the format toolbar. Discoverability problem!? Slightly thicker separator needed!? Subtle :hover effect on separator?

> Created attachment 8373026 [details] > Light gray background - Aero Now were back to non-white entry fields!? Not good. And the gray clashes with the blueish Toolbar and Menu. Or maybe it's better like this? And hopefully, the "From" dropdown selector has a :hover effect (that's not white).

(In reply to Peter Lairo from comment #16) > (In reply to Josiah Bruner [:JosiahOne] from comment #14) > > the separator was moved below the format toolbar. > > Discoverability problem!? Slightly thicker separator needed!? Subtle :hover > effect on separator? Umm... The cursor changes to a resize cursor if you hover over it? Why would adding a hover effect help. (In reply to Peter Lairo from comment #17) > > Created attachment 8373026 [details] > > Light gray background - Aero > > Now were back to non-white entry fields!? Not good. What! It was your own idea. > > And the gray clashes with the blueish Toolbar and Menu. Or maybe it's better > like this? Plenty of the application uses white. Toolbars, fields, panes, etc. I don't see your point at all. > > And hopefully, the "From" dropdown selector has a :hover effect (that's not > white). It does.

(In reply to Josiah Bruner [:JosiahOne] from comment #18) > (In reply to Peter Lairo from comment #16) > > (In reply to Josiah Bruner [:JosiahOne] from comment #14) > > > the separator was moved below the format toolbar. > > > > Discoverability problem!? Slightly thicker separator needed!? Subtle :hover > > effect on separator? > > Umm... The cursor changes to a resize cursor if you hover over it? Why would > adding a hover effect help. A cursor is a relatively tiny element on the screen and is often white on-white. A hover effect that affects the whole line would be noticeably much more noticeable. > > > Light gray background - Aero > > > > Now were back to non-white entry fields!? Not good. > > What! It was your own idea. No, my suggestion is to make the *entry* fields white and the *surrounding* UI non-white. > > And the gray clashes with the blueish Toolbar and Menu. Or maybe it's better > > like this? > > Plenty of the application uses white. Toolbars, fields, panes, etc. I don't > see your point at all. We're (hopefully) not using white for the non-entry fields UI, and a non-white color *can* clash with a *different* non-white color. (Please read more carefully: I never even mentioned "white")

As I wrote in bug 960672 adding a semi transparent background-image to #composeContentBox would help lighten up the header and could also help on dark themes. The value of the transparency can still be determined. #composeContentBox { background-image: linear-gradient(rgba(255, 255, 255, 0.5), rgba(255, 255, 255, 0.5)); }

At least on Aero 0.5 opacity works quite well. Could you try XP Richard?

first thing that strikes me, is shouldn't formatting toolbar (which isn't an input area) have same differentiating color/gradient as composition toolbar (which isn't an input area)? same goes for status bar. (afaict) As for other issues, as long as the design allows for UX-discoverablity (which I'm not sure is there yet in the mock ups so far) I trust UX folk to move us to a better design. Also bear in mind, not all of the larger design world that drives some of these things keeps the 60+ year old crowd in mind - we get to hear about it in support forums.

Comment on attachment 8373023 [details] White background fields - Aero Josiah, thanks for providing the mockups, I appreciate that (I think it's also required for such a prominent change in one of the main areas of functionality). This mockup is not yet what I had in mind, but now I understand what you meant with bizarre, and this looks a bit weird indeed. Starting out from this mockup, could you please do the following: - remove *all* borders (including the grey underline you added to input fields) - rejoin all recipient input fields (with thin lines exactly as in current version of TB) - make the sender field background white, too After that, it should look a lot smoother and simpler while offering much better ux-discoverability for the various input blocks (sender - recipients - subject).

(In reply to Wayne Mery (:wsmwk) from comment #22) > first thing that strikes me, is shouldn't formatting toolbar (which isn't an > input area) have same differentiating color/gradient as composition toolbar > (which isn't an input area)? It might be acceptable for the formatting toolbar to come with a lighter shade of the default toolbar background color as long as it's different from text input area coloring. But it's very strange to see a toolbar with a white background color just like the editor input in the mockups. Next thing you'll get users wondering if the toolbar - no longer well recognizable as such - will be sent as part of their message (and we couldn't even blame them because that's what an all-white background UI suggests). Josiah, I think we need to avoid taking our level of UI experience for granted for the entire user base. Of course you and I are able to find the input field regardless of background color - although even I wouldn't want to search for the input when there's better ways of indicating input-ability. But for users like my Mum, stressed secretaries, beginners, or just less explorative types of users, such ux-discovery problems can be a much bigger issues. The point being, there's neither need nor much benefit of potentially creating such problems, just for the sake of satisfying the personal state-of-the-art aesthetic preferences of new theme peers (and I mean that in a factua/observing way, not to blame you personally). As I said before, all-white background for the whole header including toolbar probably creates more problems than it solves. We could try for the entire header, but not sure how that would look with just a grey toolbar in between (let's see the screenshot...). But I still think we'll be much better off with a compromise of old and new design that's more similar to the existing design with respect to input fields ux-discoverability, as outlined in my previous comment: Proposal of Comment 23 still has a lot of Josiah's improvements (less borders, edges, shifted splitter etc.), while preserving a clear and more easily ux-discoverable functional structure of the header.

Comment on attachment 8373012 [details] Current design on OS X. (Ideal look) Something I explicitly don't like about this is the complete lack of separation between subject and recipients area, which makes the subject *a lot* harder to discover as soon as the recipient area is filled up to the subject row. Try it, and compare current and new design: Which is easier for identifying the subject without actually closely parsing the header labels? Iow, subject loses a lot of salience in the new design, which I think is unwanted for efficient UX.

Sorry, for also chime in. I've read that there are some complains about the new design. I can not speak for Windows or Linux, but I'm using a build with the new design for around two month now and in the meantime I don't miss the old UI. And I also have given this build to my dad one month ago, no complains so far, he still can write emails (and he is a 60+ normal Mac user). So, it really can not be that hard to find the Subject field. ;-)

Josiah, could you just tweak the current state so that each recipient row that has the address type dropdown (To, CC, etc.) prepended has the white background permanently expanded, regardless if they are empty or filled in? Rows, that don't have the widget would still expand only on hover as today. Subject should be expanded white too (no hover effect). Other than that it should be fine.The HTML tolbar should stay grey as it is.

No. :) Here's the deal now. I thought about this, discussed, and re-examined the compose UI and decided that nothing is wrong. Users will easily be able to tell what each element is and how to use it, and the fact that the first To: field is automatically focused is a fine enough indication to the user on each field's purpose. I also talked to a principal engineer who works at another company (he does both software engineering and HMI design), showed him the design, and he said the new design actually is clearer and also does not believe people will be unable to use the change. He also told me he is usually skeptical to design changes, but approved this one. I talked to Paenglab again, and we both agreed that nothing was wrong. Basically I'm taking a stand that since our UX team has approved the change, re-examined it, mockuped new designs, and evaluated others, and no problems were encountered, I am going to keep thing as-is*. I appreciate everyone's feedback, but I have full confidence in the people I have talked with (both in person and digitally) and conclude that no immediate/drastic changes are necessary. *The exception here is the separator to expand the top header. That I do think may need to more closely resemble a separator.

(In reply to Josiah Bruner [:JosiahOne] from comment #28) > I [...] decided that nothing is wrong. I'm not looking forward to even more e-mails with blank Subject lines. How very disappointing. BTW: Do Paenglab and the principal engineer who works at another company use Windows?

Yes, almost exclusively.

(In reply to Peter Lairo from comment #29) > (In reply to Josiah Bruner [:JosiahOne] from comment #28) > > I [...] decided that nothing is wrong. > > I'm not looking forward to even more e-mails with blank Subject lines. How > very disappointing. That's a groundless complaint. Thunderbird gives "Your message doesn't have a subject." and, if user cancels the send request, then focuses the Subject field when the user attempts to send with no subject

Good point, but we shouldn't be relying pop-up notifications to compensate for poor UI design.

For Windows, version with the light gray background looks acceptable (quite nice, actually), except that the HTML formating toolbar should look like a toolbar. But I have one big question: why You try to make Windows / Linux versions looks like the MacOS version? This is not improvement, in my opinion. Application should look & feel as close as possible to hosting OS. Fancy GUI should be provided by themes, not by application itself, for those who want it. And if You really have too much time, do features that really will help users. In case of addressing, it would be allowing more than one email address in one line, like most other MUA. Today screens are wide, while the TB addressing use the width, not the height of screen for multiple addresses.