kde.org new design CSS

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday October 20, 2002 09:06, Mat Colton wrote:
> Am Montag, 21. Oktober 2002 01:11 Neil wrote:
> > 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.

OK, fine.  I can live with that.  It may make for easier maintenace.

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

I threw out the radical idea earlier today that we remove them all, leaving 
the www index page to be the sole jump page.  That would reduce the 
sidebar to be merely the menu.inc-generated links (The Usability tree for 
example) plus a single link to the home jump page.

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

You're right.  And just to remind those who don't know, we solve the print 
problem by setting display: none for the sidebar in the print medium.

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

I'm convinced.  There's one problem, though:  The text at the top overlaps 
with the image at smaller sizes, and it doesn't contrast much with the 
logo image.  Maybe change that text to black?

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

Fine by me.

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

That's just the old flaw in CSS 2, is it not?

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

OK.

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

But we want links in the sidebar <p>s to be bold, because the plain <p>s 
are bold in there, too.


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

Nothing wrong with putting in effort to show us some improvements, I think.  
In fact, action beats talk by me any day. :-)

- -- 
Neil Stevens - neil at qualityassistant.com
"The nearest I can make it out, 'Love your Enemies' means, 'Hate your
Friends'." - Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9s5LZf7mnligQOmERAgk0AJ90zW7O9w/cdov1cDl5WwOnUsNM1ACfWRKr
jlVqL4+urnWIMRlf8x4hXAE=
=tkm2
-----END PGP SIGNATURE-----