RE: [www-redesign] Update of http://wwwredesign.gentoo.org

[Aaron Shi]

> I should have said that the last update was not complete as
> far as design was concerned. I was mainly looking for
> accessibility and rendering issues on as many browsers/OS's
> as possible. I got that feedback and fixed the issues that
> came up. I also implemented the rest of the design so it
> should now be more visually appealing and better match Aarons
> reference design. I took into consideration all of the
> suggestions that were submitted and now ask for additional
> feedback to ensure that my changes didn't introduce any
> additional rendering/accessibility bugs and that the design
> is acceptable to as many people as possible.
>
> If there are no more outstanding issues reported I will
> submit this current layout for approval.

Sorry, but this looks worse. The colors (other than what's in the original
graphics) are way off.  I'm going make a wild guess that an uncalibrated LCD
is being used to view the site.  Many panels are not capable of the full
16.7 million range and uses dithering techniques to emulate the other
colors.  So in reality, the colors when viewed on proper LCD and CRTs are
slightly off (but all the "off-ness" in colors adds up and the combined
effect is quite obvious). 


> Any issues with the
> infinity symbol should have been addressed a year ago.

Amen.


> Aarons reference design at www.aaronshi.com/gentoo/ is
> exactly that: A
> reference. In it's current form it differs from his original
> submission
> which was the winning entry and should not be considered as anything
> else but a reference. I tried to stick to that design as much as
> possible but some things were simply not possible.

The reference I made, after listening to comments on the forums, etc., is
what I believe an improvement to the original submission.  However, the live
site right now, while the backend is perhaps implemented with improvements,
the frontend (the design) is a deterioration.  I understand there are
technical limitations to what's possible.  I've worked with CMS's and
combining backend with frontend etc., but it's about injecting data into the
design; not the other way around.  This is usually done after reference
templates are done and "locked," and the final output of the injection
effort is usually very close to the references templates.  The Gentoo
templating system seems to be such a way that everyone working on this
project, Curtis and myself included, have to work contrary to normal
processes in order to force things to work.


> Aarons design uses a smaller default font, that is not
> acceptable from
> an accessibility POV. The main font is at 1em and all cursory fonts
> multipliers of 1em. The main font will remain at 1em which is the
> standard for the accessibility guidelines. If you don't like the
> standard font size every single graphical browser offers a font zoom
> capability, use it.

If you look at all of the professionally designed sites on the Internet, I
bet they're using a font size similar to what's in the reference templates.
The reality is, most people are _not_ on 1600x1200 resolutions and the font
used in the live site is just plain huge.  I'm using 1280x1024 and it's
still gigantic! (All of my browsers' font zoom is default.)  Even
mozilla.org's fonts are about half the size of what we're using.  Looking at
other "modern" open source sites, freebsd (nice facelift), fedora, etc. none
of them are using fonts as large as ours, not even close.  The browser's
zoom capability is really a double-edged sword...

That said, all the "reading/content" fonts are controlled using 1 value in
global.css, change font-size in body and the whole site will change.  The
"reading" font I'm referring to is specified for the real substance on the
page that people want to read, i.e. the content.  The philosophy is that
content "reading" fonts can be larger or flexible (hence I put in the
font-size adjuster so people can increase/decrease the content font size and
have that remembered in a cookie).  However, fonts that are an inherent part
of design should be congruent with the design itself.  

E.g. Redhat, http://www.redhat.com/en_us/USA/home/services/

Their reading font is large, but the fonts associated with the design (nav
bar items, side bar, legal, etc.) are not being blown out of proportion.
People are not going to be reading these elements for hours on end, so it's
okay.  If you consider your _main_ audience, it's irrational to worsen the
experience for 99% of the people so that the other 1% can have an ok
experience.  Redhat's reading font is already on the large end of what is
acceptable in a professionally designed site.

The other problem with setting the default font so large, is that if you
increase the font size just by a little bit, everything will go nuts.

E.g. http://www.aaronshi.com/gentoo/problems/aaronsplus2.png  VS.
http://www.aaronshi.com/gentoo/problems/liveplus2.png

Both of the above were increased by 2 sizes in Firefox.  What I'm getting at
is that if people set their browser defaults just a bit larger, then
everything would explode.  In reality, it's more likely that people will set
their browser defaults larger rather than smaller.  The odds of it being
blown up due to us setting a large default font is even greater in that
respect.


> Purple background with yellow text is hideous. Not going to happen.

It's pea green.  If we consider color theory, this shade of green is much
more in line with our shade of purple (they are as best of a match between
purple and green as you can get).  The saturation is also much closer (69%
vs. 70%) where as with the live site green it's (69% vs. 100%).  This live
site green, when viewed on (proper) displays, actually causes eye strain
because the colors are _unnatural_ together.

Green vs. yellow: http://www.aaronshi.com/gentoo/problems/greenvsyellow.png

Pea Green (top) vs. Live Site Green (bottom):
http://www.aaronshi.com/gentoo/problems/greentest.png  The bottom one hurts
doesn't it?


> The "Locator" would require rewrites of not only the XSL but also the
> actual xml files and is outside the scope of this project.
> Touching any
> xml content file is strictly off limits, all existing xml should be
> backwards compatible with the new design. This point is not
> debatable.
> Use of a database would make this task easier while allowing
> backwards
> compatibility but it will have to wait for a future update to
> the site
> to be implemented.

Fair enough.


> The contents of the uppermost menu are to sites that are outside the
> www.gentoo.org website. They will stay in this location. They
> are green
> to contrast with the purple background to ensure that colorblind and
> other visually impaired people can see it. Green is the compliment to
> purple so I am baffled that people think the combination is not
> attractive. In Aarons preview the light purple color of these
> links is
> not visible to color blind individuals thus it is unacceptable. This
> color will not change.

The contrast between the purples should be enough, the lighter purple is
roughly 2x brighter than the darker purple.  The green makes it standout too
much, especially the live site green.  It's distracting.  Originally, this
element was intended as an indicator (to complement the locator) of the
Gentoo network site a user is on.  If we come back to asking the fundamental
questions, by looking at any given page do I know where I am?  After
browsing around, am I still on the same sub site?  Or have I gone from main
to planet to bugs to ...?  I understand this is a lost cause, but it's good
to know that a "locator" of some sort is being considered for the future.
Breadcrumbs have been a rather standard feature since the late 90s.


> The grey menu should contain links that would be used in
> order of a new
> user and that highlight the main parts of the site. I did
> this quickly
> to have something there to look at. I didn't notice any good
> suggestions
> to replace what is there. If you have suggestions please send
> them. The
> same goes for the wording in the purple boxes, if you don't like what
> they say submit a suggestion for each. Suggestions of "I
> don't like it
> you should change it" that don't include a clearly worded replacement
> will be ignored. The donate box is here to stay until the search
> function is implemented.

Agreed.  I think what we're both noticing here is that we're building the
house from top to bottom rather than from the ground up.  The information
architecture should be in place and/or optimized before the design is ever
started.  Oops, scratch that, if I recall I think swift made a site map
somewhere...  The issue of what goes in the nav bar has been raised before
and there was a semi-resolution to it.


> Graphics should be implemented in the CSS as much as possible to aid
> future maintenance (the xsl templates are huge and not easy
> to maintain.
> The least amount of editing of these files as possible is one of the
> major goals). In text browsers that can handle graphics but don't
> support CSS the upper left logo (which is a background image
> so it can
> be put in the css) will not appear but will leave space for
> the missing
> background image. I can't figure out a way around this. If you have a
> suggestion I would appreciate it.

I tried to do everything in CSS, which is why having a printable version of
the site (http://www.aaronshi.com/gentoo/guidepageprint.html) is easy.
Nothing is changed.  No CSS files are changed.  The _only_ difference is
that the print CSS file is added to the end of the cascade, so that the
print CSS rules overrides certain elements we want to redefine for print.
Basically, with the logically structured HTML, we can change the design a
whole lot without touching the HTML simply by manipulating the CSS.  I.e. I
had in mind different themes and elements for xmas, halloween, etc. and only
an extra CSS file is required to add the changes (without touching the
existing CSS files).


> Horizontal scrolling of the entire page when a code listing is wider
> than the page only happens in IE. All other browsers
> understand the CSS
> scroll:auto tag and will only scroll the actual code listing.
> The same
> applies to inline images within the page contents. IE is broken but I
> did everything I could to make it behave the same as other browsers.
> This is one issue that IE is simply broken on and there is
> nothing I can
> do to fix that. Javascript fixes are available but the use of
> Javascript
> is strictly forbidden. Javascript is not debatable.

I think this problem was fixed in my reference page, some googling uncovered
the solution (http://www.aaronshi.com/gentoo/guidepage.html).  If in IE,
scale down the window, the scroll bars will automatically appear on the code
listing when necessary.  It behaves identically as in Firefox etc.  I'm not
too sure what you mean by the inline image problem, can you explain (maybe a
demo is easier)?


> The <hr /> tags in the Handbook navigation are contained within the
> handbook xsl template. Touching that file is outside my scope.

They look ok anyway, but we can probably add a CSS rule to make it nicer if
necessary.


> The site is not XHTML it is HTML-4.01 Transitional and it
> passes the w3c
> validator. Manually overriding HTML-4.01 Transitional in the w3c
> validator is not required and any errors that it reports if
> you do this
> will not be addressed. If you can come up with a good
> technical reason
> why doing this would benefit anyone I will address it.

The differences between the two specs (at least HTML 4.01 vs. XHTML 1.0; --
1.1+ is another story) are not really that significant.  I don't see why we
can't switch to XHTML unless there are inherent coding in the system that we
can't mess with.


> Navigation and useability studies are beyond my scope. These issues
> should have been addressed a year ago.

I tried to address those issues (with pages of explainations etc.), but my
suggestions were completely ignored.  Hence, I won't say anymore about this.


> The left hand navigation column is dead. No amount of beating
> this dead
> horse will resurrect it. The jumppads will remain at the bottom and
> appear on all non-documentation pages so that those links are
> accessible
> as much as possible.

We can also make additional jump pads if necessary.  I only did 3 for the
sample.


> In Aarons preview the search box and the ads column are placed with a
> Position:absolute and has it's size set. At resolutions below 800x600
> this makes the ads overlap the content and the search box overlap the
> box to the left on every browser. When content is scarce the
> ads overlap
> the footer. This is not fixable given the current state of
> css support
> in the various browsers. After many many many long hours of
> research and
> experimentation I decided that we would have to resort to a table for
> the ads column and include the search (now donate) box within the div
> that contains the four purple boxes with a % width to fix
> this issue. I
> lowered the % width of the donate box and increased the
> others to bring
> it more inline with Aarons original design. It's not perfect but it's
> close enough.

It looks fine at 700x500.  Even smaller at 640x480, it's still ok.  This is
because there's a min-width rule specified for the content area.  Modern
browsers should respect this rule (IE doesn't, but Firefox, etc. and Opera
are fine).

http://www.aaronshi.com/gentoo/problems/700x500ref.png

Speaking of lower resolutions, the author credits takes up the entire screen
(http://www.aaronshi.com/gentoo/problems/700x500live.png).  I originally
thought about doing it this way, but after trying with that same author list
it didn't seem right.  Hence the design was reworked to use the side bar, as
old Gentoo site does, for author listings.  It seems to work better.

The side bar overlapping the footer when there is minimal content is a known
issue.  It's not as if we have the handbook in the footer. ;)  The
alternative is to have the footer block the bottom of the side bar, but the
implementation is much more convoluted that it's not worth it.  On the other
hand, the side bar in the live site stops abruptly if the content is long.
If content is the main focus, does it make sense to show a whole page's
worth of white space just so the sidebar can display entirely?


> Accessibilty guidelines say that all text links should be
> underlined. I
> made an exception for the grey menu bar for aesthetic
> purposes but will
> not make an exception for any other links.

My thoughts exactly, although the author list is missing the underlines.


> gentoo.org and all domains owned by the Gentoo Foundation
> should render
> correctly in all browsers that are still in general use. IE5
> on the mac
> is still a valid browser and will be supported as much as possible.

In my own site logs, Netscape 4 still out numbers IE5 for Mac (go figure).
It's a simple cost/benefit analysis and in the end is it worth it to support
such non-standard-compliant browsers?  What message are we sending? --- we
try to accommodate a few at the cost of the majority?  


> Summary and authors are important and should be prominently displayed
> before the actual content. On the current design they are on
> the right
> in a tiny column that wraps every two words. This is
> unacceptable. These
> items will stay at the top for now unless someone can come up with a
> place to put them that makes sense, looks good, allows the
> summary to be
> seen on top and not below the content (because a summary
> should be above
> the content otherwise why have a summary if you have to
> scroll past the
> content to see it?). The handbook is the only page that has a
> large list
> of authors and authors only appear on the first page so this
> should not
> be a problem.

I had placed the title, summary, date modified (highlightly prominently in
it's own box) at the top, and the authors on the side.  It's the best I
option I could come up with that doesn't kill usability (see my point a few
paragraphcs above re: author list filling entiring screen; see my previous
email re: what is usability).


> *Background color for content was made light grey with black text for
> better visibility of the text. Bright monitors should no longer be a
> problem.

Background should remain white, it's much easier to work with.  To make it
easier on the eyes, just lighten up the text a little (i.e. so it's not
black on white which is high contrast but high contrast also strains the
eyes after prolonged reading).  I used #515151, which is 81% gray.  The
other point for not having colored backgrounds is that it looks particularly
bad on laptops running on battery.  When the screen dims when it's not on
AC, it's all over.


> *background color of the ads was made darker to contrast with the
> content area. Decorative header was added.

Please check the original colors, I think that was sufficient in boxing that
area while leaving the text readable.


> *all extraneous information and decorative news headers were removed
> from the front page to help readability and to bring focus to the
> information. This includes the cow image and text.
> Overwhelming amounts
> of information on the front page should no longer be a problem. This
> also brings the jumppads closer to the top so new users will
> be better
> able to spot them.

If decoration is used sparingly, it's great.  If we want to be purely
information based, and ignore appearance and marketing, we could go text
only.  


> *table borders are now collapsed and only 1px thick. They are
> no longer
> ugly.

Getting better...


> *The purple boxes below the grey menu bar now only appear on
> the main index.

Perfect, that was the original intention.


Some other points:
- margins! Do books, magazines, newspapers not have margins? Keep it
familiar for the readesr.

- In IE, the top content starts ok, as you scroll down, everything shifts to
the left.  If it's a long page, by the time you get to the bottom, 20% of
the content is out of bounds (to the left).  E.g.
http://wwwredesign.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8
The last sentence which says "You may now continue with Installing Necessary
System Tools." only reads "ith Installing Necessary System Tools."

- It's probably a good idea to add Arial to the fonts in CSS.  Right now
we're leaving out the 90% of the PC market.

Hope that helps.

Aaron 

-- 
www-redesign@g.o mailing list