Gary Schnabl wrote:
Jean Hollis Weber wrote:
Blue should definitely NOT be used for x-ref text.
I personally do not like blue for user input (or another other purpose
where the colour is supposed to convey information; in headings colour
is eye candy). Colours often don't differentiate well when printed in
black-and-white, even if there are no on-screen issues for
colour-blind readers.
Deselecting colors (or most other things) via intelligent use of styles
for the relatively few hard copies of the docs could easily be handled
in the master documents used for the print docs.
It's yet another step in the process of preparing the docs for print.
So, that is mostly a
non-issue with regard to online viewing.
Furthermore, I doubt that many (any?) Webmasters would eliminate colors
in their Web pages because of some potential color-blindness of viewers.
Perhaps, the 1.3% of monochromats
<http://en.wikipedia.org/wiki/Colorblindness> (in the US) are getting
the short end of the stick in this regard, but that's life...
Actually, a growing number of web designers are concerned with making
their web pages meet accessibility standards, not only due to government
regulation, but also because accessible web pages tend to enhance
usability for all users. For color-blind users, this does *not* mean
eliminating all colors, but rather it means that *where color carries
meaning*:
* using color distinctions that color-blind users can distinguish (there
are web resources that provide such palettes)
* not using color as the *only* carrier of meaning
For the purposes of this project, that leaves the question, if color is
not the only carrier of meaning, is color needed at all?
IMO we should minimise typographical changes. Usually they just cause
"noise" or clutter in the docs, or draw undue emphasis to some items,
without adding any real value. They also increase the complexity of
things for authors/editors to remember to do, which is one reason why
there is so much inconsistency among the chapters of a single book,
and even more between books.
While I don't share Jean's personal distaste for blue, I do share her
concern with simplicity. This project has to balance usability for
readers with simplicity for volunteer authors and editors, in order to
foster participation. The more time authors and editors have to spend
applying special styles for special cases, the less time they spend
focused on the content, which is where the real value of docs is.
If we minimise the use of typographical changes, then we don't need to
inform the readers of what they mean. IMO if typography needs to be
explained, then we probably shouldn't be using it.
Vance Packard
<http://en.wikipedia.org/wiki/Vance_Packard#The_Hidden_Persuaders> would
probably not agree with this, and his influence in this field can be
seen anytime one enters a commercial retail establishment the past half
century. Subliminal tactics, including colors used, in everyday life
have been influencing persuasion (or assisting readers, for example) and
will continue to do so.
This seems tangential to me, but it seems like your point reinforces
Jean's. "Subliminal" tactics are "under" conscious awareness. Anything
that has to be explained is definitely within conscious awareness,
therefore not subliminal, therefore less psychologically effective.
It's a common practice in technical guides to include a brief section
within the front stuff regarding what the typographical conventions are,
along with an example or two of how each type would appear in the text.
This should impose zero problems to OOo docs, and many readers are
already accustomed to their use, especially in software guides that
contain a plethora of categories or other elements.
It's true that it's a common practice in professionally-produced
technical guides. However, my experience is that most readers skip over
such sections as useless front matter, going straight to the content. It
does not have zero cost, because it is another section that has to be
maintained.
> Not everything non-vanilla is "eye candy."
True, but it needs to earn its keep.
--
Janet Swisher, Sr. Technical Writer
Enthought, Inc., http://www.enthought.com
