Closed
Bug 29105
Opened 26 years ago
Closed 25 years ago
Chrome color choice problems, conflict with web pages [modern skin]
Categories
(SeaMonkey :: General, defect, P3)
SeaMonkey
General
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.
Comment 1•26 years ago
|
||
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 :-)
Comment 3•26 years ago
|
||
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.
Comment 4•26 years ago
|
||
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.
Comment 5•25 years ago
|
||
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
Updated•25 years ago
|
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.
Comment 7•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
"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".
| Reporter | ||
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Added M30 so we may get there after all high priority features.
Target Milestone: --- → M30
| Assignee | ||
Comment 11•25 years ago
|
||
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
| Assignee | ||
Comment 12•25 years ago
|
||
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: 25 years ago
Resolution: --- → FIXED
Comment 13•25 years ago
|
||
Classic is now the default skin, and Modern has also been toned down a lot --
verifying fixed.
Status: RESOLVED → VERIFIED
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•