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

[Paul de Vrieze]

On Wednesday 23 November 2005 15:39, Aaron Shi wrote:
> > 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).

I agree, the reference still looks better. And indeed an LCD is not really 
a good judge of colors.

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

Could you anyway make a version where the infinity symbol is made by 
clipping two "oh"'s together. I would like to see how they visually 
compare. I find the infinity symbol to be dissonant towards the "gent" 
letters.

> 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.

At the time, the design was approved understanding that it would be a 
guide towards the final looks. Not an absolute this and nothing else. 
Further the designer (Aaron) was encouraged to participate in 
implementing his design. Partly to make small improvements, and to fill 
in the design where it was missing. As such I fully believe that the new 
reference could be used as basis.

> 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.

I agree, I think that the main text size should be taken from the browser 
settings. Those are normally reasonable (smaller than wwwredesign) AND 
what the user prefers. The text zoom function is just a kludge around 
sites that have been wrongly designed. The font size of menu items could 
be set, but body size shouldn't.
>
> 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?

Yes it does.

>
> > 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.

I think the design should be made to include a locator when given in the 
page. I would think something like adding an optional "<parent>" tag to 
the DTD. The DTD would then query the parent for it's parent 
(recursively) and display that parent, and then this one. (Creating the 
path). It would be compatible with existing pages, while still allowing 
forward progress. I see no reason why it would be impossible to change 
the DTD as long as current pages are still supported.

>
> > 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.

And I see no reason to not implement them (as above).

> > 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).

Besides the fact that I agree with this, it is also the way that things 
will go in the future as propagated by the W3C. And indeed, css should be 
used predominantly for the design.

>
> > 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)?
>

I see no reason why javascript could not be used to circumvent the 
behaviour of certain (enumerated) broken browsers. Normally working 
browsers do not use the javascript and would look exactly the same with 
or without javascript enabled. The broken browser looks properly (or as 
proper as possible with the broken behaviour) though.

> > 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.

Why not implement either html-4.01 strict, xhtml-1.0 (transitional or 
strict) or even xhtml-1.1. All are compatible with browsers that 
understand 4.01 transitional. If possible xhtml-1.1 would encertain that 
the layout and structure of the pages are properly separated.

>
> 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.

I don't see it either. I also don't see why transitional is needed when we 
have such a tightly controlled source language. None of the pages 
actually contains actual html, so having the stylesheet support xhtml-1.1 
(has no transitional version) should be straightforward.

>
> > 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.

Please still give your suggestions. I think it is important they are 
properly performed.

>
> > 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.

Don't be so thickheaded.

>
> 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).

Actually it is easy to even make IE do such a thing by introducing a 
"strut" and having a proper overflow behaviour. A strut is an invisible 
element that has the minimum with required and as such forces that this 
is the minimum.

> 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.

Probably right. I think that some flexibility is good.

> 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.

I think that the browser preference should be used. Most browsers 
underline by default. But if users prefer links not to be underlined, why 
not respect those users.

> 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?

That's why one should use javascript to enable hacks to work around such 
broken browsers. Most users get the full behaviour, and the broken 
browser gets slightly degraded, but controlled behaviour.
>
> 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.

Also I find that the purple background on the live site makes the site too 
purple.

> > *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.
>
I agree, we should use the decoration where not superfluous and where 
there is space. If the decoration causes space issues, it can be 
reconsidered.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net