Closed Bug 29105 Opened 25 years ago Closed 24 years ago

Chrome color choice problems, conflict with web pages [modern skin]

Categories

(SeaMonkey :: General, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: trudelle, Assigned: german)

References

()

Details

I gathered comments from several contributors, some of them key developers:

Color screen - light pale blue items on dark blue background  The colors are 
awful.  Dark blue and shades of blue are not very good choices. 

Lack of contrast in the UI. On the mac in particular many of the UI components 
such as scrollbars, radio buttons, etc. don't have enough contrast with the 
surrounding content. For example, I've found that adding a simple one pixel 
border around the scrollbars makes a large difference. See Apple Human Interface 
Guidelines. Controls blending into content is bad. This applies for the chrome 
too. Also with the scrollbars, the track color and the thumb color are too close 
together. Again, we need more contrast. MacOS and Windows have significantly 
different default gamma settings, and we need to account for this.

Note: This bug report may turn out to be merely a tracking bug for dependent 
bugs filed against specific issues.
Blocks: 28883
Bug 17639 covers having the one-pixel border around widgets -- i.e. taking the 
current moused-over appearance of widgets, and making them look like that all the 
time.
Depends on: 17639
"...Color screen - light pale blue items on dark blue background The colors are awful. Dark blue and shades of blue are not very good choices..." this would qualify as not-useful bugwriting. What can I read from this part of the bug other than your personal taste? Please be more specific and more fact-oriented in your feedback ie. why you think this is a bad choice. Inferring from your comment wrt to the controls/content on the Apple Human Interface Guidelines lets us conclude that links on web page are bad. Moreover web forms are bad. But wait we didn't have a web when those guidelines where conceived...hmmm :-)
Light blue on dark blue is a poor choice for a color scheme because:

* In Western culture, blue -- especially in mixtures of light and dark -- has
  connotations of coldness. This in turn produces a feeling of unfriendliness
  (that's why we refer to people's behavior as `cold', `icy', `frosty', etc). To
  be fair, `cool' also has positive connotations in the younger generation, but I
  don't think Netscape is aiming solely at the younger generation.

* In Japanese culture, blue has connotations of evil.

* Making chrome predominantly dark blue forces icons and text to be light on
  dark, rather than dark on light. This has been shown, in countless studies, to
  be bad for readability.

* It's inconsistent with OS color settings for the large majority of users (how
  many people do you know who have their computer set up to have dark blue chrome
  throughout the OS?). This subconsciously suggests to the user that the browser
  doesn't really `belong' on the computer, that it's an unfriendly visitor rather
  than a friend.

The lack of contrast in controls is bad because:

* Controls are meant to be used, as opposed to content which is meant to be read.
  There is zero benefit to be gained from blending the two together.

* It's inconsistent with every platform on which Mozilla is running. XPFE widgets
  were supposed to look like a harmonious average between widgets on the various
  platforms -- not like something at odds with every one of them.

`Inferring from your comment wrt to the controls/content on the Apple Human 
Interface Guidelines lets us conclude that links on web page are bad' is not a 
valid comment because:

* Links usually have high contrast with surrounding content (bright blue in the
  midst of black text, on a white or pastel-colored background).

* Links almost always have a one-pixel border drawn along one of their sides --
  i.e. an underline. Like the color, the underline also helps the link stand out
  from surrounding text.

`Moreover web forms are bad' misses the point because:

* Web usability in general is terrible -- every day people use the Web *in spite
  of* its unreliability and unfriendliness, not because of it. There's no reason
  why we should make this situation even worse.

* Web forms wouldn't be so bad if there was decent contrast in the form widgets
  in the first place -- which is what this bug is about. In versions 2.x through
  4.x, Mozilla has provided such high-contrast form widgets, and that is part of
  what has made the Web so successful.

`But wait we didn't have a web when those guidelines where conceived' is not a 
valid comment because:

* The MacOS 8.0 HIGs were published in 1997, well after the Web was in popular
  use, as an addendum to the original Macintosh HIGs. The MacOS 8.0 HIGs could
  have said `ok, we don't need contrast in widgets any more', but they didn't.
Err, it's been a while since I've read them, but the 1997 HIG update (if I 
recall) were written by a tech writer off the street (proverbially speaking), 
rather than Lori Kaplan. 

I'm also not aware of any high-caliber UI folks at Apple being involved in their 
writing. Thus, I wouldn't personally ascribe too much value to omissions within 
it.
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
Depends on: 30715
The moment you stay away from a conservative grey and provide a more customized 
experience you polarize opinions. Where a conservative "brown bag" approach" 
seems be safe (we have the 4.x skin for that), we will have this 'problem' with 
any design theme. But thats the point it is not designed to please everyone but 
to represent one design direction that a certain group of customer likes. For 
what its worth a large number of customers repsonded to us after beta 1 that they 
like the new appearance. I understand others don't - again for that reason we 
provide choice.
As far as usability is concerned we did identify a few issues based on contrast, 
font-size and visually seperating controls which will be addressed quickly.
So for me this bug a globally written as here is really invalid.
Depends on: 37529
Ok, just explain why `design[ing] to please everyone' is a bad idea for the
*default* skin, and I'll gladly verify this bug as invalid. I would have thought 
that `represent[ing] one design direction that a certain group of customer likes' 
would be an excellent idea for alternative skins bundled with Seamonkey, but for 
the default skin it would unnecessarily drive away potential users before they 
even discovered the other skins available.
"I gathered comments from several contributors, some of them key developers:"

But you were very selective in the comments you gathered. The comments you 
supplied do not consititute a valid argument that this is a bug, because, 
simply, you only presented the side of the story that you agreed with.

There is every indication that this is a Netscape specific bug, not a Mozilla 
bug, because Mozilla will not be using Netscape's "skin" indefinitely. And 
Netscape can do whatever it wants with its default appearance (whether you like 
it or not). I have not seen *anywhere* *any* indication that the default 
Netscape skin will become Mozilla's default skin as well. In the short term, 
Mozilla's use of Netscape's skin is simply for 1) convenience, 2) because 
Mozilla itself isn't completely "skinnable" yet, and 3) because no one has done 
up a replacement skin (because of point 2).

If this report isn't marked invalid, it should definitely become a "request for 
enhancement" because it is not a valid or legitimate Mozilla "bug".
I filed this bug in order to ensure that some strong feedback from key 
contributors got through to the designers, to stimulate further comment, and to 
provide a place to collect any follow-up issues.  I am personally rather 
neutral about the color choices,  but wanted to get these issues resolved.  
This certainly only applies to the intended Netscape appearance, so anyone not 
interested in that is free to confine their attention to the thousands of other 
bugs in Bugzilla.  I have no idea what your criteria is for a 'legitimate' bug, 
but I believe this one has been useful, and is serving its purpose.
Added M30 so we may get there after all high priority features. 
Target Milestone: --- → M30
Depends on: 41272
adding modern skin to summary to make clear this only applies to that skin. 
Modern will receive some updates starting after beta 2 to improve form and 
function.
Also other themes will likely be available by the time we ship. Futhermore what 
will be the right default theme for each Mozilla and Netscape6 will be decided at 
the right time with the right set of people respective for each group. 
accepting bug for now to cover changes to modern skin setting m to 20.
Status: NEW → ASSIGNED
Summary: Chrome color choice problems, conflict with web pages → Chrome color choice problems, conflict with web pages [modern skin]
Target Milestone: M30 → M20
Marking fixed as the new modern redesign has been completed and has a less
saturated more toned down color in the chrome as well as clear delineation
between content and chrome.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Classic is now the default skin, and Modern has also been toned down a lot -- 
verifying fixed.
Status: RESOLVED → VERIFIED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.