David Abrahams wrote:
Rene Rivera <[EMAIL PROTECTED]> writes:
[1] I have some objections to the BoostBook design just about all
stemming from my perception that the current design impairs structural
understanding of the docs. Basically because it violates a number of
understood design principles. One of those is the use of multiple visual
style vectors
What's a "visual style vector?"
It's one particular aspect of style that can be changed independent of
others. That is height, slant angle, weight, outline/filled, and color.
For example you can manipulate the height and color with great freedom
and independently of each other in HTML.
to indicate heading levels. Others are perhaps personal
readability concerns. For example the overuse of background "color"
(meaning non-background color) in text elements which break up the
structural flow of the text. In particular "pre" and "quote" boxes with
the gray background. Such design elements are causing the escalation
What is "escalation?"
It's the traditional meaning :-) From a design perspective it's when the
use of one style element drives the increase of another element in
compensation so that it doesn't get perceptually "lost". That is so that
it doesn't loose the perceived importance it used to have or should
have. In this particular case I was referring to the large difference in
size (font height) between the headings and body text. The large size
is, in my opinion, an escalation to compensate for their reduced stature
because of the distracting background color elements in the textual
content. There is additional escalation on the slant of the headings to
then compensate between the now larger headings.
[3] This is probably for me, personally, the most contentious
question because of the effort as the author of the web site
design. Just like Joel feels alienated for having to hand over
design control, I would feel betrayed if parts of the web site
content, the docs, do not coexist with the overall design. I think
we either use two (or more) different documentation presentations
for online and offline, or we agree on one design that can live on
both contexts.
I don't see a contextual difference. It all ends up in a browser
window, doesn't it?
Yes, although the offline use is more likely to also get printed out.
They are likely to get used differently. There's been mention from some
that they mostly use the docs in a scanning mode, while others tend to
sit and read carefully. I think that the former is more likely a use of
the online docs, and the latter of the offline docs. But more explicitly
the offline docs won't have all the navigation and interactive (i.e. the
webnotes) hence they can be tailored without the worry that they will
clash with those elements to make for the easiest to read. While the
online docs might be tailored for scanning and searching.
Having said; _I believe we should have different design for online
vs. offline reading._ Because otherwise we would tie the web site
design down for longer than we might want. It would be considerable
harder to change our minds, and make improvements, to the web design
if each time we had to go back and redesign the offline BoostBook
design. This is a major goal of the new we structure, to separate it
from the Boost structure so that we are then free to tailor each to
the pertinent audience.
I'm rather confused about what you mean by online and offline.
Online: The docs you see as part of the Boost website. They will
eventually, and immediately in my test site, have interactive elements.
First one being the webnotes, another being ability to read past,
present, and future versions of the docs. By future I mean reading the
HEAD revision docs that meta-comm generates periodically. By present,
whatever the current release is. And past would be previous releases.
Offline: The docs that users download either as part of a single Boost
release, or one of the alternate released formats.
Better terms are welcome if those are confusing ;-)
Good questions.
Yep they are. Hopefully my answers are constructive. And drive others to
comment.
I'll probably be happy with anything you and Joel can agree on.
I think that exactly Joel's point :-) You'll be happy, but someone else
will be angry. And unlike libraries where the friction is minimized most
of the time because it's something that library author will deal with
individually. The design is something that affects everyone.
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Boost-docs mailing list
[email protected]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
