Open Bug 1042780 Opened 10 years ago Updated 2 years ago

Clean up styling for the new compose header UI styles (recipient input area)

Categories

(Thunderbird :: Theme, defect)

Product:
Thunderbird
Component:
Theme
Version:
31 Branch
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mike.mayr, Unassigned)

References

Details

(Whiteboard: [ux-feature-wanted-38])

Attachments

(11 files, 3 obsolete files)

TB31_css.png
(deleted), image/png
Details
TB31_css_box-shadow_none.png
(deleted), image/png
Details
TB31, more-complete compose-UI reversion
(deleted), image/png
Details
TB_31_css_darker-line.png
(deleted), image/png
Details
TB31-compose-windows-mockup-improvement-proposal.png
(deleted), image/png
Details
OS X 10.10 Compose Proposal
(deleted), image/png
Details
WIP
(deleted), patch
Details | Diff | Splinter Review
WIP screenshot.
(deleted), image/png
Details
Use -moz-mac-vibrancy-light screenshot
(deleted), image/png
Details
8515396 Mockup Revisited
(deleted), image/png
Details
8524740 Mockup variation (with margins)
(deleted), image/png
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140715215148 Steps to reproduce: Installed verion 31; running Ubuntu 12.4 Actual results: When composing mail, the fields to, subject, reply-to, ect. are grey like non clickable or editable parts of the window. Expected results: They should be in a lighter color to be recognizable as text fields.
Yes, I can confirm this. The boxes don't look totally out of place now. Thunderbird 31 screenshot: https://i.imgur.com/6t1VD4F.png Thunderbird 24.6.0 screenshot: https://i.imgur.com/Pdj9vrN.png
This was an intentional change made across platforms that makes text fields appear as single lines when text needs to be entered instead of the bulkier text fields. However, it seems the general consensus is that the gray (which originally wasn't so dark, but was changed to follow the Distro's styling) gives the appearance of disabled fields on many linux distributions (especially Ubuntu). I think we could probably clean up the linux styling. I haven't heard of any Windows or OS X usability reports. I'll take a look.
Status: UNCONFIRMED → NEW
Component: Message Compose Window → Theme
Ever confirmed: true
Hardware: x86 → All
Summary: The text fields are no longer visible as text fields → Clean up Linux styling for the new compose UI styles.
Blocks: 906264
I'm worried that our need to try to use the theme's color for the background is one of the issues here. We wanted the new fields to show up and be visible on dark, light, grey, and colored themes, but this makes the styling a little bulky. Richard, if I implement something that checks the background color (I think we're suing -moz-dialog-color), for brightness and can detect whether it's more light or more dark, would you be okay if we have two styles (A dark and light one) only, therefore allowing us to be more specific?
Flags: needinfo?(richard.marti)
Ubuntu 14.04 LTS user here, running the default Ambiance GTK Theme: I am having usability issues. First, the grey text fields look non-editable, or alternatively, look like they have already been "finalised" and that I am "ready to send". To me, both alternatives are confusing and break the flow of composing and sending an e-mail. When opening a new compose window, the first "to" field is highlighted in white and thus is not grey. But e.g. when I type the message first, I have already "forgotten" to add a recipient. Second, the grey text fields do not only look non-editable, but there is also no distinct separation between "from" and "to" and again between "to" and "subject". This makes it even harder to recognise that a recipient is missing. In addition, this makes it harder to locate and compose the subject line, esp. when several recipients have already been added. I have been led here by an Ubuntu bug report on Launchpad, https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1347305 The fact alone that users are judging this to be a bug rather then a GUI cleanup should raise attention. These issues get worse with even just slightly "darker" themes like e.g. the popular Numix GTK theme. Thank you for taking this into consideration.
While I completely understand the intention of this change and agree mostly, I have some concerns with this implementation: - No distinction between sender, recipients and subject. - Depending of the theme the horizontal lines look ugly / too thick. - Widget of the drop-down menu doesn't respect the system widget toolkit theme. - Input fields appear to be disabled (grayed out). - Hovering with the mouse looks disturbing, contrast between gray/white too high. I think it would look great with some improvements. Either try to make it compatible with all system themes or use only custom widgets (and respect only background/foreground color).
(In reply to Josiah Bruner [:JosiahOne] from comment #4) > Richard, if I implement something that checks the background color (I think > we're suing -moz-dialog-color), for brightness and can detect whether it's > more light or more dark, would you be okay if we have two styles (A dark and > light one) only, therefore allowing us to be more specific? I'm okay with a brightness check and special rules for darker and lighter backgrounds. if you haven't started on detection code you could look at bug 940393 and bug 988191 where the window brightness is checked. I used (or better copied) this code in bug 1003295 for TB.
Flags: needinfo?(richard.marti)
A basic workaround until hopefully this gets cleared up : http://forums.mozillazine.org/viewtopic.php?f=29&t=2798693
This is a problem in Windows 7, too. The From, To, and CC fields and even the drop-down boxes are now all the same blue color as the background, making them no longer look like editable text fields.
I'm using xubuntu and I too thought (and still think) it should be a bug. What didn't work about the old way? Another case of significant UI changes that have no benefit and just cause confusion and frustration for long-time users, IMO anyway.
Some more feedback from the unsuspecting user's perspective: To me, it seems that the new, greyed-out UI design is encouraging a kind of "linear" approach to composing an e-mail: First, add recipient (when field is highlighted in white), then add subject line (before you forget it, otherwise Thunderbird will give you a friendly reminder), then write message text. This kind of "guided linear thinking" simply does not fit my thinking. I have caught myself hesitating to change the subject line when I thought of a better one while writing the message text, again because the subject line looked un-editable. Really, I am trying to make use of this new UI, but I keep failing. Or is it rather the UI that is failing me? All has been working just fine before. Will there at least be an option or an add-on to "get back", or rather to be able to "think forward"?
Hello, I am on Ubuntu and i use Thunderbird for a long time. When I first opened the new compose window I thought it is a bug and restarted my laptop. I have not seen such an atypical interface before, and I would like to suggest to release it not as default, but as an option. Greetings Ralph
Hello, I am on Ubuntu and I use Thunderbird for a long time. When I first opened the new compose window I thought it is a bug and restarted my laptop. I have not seen such an atypical interface before, and I would like to suggest to release it not as default, but as an option. Greetings Ralph
Oh, JosiahOne broke the theming again! I had a hunch it was you, due to the grained background inserted along with the problematic flat-design text fields. A general remark about this Josiah: on libre *nix systems which use GTK+ theme (such as GNU/linux, freeBSD and so on), you should *really* stick to using the widgets of the GTK theme the user specified. Anything else only leads to (user-unfixable) breakage, see this screenshot for the compose window: https://bugzilla.mozilla.org/attachment.cgi?id=8466769 That looks just like locked text fields now, doesn't it? Cheers!
Flags: needinfo?(josiah)
Looks strange on Windows XP too. This particular change wasn't lucky at all across most platforms.
(In reply to calimeroteknik from comment #15) > Oh, JosiahOne broke the theming again! > I had a hunch it was you, due to the grained background inserted along with > the problematic flat-design text fields. > > A general remark about this Josiah: on libre *nix systems which use GTK+ > theme (such as GNU/linux, freeBSD and so on), you should *really* stick to > using the widgets of the GTK theme the user specified. > > Anything else only leads to (user-unfixable) breakage, see this screenshot > for the compose window: > https://bugzilla.mozilla.org/attachment.cgi?id=8466769 > > That looks just like locked text fields now, doesn't it? > > Cheers! I don't really think so, no. But Thanks for the feedback, and as I said earlier, I am investigating/thinking about improvements. I have a feeling most complaints here are more about its look and not really usability, but perhaps we could make things clearer without making it *so* minimal. (Just as a note, the passive aggressiveness is not helpful especially when you're targeting volunteer developers such as myself. I did cause the grain, but also fixed it, as well as over 100 other bugs for 31.) Blake, sorry to do this to you, but what thoughts do you have on the compose ui for all platforms, Linux in particular. Any improvement ideas?
Flags: needinfo?(josiah) → needinfo?(bwinton)
(In reply to Josiah Bruner [:JosiahOne] from comment #2) > This was an intentional change made across platforms that makes text fields > appear as single lines when text needs to be entered instead of the bulkier > text fields. For what its worth, I think this is the root of the problem. What's wrong with a "bulkier" text field? What benefit does changing to single lines bring? The text box motive makes sense and has worked for years and years and years. I've used them on Windows, Linux, and OSX. And I never, ever, even once, considered that the compose UI at all felt bulky. Why was it changed? If there was no valid reason, other than "they seemed bulky to me" please, for the love of Thunderbird, change them back. I just find it ironic that that are bugs in Thunderbird that have been around for years that no one seems to care about but then UI elements get changed that didn't need to be changed in the first place. It's NOT better and it is NOT an improvement. There was nothing "wrong" in the first place. :(
The point was to make things look nicer and to pave the way to the future changes to the compose ui. Things will eventually be entered in one field, with multiple addresses per line, improved contact support, drag and drop address movement and other cool things. However, In an effort to accomplish this, we want to get away from classical and dated ui. That's the reason, hope it clears things up a little.
(In reply to Josiah Bruner [:JosiahOne] from comment #17) > I have a feeling most complaints here are more about its look and not really usability Just to avoid any misunderstanding: All that I have been writing here concerns usability, not the "look" (cf. start of comment # 5 "(...) I am having usability issues."). Also the other comments here to me seem to relate to usability. The term "look" alone does not need to imply that just the "look" is being referred to: if an editable text field does not "look" like an editable text field, but on the contrary non-editable, that is clearly a usability issue, isn't it?
Except you did figure out you could edit them didn't you? So perhaps there is a learning curve that could be reduced some, but I don't think people will suddenly be unable to send messages. Several other co-developers stated that, although they were at first thrown by the change, they later came to get used to it, and in most cases, preferred the new look. No other developers who work on the product considered it a usability issue though. Anyway, before any other comments are made, let's wait for Blake to weigh in. He's the UX lead. Thanks to everyone for the feedback.
@JosiahOne sorry if I felt aggressive before, I really intended none of it… (In reply to Randy Syring from comment #18) > (In reply to Josiah Bruner [:JosiahOne] from comment #2) > > This was an intentional change made across platforms [...] > It's NOT better and it is NOT an improvement. There was nothing "wrong" in the first place. :( More importantly even, I believe that it is more important to stick to the look'n'feel of the OS's UI toolkit and theme. In a desktop system, it's really nice when you can get the theme used uniformly across applications. An application that decides to theme widgets differently from the others isn't quite good news to the user. If these changes improve MacOSX integration, they could maybe be kept for MacOSX specifically. But aren't there themes as well on OSX?
(In reply to Josiah Bruner [:JosiahOne] from comment #17) > Blake, sorry to do this to you, but what thoughts do you have on the compose > ui for all platforms, Linux in particular. Any improvement ideas? While I love the look of the text fields currently, perhaps we could scale it back a little, and always show the white boxes of the focused state… It's a little more busy, but not totally heinous. (In reply to calimeroteknik from comment #22) > More importantly even, I believe that it is more important to stick to the > look'n'feel of the OS's UI toolkit and theme. In a desktop system, it's > really nice when you can get the theme used uniformly across applications. You are certainly within your rights to believe that, but I'm afraid I disagree with you. There's a balance to be struck between looking like each OS, and looking like Thunderbird. You can see how Firefox is trying to balance their application at http://people.mozilla.org/~jgruen/chameleon/#nav7 and having Thunderbird strike a similar balance seems like the right choice to me. (As a side note, Josiah, you can see in that screenshot how the urlbar remains white even when unfocused. That's kind of what I'm thinking of for our compose fields. Of course we have more of them, so it won't be as clean, but I think I can live with that. Oh, you should also ping Paenglab on irc, and see if he has any thoughts, since he is the Theme owner and all. :)
Flags: needinfo?(bwinton)
Sounds good, thanks Blake!
(In reply to Josiah Bruner [:JosiahOne] from comment #21) > Except you did figure out you could edit them didn't you? So perhaps there > is a learning curve that could be reduced some, but I don't think people > will suddenly be unable to send messages. Several other co-developers stated > that, although they were at first thrown by the change, they later came to > get used to it, and in most cases, preferred the new look. I have given the new compose window UI a fair shot, and by now I have decided to "work around it". Yes, I could probably get used to the new UI and its deviating way of displaying editable text fields in contrast to all other applications and in contrast to all other windows of Thunderbird itself. But I just do not see the point (in a way, just like I would not see the point of getting used to enter "Open Sesame" in order to be able to edit a specific text field). I have contributed here because the defaults matter and because I care for Thunderbird. Thank you for listening.
Attached image TB31_css.png (deleted) —
Thanks to the Mozilla/Thunderbird community, by now there are serveral starting points for basic workarounds: In continuation of comment #8 referring to http://forums.mozillazine.org/viewtopic.php?f=29&t=2798693 I would like to point to http://forums.mozillazine.org/viewtopic.php?f=39&t=2858087 I am attaching a screenshot of what this latest userChrome.css approach looks like on my machine (Ubuntu 14.04 LTS, default Ambiance GTK theme). By posting this, I do not intend to diminish the work that the Thunderbird developers are continuously putting in, highest respect from my side. This is only intended as an additional help for those who might be presently unhappy.
(In reply to Guido Zoellner from comment #26) Some of that CSS does kind of improve the situation, but I still get that weird flat design, with next to no contrast, and therefore really hard to use. (In reply to Blake Winton (:bwinton) from comment #23) > (In reply to calimeroteknik from comment #22) > > In a desktop system, it's really nice when you can get the theme used uniformly across applications. > > You are certainly within your rights to believe that, but I'm afraid I > disagree with you. There's a balance to be struck between looking like each > OS, and looking like Thunderbird. I'm actually very sad it came so far as to having to say this: I have no idea what “looking like Thunderbird” should even mean. An application has a purpose and an usage; giving it an “identity” by doing unusual and disorientating things with the design of functional parts of it is a slippery slope up from functionality down to nobody knows what. > You can see how Firefox is trying to balance their application at > http://people.mozilla.org/~jgruen/chameleon/#nav7 and having Thunderbird > strike a similar balance seems like the right choice to me. So far, firefox has always kept its UI in sync with the system theme colors, and anyway complies with the worldwide standards of text fields coloring; the matter at hand is that currently, that's not quite what thunderbird does. Firefox looks good, so I think that everybody would be satisfied with an alignment to that, indeed!
Hello, I would like to share my experience with the new compose window. Over the last few das I forgot to fill in the subject line a couple of times. That is something new to me and I therefore will try one of the workarounds. Ralph
The style looks a bit weird on Windows 8.1 too. As mentioned earlier, the fields do not look editable anymore nor prettier. http://i.imgur.com/pMpkBbN.png
(In reply to Reihar from comment #29) > The style looks a bit weird on Windows 8.1 too. As mentioned earlier, the > fields do not look editable anymore nor prettier. > > http://i.imgur.com/pMpkBbN.png Hi, I have tried the workaround by konrad79 pointed to in comment #26 http://forums.mozillazine.org/viewtopic.php?p=13699151#p13699151 You can see a screenshot of the result attached to this bug report. https://bug1042780.bugzilla.mozilla.org/attachment.cgi?id=8467753 This is my favourite and I hope it works for you as well.
:aceman's comments from bug 960672 (which apparently introduced this change) seem relevant, and match my own sentiments fairly well. I don't see any response to them there; were they discussed elsewhere, or just not taken into account? For myself, I find this change highly aggravating. I've finally managed to get all the parts of the TB2 UI which I found essential restored, and when they finally make it into a release version, that version has *another* new undesirable-to-me UI change with no apparent way to effectively revert it... I really hope some way (whether userChrome.css or add-on or something else) can be found to 100% restore the old UI in this regard, at least visually, because I really don't want to stay on Thunderbird 2 for another year or more; I wanted to move off of it more than a year ago, in point of fact. The screenshots I've seen of the userChrome changes proposed so far don't seem entirely satisfactory; I haven't had the time to dig through the patch that made the change and see what might be required to just revert it wholesale, but I'm not entirely confident of that being a productive approach, since I don't know of any way in CSS to *remove* a style rather than overriding it with a different one. (Doing it in JS, via an extension, doesn't seem likely to be much easier.) Also, just to note, in regard to comment 19: * Thanks for explaining the rationale behind the change. Shouldn't that have been included in the original bug? * I disagree that this makes things look nicer. IMO this looks considerably worse. * Although most of the features you described as upcoming do indeed sound cool, I don't want "one field, with multiple addresses per line". I've seen that in Outlook, and while it has an advantage in information density, it's also harder to read and harder to work with IMO than the discrete separation of one address per line.
(In reply to Andrew Buehler from comment #31) > > Also, just to note, in regard to comment 19: > > * I disagree that this makes things look nicer. IMO this looks considerably > worse. +1,000,000 > > * Although most of the features you described as upcoming do indeed sound > cool, I don't want "one field, with multiple addresses per line". I've seen > that in Outlook, and while it has an advantage in information density, it's > also harder to read and harder to work with IMO than the discrete separation > of one address per line. +1,000,000 Don't need drag and drop either. Just more complicated code to go wrong. The changes might look 'cool' but I don't want cool. I want to work, and with a UI that doesn't confuse me. If I really wanted an Outlook lookalike, I'd go install Outlook. Screens these days are big enough that designers really shouldn't be having to worry about every single pixel. And for those with poorer eye sight, cramming stuff together must me murder. (In reply to Josiah Bruner [:JosiahOne] from comment #19) >Except you did figure out you could edit them didn't you? So perhaps there is a learning curve that >could be reduced some, but I don't think people will suddenly be unable to send messages. Yes, I figured it out but I find the comment a little insulting. We aren't all dumb thanks, but you severely interrupted my work flow and caused me to make mistakes. That is seriously uncool, annoying and unnecessary with good design. (In reply to Josiah Bruner [:JosiahOne] from comment #19) > I have a feeling most complaints here are more about its look and not really usability, Maybe it's you who hasn't figured it out. The usability is awful, and that is due to the changes you have made. The look is pants too..... See Comment 28 for instance "Over the last few days I forgot to fill in the subject line a couple of times" I did exactly the same as well. That's when the trouble started.... (In reply to Josiah Bruner [:JosiahOne] from comment #19) > we want to get away from classical and dated ui It works. YOU might want to get away from it, but what about the people who actually use it ? Personally it is fine the way it is. I don't want dumbed down pretty boxes - if I do I'll go find some theme thing, not that I have ever bothered til I looked for a fix for this mess. Look at what is happening - Palemoon rising from Firefox, Fossamail, Mint on the back of Ubuntu, and dare I say it Windows 8 ? People don't always want fancy new UIs they don't understand or can't work with or that upsets their workflow. Change needs to be slow, well thought out and intuitive, not a rush over the precipice just trying to keep up with 'the Joneses', and one that doesn't leave an enormous mountain of bugs lying collecting dust for years, or create new ones like the hanging forever Address book search we now have.
I'm getting tired of reading Mr. Crisp's rants, so I'm going to unsubscribe myself from this bug. Later, Blake.
Before even reading any intervening comments, I'd like to apologize for the tone of my previous comment. It's just that it's depressing to go from the positive thought of "today I'm going to finally migrate to a new Thunderbird, with all the problems I've had with it fixed!" to "oh, there's now even more problems to fix, and there's no hope of getting them fixed upstream because they're intentional changes.". Add in the difficulty (impossibility?) of reverting / ignoring CSS changes, as opposed to explicitly overriding them with hardcoded values, and my frustration boiled over. Since my previous comment, I've discovered that part of the reason I didn't think any of the existing userChrome.css fixes were enough to revert the change is that I was trying to revert the compose UI to the form it had in TB2, whereas the form the existing fixes were trying to restore is apparently one which was introduced sometime between TB5 and TB8. I think I can probably adjust to that form of the UI if necessary, I just wasn't expecting it to have changed.
It looks like the currently-latest version of the reverting CSS in the MozillaZine thread currently linked to from comment 8 does mostly work. The only issues I see left (on Linux) are that the border between the toolbar with the Send button is now a shadow rather than a simple line, and that there is no longer a darker line between the Subject box and the actual compose-message-body pane (on, or just below, what I think is the resize-dragger widget). I've been poking around trying to fix the latter, as the more egregiously noticeable of the two, but I haven't been able to find what part of the commit which introduced this change actually causes that part. It seems obvious that it would be the #compose-toolbar-sizer style rule, but no matter what I add to userChrome.css under that name, it doesn't seem to take effect in Thunderbird itself... I'm guessing that either I'm modifying the wrong object, or my modifications are being overridden by some other part of the CSS added in this commit, but I don't know what. (Now that I look again, perhaps I might need #composeContentBox instead - but I don't know what I'd need to change on that if so, since the previous style rules didn't touch that at all.) Any ideas what I should be trying to pursue for this?
Hello, I agree with John Crisp's comment #32 and I can't see it as offensive. The reaction of Blake`s comment #33 has been demotivating for me and I have asked myself how we as users can participate in issues like this? Greeetings Ralph
(In reply to Andrew Buehler from comment #35) > Any ideas what I should be trying to pursue for this? Andrew, for your specific question possibly it would be more promising to head over to MozillaZine and ask there, maybe also adding screenshots to visualise. At the same time, I can see your frustration. This is one more indicator of the pains that TB users are going through at the moment. I have to say that I am astonished that this UI change has been pushed to the users for them to cope with on their own (be it via userChrome.css, theme changes or reverting back to TB 24.x), even though the earlier Bugzilla threads show that this has been "flagged" for at least several months already. And I am hopeful that all the additional users' feedback right here will be of help for the developers to create a 1) functional and 2) aesthetic default compose window UI. As to the earlier Bugzilla threads that I was referring to: https://wiki.mozilla.org/Thunderbird:UX/Priorities/31 at the bottom lists three reports: https://bugzilla.mozilla.org/show_bug.cgi?id=906264 (Linux, depends on this Bugzilla report) https://bugzilla.mozilla.org/show_bug.cgi?id=867161 (OS X) https://bugzilla.mozilla.org/show_bug.cgi?id=960672 (Windows)
After a false start and apparent (but unreproducible) success involving #appcontent, it looks like the missing stanza from Bozz's CSS, to restore that darker line below the resize-dragger widget, is: #compose-toolbar-sizer { -moz-appearance: none !important; border-bottom: 1px solid ThreeDShadow; } This also eliminates the visible "this is draggable" image at the center of the resize widget; I can see how that could be desirable to have, but IMO having the across-the-board visible demarcation of the darker line is more important, since otherwise the UI looks too "flat". I thought I found a way to get the darker line while still retaining that visible dragger image, involving a 'border-top' on #appcontent, but I can't seem to get the effect back now.
And eliminating the "gradient / shadow" border between the Send-button toolbar and the From/To/etc. headers area appears to be a simple matter of: #composeContentBox { box-shadow: none !important; } Guido, I'm posting about this here because I think this is likely to be more discoverable for people who want to revert the change than a MozillaZine thread would be, particularly since there are already multiple such threads - and while some such threads are linked to from here, if someone's going to have passed through here in getting there anyway, why not have the information here? Also, it seems appropriate to have the fixes for the issue available on the bug reporting the issue, whether or not that bug is officially considered something which should be fixed.
Attached image TB31_css_box-shadow_none.png (deleted) —
(In reply to Andrew Buehler from comment #39) > And eliminating the "gradient / shadow" border between the Send-button > toolbar and the From/To/etc. headers area appears to be a simple matter of: > > #composeContentBox { > box-shadow: none !important; > } Andrew, OK, picking up the ball you brought into play, I am attaching a new screenshot with this addition of yours. I added this at the very start of userChrome.css and I can confirm that this takes away the "drop shadow" that you mentioned. This becomes even more apparent when comparing this screenshot to my previous one (see attachments at the top of this Bugzilla report). As stated in comment #26, this userChrome.css version is based on the version of konrad79 http://forums.mozillazine.org/viewtopic.php?p=13699151#p13699151 which in turn is based on the second version of Bozz http://forums.mozillazine.org/viewtopic.php?p=13624709#p13624709 I am not entirely sure how exactly you modified Bozz's version with your other changes. Would it be possible for you to add a screenshot?
Attached image TB31, incomplete compose-UI reversion (obsolete) (deleted) —
Here's a screenshot with Bozz's changes, as I see them...
...and here's one which also has my local CSS tweaks (snippets already posted) on top of it.
Attached image TB_31_css_darker-line.png (deleted) —
(In reply to Andrew Buehler from comment #38) > After a false start and apparent (but unreproducible) success involving > #appcontent, it looks like the missing stanza from Bozz's CSS, to restore > that darker line below the resize-dragger widget, is: > > #compose-toolbar-sizer { > -moz-appearance: none !important; > border-bottom: 1px solid ThreeDShadow; > } Andrew, thanks for your screenshots. Now that I see what you mean, in order to test I put your addition at the end of my userChrome.css and I can confirm your description of the effects. Screenshot attached.
(In reply to Andrew Buehler from comment #39) > Guido, I'm posting about this here because I think this is likely to be more > discoverable for people who want to revert the change than a MozillaZine > thread would be Agreed Andrew, esp. with your two new inputs to Bozz's foundation. Personally, aesthetically, so far I prefer konrad79's spin together with your "no drop shadow" addition and without your "darker line" addition. I just checked Bozz's .css take again, and together with that both of your additions aesthetically make sense to me as well. This being said, all of these alternatives are working for me without any difficulties, no usability issues with any of these whatsoever. And to me, that is the point of all of these efforts to "restore" the compose window UI, form should follow function and all... So thank you for your input Andrew! As to the "drop shadow": as a bonus, this might also clear up for some Ubuntu users that that is not coming from Ubuntu, cf. e.g. this post in the corresponding bug report on launchpad from "back in the day": https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1347305/comments/3
As a user who just upgraded to TBird 31 on Windows 8.1, just wanted to chime in and confirm that as a user this change is a horrible break to expected and desired behaviour. It took me over half an hour to finally work out that this was an intended change not an extension messing up the UI or a bug. If a field is available and should be considered for entry, it should look like an empty text box, not an empty area of the window that looks like Windows forgot to draw the UI properly or at best an uneditable area. I also think it's now completely non-obvious how to add multiple recipient addresses to an email. It's stupid UI changes like this, made just because what's worked for years is considered "old and stale - must change" instead of "stable and working fine - leave this alone!" that make me hate Mozilla products and waste my time find the method to revert the changes (which exists without fail because I'm never the only one) with every update. It's the reason why I've switched to Chrome for web browsing. It's the reason I no longer use Thunderbird at home. It'll likely soon be the reason I find an alternative for work too.
Summary: Clean up Linux styling for the new compose UI styles. → Clean up styling for the new compose UI styles.
OS: Linux → All
Idea for improvement...
As indicated in Bug 1084539 after upgrade to TB 31.2 (Win 7 64bits) the lack of contrast between the background color of windows and background color of fields (currently same color) in compose window is the main issue. It make the fields much more difficult to read and edit and therefore are not end-user friendly at all, even after a while of usage. It remain not-intuitive in term of usability. The address fields background color shall be of different color that the window background color (white would remain most appropriate in a light theme). For constancy, I would expect those field background color to be the same as the body/content field background color (eg: white in a light theme). The simple fact that developer themselves seems to have difficulties to adjust to the new layout shall have ring a bell that it wasn't an adequate change to make for all. Why to change what's works? Better concentrate on what doesn't... As a stone to the edifice, you would find in attachment 8507216 [details] a rough mockup proposal that may inspire a better solution as a possible compromise... Basically From and Subject fields appears more separated (thicker lines - same color as window background color) while To,Cc,Bcc scroll down list stand in the middle with addresses lightly separated by thin lines of background windows color... Rounded corner may be optional... just look more smooth... to my opinion... The field shadow may be removed to provide a less bulky aspect and to bring it closer to a "flat design" which seems fashion at the moment but which usually create loss of contrast making things more difficult to distinguish... new version of Android and iOS are good examples... If you look at Bugzilla, Thunderbird and Firefox layout, most of the editable field by end-users have a white background that clearly contrast with the background color of the window that contain them (eg: url address bar, search field, etc...) this is the most optimized contrast in term of usability. Most of forms on the web (and in software) do use such layout [though some might use a background color for field and white for the background color of windows/table that contain them]. This is a very standard design guideline that works and which is well followed in software development and on the web. Thunderbird should keep it. As you are at redesigning the layout of compose windows I would also suggest the following additional changes as possible room for improvements: - Replace the current To/Bcc/Cc separate fields for each email address set by a comma (or semi-colon) list of addresses instead (as usually used in alternative email client software). With a trailing X button for each address to allow deletion/removal or a drop down menu to: delete, copy email address, edit contact, add contact, etc... - Increase the newly set auto-completion search result display default limit (in To, Cc, Bcc fields) from 5 contacts to the previous value available in TB 24.x (I think it was about twice the amount: 10 contacts) and eventually allow end-users to change this limit within the options. Those may be created as separate bug if needed. Hope you would take all those input positively.
First of all, I want to thank you for having an issue with the design *and taking action* on it, it's very much appreciated, and a rare quality. I actually am a fan of your idea, and think that if done properly, could balance the "cleaner design" without having such a radical change. (In reply to Richard Leger from comment #48) > If you look at Bugzilla, Thunderbird and Firefox layout, most of the > editable field by end-users have a white background that clearly contrast > with the background color of the window that contain them (eg: url address > bar, search field, etc...) this is the most optimized contrast in term of > usability. Most of forms on the web (and in software) do use such layout > [though some might use a background color for field and white for the > background color of windows/table that contain them]. This is a very > standard design guideline that works and which is well followed in software > development and on the web. Thunderbird should keep it. > Valid. > As you are at redesigning the layout of compose windows I would also suggest > the following additional changes as possible room for improvements: > - Replace the current To/Bcc/Cc separate fields for each email address set > by a comma (or semi-colon) list of addresses instead (as usually used in > alternative email client software). With a trailing X button for each > address to allow deletion/removal or a drop down menu to: delete, copy email > address, edit contact, add contact, etc... That is being handled separately in bug 440377. > - Increase the newly set auto-completion search result display default limit > (in To, Cc, Bcc fields) from 5 contacts to the previous value available in > TB 24.x (I think it was about twice the amount: 10 contacts) and eventually > allow end-users to change this limit within the options. Noted, that would indeed be a separate bug though.
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #49) > First of all, I want to thank you for having an issue with the design *and > taking action* on it, it's very much appreciated, and a rare quality. I > actually am a fan of your idea, and think that if done properly, could > balance the "cleaner design" without having such a radical change. Thanks. > > As you are at redesigning the layout of compose windows I would also suggest > > the following additional changes as possible room for improvements: > > - Replace the current To/Bcc/Cc separate fields for each email address set > > by a comma (or semi-colon) list of addresses instead (as usually used in > > alternative email client software). With a trailing X button for each > > address to allow deletion/removal or a drop down menu to: delete, copy email > > address, edit contact, add contact, etc... > > That is being handled separately in bug 440377. Thanks for info. I have updated bug 440377 comment 39 with my input posted here for reference. > > - Increase the newly set auto-completion search result display default limit > > (in To, Cc, Bcc fields) from 5 contacts to the previous value available in > > TB 24.x (I think it was about twice the amount: 10 contacts) and eventually > > allow end-users to change this limit within the options. > > Noted, that would indeed be a separate bug though. Done. Bug 1084653 has been opened :) One more!!! Don't hate me... lol!
I am delighted by what I am reading here most recently, and I am a fan of Richard's mockup, too.
Attached image OS X 10.10 Compose Proposal (deleted) —
Alternatively, I would suggest following what OS X does now, and have full lines with the header background the same color as the input area.
Assignee: nobody → josiah
Status: NEW → ASSIGNED
Much prefer Josiah's proposal. Much cleaner but, at least for non-Apple OS's, it needs a collapsible formatting toolbar.
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #52) > Created attachment 8507360 [details] > OS X 10.10 Compose Proposal > Alternatively, I would suggest following what OS X does now, and have full > lines with the header background the same color as the input area. It does look nice, I like it as well, but a Windows style mockup would help to get a better idea/feeling of it in a Windows environment. What looks nice on OS X does not necessarily on Windows due to the different default styling... Also the mockup does not include text or addresses (which I suppose from the mockup, would be used as a list of contacts and no longer individual contact in separate fields) how does it look on OS X when data is filled in? Also to highlight separation between the header fields and the body content I would suggest - to create a better/stronger separation between subject field and body textfield a slightly thicker line (or a double line) maybe at the top of body textfield... or - to use the body format bar which seems to be currently missing on the mockup (where would you place it?) on the OS X screenshot and which currently separate subject field (and other headers) from body textfield in the Windows version of Thunderbird. It is quite handy to have it just at the top of the body textfield... so it may be better integrated with a more "flat design" style to make it more discrete, less bulky than current Windows style in place... A light background color could then be used to highlight active field being edited eventually... but not really required (not needed I believe) as there would be in any case a blinking cursor at the location of current editing area... which I suppose is what is used in Mac OS X version to highlight active field. Hope that help. Thanks for your effort and work on this issue.
Aesthetically, to my eyes both Richard's and Josiah's proposals look very clean. Functionally, what I like particularly about Richard's mockup is that there is a distinct separation between sender, recipients and subject line.
Whiteboard: [ux-feature-wanted-38]
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #2) > This was an intentional change made across platforms that makes text fields > appear as single lines when text needs to be entered instead of the bulkier > text fields. Imho how bulky text fields appear depends much on their borders and the overall design. Flat and borderless white against a normally lightgrey platform background isn't so bulky. Perhaps the pre-TB31 recipient area looked a bit nervous because there were so many borders all around. But I don't recall noticing any visual problems until the big redesign... It's also interesting to see the historical development of recipient area, perhaps someone could add screenshots of TB2, TB3.1, etc... TB2 is actually pretty close to the all-white background solution currently favored by Josiah. (Which is nice, but the problem starts when the formatting toolbar is added to that...) > However, it seems the general consensus is that the gray (which > originally wasn't so dark, but was changed to follow the Distro's styling) > gives the appearance of disabled fields on many linux distributions > (especially Ubuntu). Thunderbird as a desktop email application might be a more traditional/conservative thing in itself, where users (especially corporate) might care more about UX/functionality than innovative cutting edge design... But there's a more general question here how much we want to be consistent with OS platform design, vs. introducing an application-specific design... The answer is probably along the lines of what Blake said in comment 23, we need to strike a balance between being OS-conform and being ourselves as Thunderbird. Tricky... > I think we could probably clean up the linux styling. I haven't heard of any > Windows or OS X usability reports. Well, aceman and I have raised our concerns for Windows, and duplicate bug 1051638 (currently 5 votes) and bug 1061063 are both reported against Windows. Several comments on bug 1051638 are quite vocal against the current design. Even long-standing and loyal supporter like Anye Yelf who really isn't known for idiosyncratic or exaggerated criticism. Several users actually consider this a design bug and are quite surprised to hear it was intentional... Apart from the general issue, something which really disturbs me is that we're not even consistent *within* the new design. As discussed on the Toronto summit, we really shouldn't irritate users even more by having two competitive designs for the same type of control, namely Sender-dropdown vs. Recipient-type-dropdown. These are functionally exactly the same, so they should look and behave the same. I'm seeing this quite strongly on WinXP, where the dark-grey background of recipient type dropdown offsets a lot against recipient area background and I'm always wondering what's wrong with the recipient type that it still stands out from the all-flat header although it's not focused or disabled.
Hello, how much feedback is necessary to get this feature-bug fixed!? greetings
Most of the users of Thunderbird are normally in my expectation people who want an email system that just works. It does not need all the bells and whistles, skins and fashionable features, it just needs to work. Change for the sake of change is not a good option. If somebody wants to change something allow them to download and run as an ad in but please leave the basic configuration of Thunderbird email alone. It has been discussed and mentioned many times that we all consider the layout, the visual cleanness and the operation of the program to be perfect, please don't change this just for the sake of making changes. I have had to revert many computers back to previous versions like 24 and it worries me that I may be leaving my email system vulnerable by not having the latest versions with all of the security enhancements. One of the big problems I have is, now I have turned off automatic updating so I have no idea when will be the correct time to update again and I don't know when the problems we are mentioning will be fixed. I hope that I am not leaving myself open to email security issues. Just remember, because something has been the same for a long time does not mean it is broken! Please leave the layout and functionality the same and allow people the option to change the look and customise the program themselves without you forcing it on us
This problem extends even further indeed: Personally, I might be able to "work around" the (for me) currently unusable default compose window, but I have become hesitant to recommend Thunderbird to others.
Attached patch WIP (obsolete) (deleted) — — Splinter Review
Not even close to done, but I'm uploading my WIP for documentation. (I'll go ahead and upload the screenshot as well)
Attached image WIP screenshot. (obsolete) (deleted) —
Screenshot. Please, please, please don't comment on this with specific details you'd like addressed, or other multi-page comments. :) I'm still working on getting a basis, so limit comments to general ideas.
Attachment #8473763 - Attachment is obsolete: true
Attached patch WIP (deleted) — — Splinter Review
Whoops, I messed up the padding of the toolbar on accident. This patch corrects that and cleans up some other styling.
Attachment #8515389 - Attachment is obsolete: true
Attached image WIP screenshot. (deleted) —
Attachment #8515391 - Attachment is obsolete: true
Attached image Use -moz-mac-vibrancy-light screenshot (deleted) —
Also, here's an idea I had to add vibrancy to the OS X 10.10 version. I think it looks pretty nice, but I'm not convinced it's worth it considering the trouble it will be to obtain border colors for the fields (which in this screenshot are barely visible). Richard, what do you think? Go for it or don't bother?
Attachment #8515397 - Flags: feedback?(richard.marti)
Speaking as someone who found the TB31 compose-headers interface sufficiently horrible that he actively applied much user-chrome CSS to revert it to something very close to the TB24 one, while I'm not entirely happy with the look of these latest screenshots, I'm much more pleased with them than with either the as-shipped TB31 appearance or the other mockups / suggestions I remember having seen so far. Based on comment 52, I'm presuming that this would be intended as a cross-platform appearance (as much as possible given OS/toolkit capabilities), not something Mac-specific despite the current screenshots?
This looks already promising. I think -moz-mac-vibrancy-light is mostly used on sidebars, or not? It makes the header part again different from content, which isn't the goal of this bug. I think first we should do it without vibrancy. Here some feedback: - The header background color should be picked from the defined content background color. This can be set in Preferences/Display/Formatting/Colors.../Background (editor.background_color). Else when a user changes this color the header would differ in his background color. And unfortunately in HTML compose mode, msgcompose.background_color needs to be checked. But this could be a different kind because the user can change this color during editing, and should we then also change the header background color? - The aw-menulist is lacking a hint to be a menulist. A dropdown arrow on the left should be shown as a minimum. - The msgIdentity dropmarker is so far away on the right from the address. What about including the From: label into the menulist and move the dropmarker to the left directly above the aw-menulist dropmarker? The two last notes can be reverted with bug 440377. A tip: For selecting the text/border colors in the header you could also use the toolbar[brighttext] ... selector to switch between dark and light colors. Actually it's only used on Windows but it is working on all platforms.
Attachment #8515397 - Flags: feedback?(richard.marti)
Short comments: - the arrow on the right (see attachment); - the vibrancy looks weird, I was wondering if my screen had glitched. I would also be very thankful if you could make sure that your changes look OK on dark themes. Thunderbird always has! On the whole, it looks like you are trying to make the compose window look like an actual paper letter. Am I right?
The attachment didn't work, here it is: http://www.kirikoo.net/images/14Anonyme-20141101-133421.png
@Josiah First of all: Thank you, that's a huge improvement of the current situation and still different than the old one. In addition to the comments (top right arrow, missing arrows of the To: field): The left alignment of the From: field doesn't match the other ones. I want to try this version in Linux but don't want to compile Thunderbird myself. I'm afraid that there is no way to accomplish this e.g. with the userChrome.css, right?
(In reply to Andrew Buehler from comment #67) > Based on comment 52, I'm presuming that this would be intended as a > cross-platform appearance (as much as possible given OS/toolkit > capabilities), not something Mac-specific despite the current screenshots? Yes, it will be XP, though the current patch does not do that. (In reply to calimeroteknik from comment #69) > Short comments: > - the arrow on the right (see attachment); I agree, I think that will be removed completely. > - the vibrancy looks weird, I was wondering if my screen had glitched. Yeah, I don't think I'm going to use that. > > I would also be very thankful if you could make sure that your changes look > OK on dark themes. Thunderbird always has! I will. :) > > On the whole, it looks like you are trying to make the compose window look > like an actual paper letter. Am I right? That's the inspiration for the design, yes. (In reply to Sven Greiner from comment #71) > I want to try this version in Linux but don't want to compile Thunderbird > myself. I'm afraid that there is no way to accomplish this e.g. with the > userChrome.css, right? Yes, this is not possible in userChrome because I change quite a bit of the XUL layout as well. (Mostly properties, but still). The patch currently is only affecting OS X, but other platforms will be added in future versions. When I'm closer to finishing, I will put up Try Builds for people to try. :)
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #72) > (In reply to calimeroteknik from comment #69) > > Short comments: > > - the arrow on the right (see attachment); > > I agree, I think that will be removed completely. Ah, but then if it looks like the other editable fields, but is in fact a drop-down list, don't you think that's still problematic? I think it's not the arrow that's a problem, it should stay there, but the field could use some kind of background shape to indicate that the arrow is part of it. Since it's not an editable field, it doesn't make much sense for it to look like the text entry fields. Mockup: http://www.kirikoo.net/images/14Anonyme-20141101-144054.png (the color, the design etc might not be it, but it's for the overall concept)
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #72) > (In reply to Andrew Buehler from comment #67) > > - the vibrancy looks weird, I was wondering if my screen had glitched. > Yeah, I don't think I'm going to use that. I kinda liked the vibrancy, and am having happy thoughts imagining the content of the email scrolling behind it, but having said that I think I'm probably an odd-ball in this case, and I don't think that vibrancy should be the default. :)
Attached image 8515396 Mockup Revisited (deleted) —
Based on mockup proposed by Josiah (attachment 8507360 [details] and attachment 8515396 [details]), and few comments that follows, I would suggest the following modifications (see mockup attached): - keep white background by default - remove underline below field labels (From, To, Cc...), keep it under editable field areas only... make it less heavy ("prison like"). - remove colon from field labels and make their font color grey (like in attachment 8507360 [details]) instead of black currently. - align field labels to the right instead of the left currently. Same as current TB behavior. - in the from field, put the drop down selection list arrow on the left, in front for the text field content (as proposed in comment 68) - don't include the From label into the menu list (contrary to what is proposed in comment 68), keep it separate as a simple label as current TB behavior. - in the From field, keep background same color as other field (contrary to what is proposed in comment 73). When you click on the field to start to edit it, it would anyway open the selection box to choose value from so to my opinion there is no need to highlight it for further distinction... the arrow and the activation behavior shall be sufficient to indicate it is a selection list without surcharging the layout. Same as current TB behavior. - ideally, one of the value in the From field selection menu could be a <add new identity> link to allow creating an new identity directly from here... The field could be then updated automatically with new identity newly created. - move the format bar into the body content area at the top under the line separating from subject. May be more neat. This may require an additional (optional) line to separate with the body content. - use a more flat design for the format toolbar buttons with more greyish appearance to make more discreet/melted into the background. As an additional suggestion not in the attached mockup: - set a small page margin on left and right so the lines (and content) would not touch the window boarders, bringing the all content floating in the middle of the 'paper' page a bit like a letter :) Hope those few suggestions may help.
As a further proposal, here is a slight variation of my previous mockup (attachment 8524740 [details]) with following changes: - added more space between labels and value fields - made the subject field higher to create a better and more breathy separation with body content and its format toolbar - added margin-right in the header area so line stop before the border of the page/window. Margin width on the right equivalent to the width used by the labels area on the left. - added margin-right and left to the page so body content and format toolbar stop before the border of the page/window. Note: all the horizontal lines shall be of the same size (like between From and To)...
Blocks: 1108599
Adding relevant search words to summary - was too hard too find!
Summary: Clean up styling for the new compose UI styles. → Clean up styling for the new compose header UI styles (recipient input area)
Blocks: 1115034
Assignee: josiah → nobody
Status: ASSIGNED → NEW
I'd really just prefer that you revert back to the classic, time tested user interface. The white and grey examples are not nearly as easy to see. If it wasn't broken, why break it? This change has single handedly made thunderbird less pleasant for me to use. I held off upgrading my operating system for several years because I did not want to be simultaneously forced to upgrade thunderbird to include this bug. I eventually had to for other reasons, but I'm not happy with thunderbird.
The above mock-ups don't show what happens when there is a long list of recipients. The current style does not make obvious how many there are if they are more than three, but the proposed style does not seem to make things better (and perhaps it makes them worse by just showing 1 recipient).
(In reply to M Lopez-Ibanez from comment #82) > The above mock-ups don't show what happens when there is a long list of > recipients. The current style does not make obvious how many there are if > they are more than three, but the proposed style does not seem to make > things better (and perhaps it makes them worse by just showing 1 recipient). I just installed: https://addons.mozilla.org/fr/thunderbird/addon/mrc-compose/ and it solves this problem wonderfully.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: