kde.org new design CSS

[Mat Colton]

Am Montag, 21. Oktober 2002 01:11 schrieben Sie:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday October 20, 2002 04:04, Mat Colton wrote:
> > Hi Neil,
> > just couldn't let go...
>
> Never. :-)
>
> > Check the link below for a reworked CSS and index.html. You will have to
> > check the "link" tag in index.html and change for your needs.
> > Printing works now. As soon as i have some free time tomorrow night i'll
> > do a better job: check, clean up and improve the screen/print CSS as
> > well as add aural support.
> > http://web-xs.de/~dev/tmp/
>
> Well, I see that it does work, but unfortunately now this loses the user
> the ability to control which stylesheet he uses.

True, but why would the user want to change the stylesheet? Alternate 
stylesheets are quite nice, but they have to useful. So why would a user want 
to force print or aural CSS? The way I did it the CSS automatically fits the 
output device. Since you (Neil) wisely didn't set a fixed font size there 
should be no reason for a user to switch to an alternate CSS.
Feel free to include alternate CSS for different styles/themes though.

To you ppl in the list: this email was first intended to be a private mail to  
Neil Stevens, now I'm posting to the list.

I did some changes to Neils very nice design ( 
http://usability.kde.org/newdesign/ ). Basically small changes in 
logical layout and markup. Well, anyway, what I learned about logical layout 
and usability, so everything is IMHO.

First of all the link: http://web-xs.de/~dev/tmp/kde/
HTML validates, CSS as well, but some small warnings, easy to fix, not 
important ATM.

We need less links on the page... This is overdoing it and will confuse ppl.

Logical layout:
The site is LTR, left to right. So we assume a visitor reads that way. For 
languages which are not read form left to right we need a different layout. 
We can do this via CSS. For the moment let's stick to LTR. 
Further we assume the scroll bar of the screen output (browser) is on the 
right hand side. So the navigation should be there, not split up as in the 
original layout using tables (http://www.kde.org/testing/). This way the user 
has the shortest way between scrolling to a navigation element and actually 
selecting it. I know a lot of layouts use left navigation, but this comes from 
print layout and is not the optimum for screen layout.

What I did to optimize it for LTR:
- I moved the top line away. We are the KDE organization, not the path to to 
the current document. The first thing a visitor should read is the logo.
- Since it has nothing to do with the content, but rather is a global KDE 
thing, we keep the mirror and i18n'd links in the header. They belong 
together.
- Now we must tell the user where he is, the "history" div is inserted aligned 
to the left right above the content
- Then comes the content
- Then the navigation
- And legal stuff at the end of the page

So now a visitor reads the page:
KDE -> alternative sites/languages -> current document path -> current 
document content -> navigation ->legal notes
Seems logical to me, what do you think?

To check the logical structure of the page load it into lynx. See the problem? 
The sidebar comes first. We need to change this cause we have a display 
inconsistency depending on the output device. I'll think about that later 
today. Now it's almost 6 a.m. and I'm on my way to bed. :)

Another reason to remove three entries (path/mirrors/i18n) from the top row is 
that it's too wide on PDA displays. Besides that it's not good when the path 
gets long even on a normal screen.

Small markup changes:
Added the acronym tag for "e.V." and abbreviation tag for "FAQ".
Acronyms and abbreviations should be marked up according to the W3C 
accessibility guidelines. That means they must also include a "title" 
attribute explaining the meaning. If they are not in the declared language of 
the document we must define the language of the acronym / abbreviation. So 
"e.V." must be defined since it is german.
Changed the link "The abstract of the paper that..." in the first news since 
the link text was not logical. Check between old and new to see what I mean.

CSS changes:
dont really know, some small changes. Mostly removed overhead and changed 
single instance classes to ids. Included printer and aural support. Not much 
we can really do with CSS to enhance aural and braille browsing, CSS still 
has much to learn there...
Set the font-weight to normal for links. We already made sure the user sees 
links due to the color, so IMHO it's a markup overhead. Besides that h1-6  
have the same color and are bold, so we don't want to confuse the user.

I'm new to real team work, so feel free to let me know if I'm overdoing it or 
what ever!
-- 
Bye,
Mat