[Changing to more appropriate subject]
David Abrahams wrote:
Joel de Guzman <[EMAIL PROTECTED]> writes:
Rene Rivera wrote:
I think that's a bit too melodramatic ;-)
It is ;-) for a good reason: to show how passionate
I am on having a freedom of choice. It's really not
about which design is better, it's about freedom to choose
which one, one prefers and it's also about collaboration
and cooperation when unity is desired. When unity is
prefered, collaboration must ensue. There *was*
collaboration on the current boost book design, FWIW.
There is none in the proposed design. IMO, that's very wrong.
True, collaboration is difficult. There's always the risk
of the "design by committee" syndrome. However, I argue
that in some cases (e.g. if it involves works by
several people), we cannot have an easier shortcut.
I agree with you here.
For what it's worth I also agree to an extent, and I started replying to
this early this morning and got busy with other things :-\ So I'll just
continue here...
There are a variety of issues involved in this. From the POV of authors
having a single style for all gives the feeling of having your own work
being subverted or ignored. But from the POV of users having many styles
gives impression of inconsistent support and inferior functionality. I
hope we all understand that we all want to increase the confidence users
have. So we have a choice of prodding authors to improve the style of
their docs or we do it for them. Obviously some authors are more capable
in this respect than others, i.e. Joel. But others are either not
capable, or don't care enough to put the effort into the presentation of
their docs. So we are down to either totally imposing a design on
authors, or someplace part way there. Psychologically speaking I would
think authors would be happy to not have to think about visual design
and instead have their libraries stand out in the libraries code merits.
But I personally understand that isn't the case for all :-) (Meaning I
care about both and have a tendency to even make my code visually well
designed, I know I'm a freak) -- OK, long preamble :-)
With all due respect, I may try to reply to some more of your
statements, but IMO, they are off on a tangent.
Got it :-) ...My muddled response was because I did not understand what
your tangent is because of the inherent entanglement between the two
presentations of the docs.
I am/was
questioning 1) the very rationale for creating a new design
*for the docs* (not the site in whole) in the first place
Well there are really more questions, or parts to it. Whether to create
a new design for the BoostBook generated docs? [1] Whether to make all
documentation follow the BoostBook design? [2] Whether to have the docs
presented in a different style on the website? [3]
My feelings on those, note: not really answers...
[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 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 of
other design elements (this is another design anti-pattern). For example
the large headers. And other minor items, like the definition lists,
etc. _So yes I think we need a "new" BoostBook design._ One big caveat I
should mention is that there are other less functional issues, I also
have. Like Joel I think the design is somewhat drab and could use more
visually interesting design elements. I just didn't go that route
because of my desire to respect the previous "consensus". But the
feedback I got from doing the website design last year when I wanted to
use different colors, and interesting icons, etc. was one of "I just
want the text" or "don't put anything between me and the text". So it's
hard to do visually interesting designs with that kind of audience.
[2] _I do think we need to make all the documentation follow the
BoostBook design._ It's the least we can do for users to improve their
"Boost Experience". I also think authors would benefit from not having
to worry about this aspect of their library documentation. After all
it's hard enough for many to do good documentation in the first place if
they also have to worry about making it look presentable, and not just
making it readable.
[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. 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.
and 2) the process we must follow when we introduce design
changes.
Yea, hard question :-) I think we have to consider the web design and
BoostBook design differently. Sorry if I keep going on about both
designs, can't help it :-\
The perhaps easy one first, the web site. In the past it's only taken
the approval of the Boost moderators to get that used, more often just
Daves' OK. That seems to follow from the concept of most responsibility.
Dave is the one who is usually held responsible for the face put forth
by Boost overall. Now the BoostBook design has taken considerable effort
to get a consensus from interested parties, i.e. it was designed by
committee. I think what you are implying is that neither approach works?
One cuts out the input of interested parties, and the other delivers
less than appealing results.
Since we have considerable experience with the review process, I think
we can manage to make a variant of that we can follow. Probably
something close to the Fast Track lightweight version. So:
* Have a new design change, either both completely new design or
modification, be proposed for review.
* An interested Design Review Wizard steps forward (likely the hardest
aspect).
* The author provides the changes as: a branch of the website or
BoostBook styles, and/or as an existing preview of the design. That is
they either provide for a way to get the design locally by the
reviewers, or have it already available externally. Obviously we would
want to encourage the latter, as we currently do for library review
docs. For web site changes, the latter is almost a requirement given the
dynamic nature of it.
* During the review period the design is not allowed to change, as it
would otherwise cause confusion to those giving feedback.
* When complete, the wizard *and* moderators decide whether to accept
the change or not. I think it's important for the moderators to have a
possibly overriding say on this as it's they who are essentially
responsible for the face put forth as Boost.
Good questions.
Yep they are. Hopefully my answers are constructive. And drive others to
comment.
I tried to be as accomodating as I possibly can. Jeez, I
withdrew all objections except one! Still, you take that
with tons of resistance.
I think you have gravely misread Rene's response. AFAICT, all he said
was that there doesn't seem to be any link style around which he can
form a consensus, including your suggested style (having tried that,
too).
Yes that's accurate. What I was trying to say is that from the previous
experience there was one group that liked underlines, another that did
not, another that could not perceive (visual perception difficulties)
links without the underlines, others that liked dark underlines, others
that liked dark text links, others that liked light links, and the ever
present set of people who insisted on "standard" links. My contention is
that there is no such thing as "standard" just many different defaults.
I've personally used a variety of link styles in my web site designs:
<http://redshift-software.com/>, <http://robot-dreams.net>, and
<http://mariamorell.com> for examples. I just explained the variety of
issues others, and myself, raised with the colored link styles. And of
course there are issues with the underline link styles.
We ultimately only have to ways to resolve this:
a) We vote from some set of alternatives, and live with the results. Not
exactly something I look forward to as it will make some unhappy about
the choice, most likely me :-\ But I am willing to use what the
community wants in this respect.
b) We provide for the end users to pick from some set of link styles
dynamically. Ultimately this is the avenue that CSS allows for but it's
currently problematic to implement because of the IE6 albatross.
Additionally it's unfortunate that we can't use the users default style
as that will more than often clash, in unreadable ways, with the rest of
the design.
--
-- 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
