Navigation Part II
JaseOne at myrealbox.com
Thu Nov 14 00:23:24 UTC 2002
This is just another quick email from work, but am I reading correctly that you want the one global menu to be used across each *.kde.org site along with kde.org itself with the links going different places on each?
I think it would work much better if kde.org was treated seperately from the *.kde.org subdomains as each subdomain has it's own requirements for content. Sure we could probably use n levels of abstraction to classify the existing menu entries into the global ones, but that has more disadvantages then advantages IMHO.
I like the idea of having the high level categories for kde.org and using sperate pages to flesh out the links giving us opportunity to give a little detail about the links and leaving the main page uncluttered and easy to navigate. Although I think the *.kde.org sites should be allowed their own menu structure as you can't really use the same structure for sites as diverse as accessibility, printing, women, usability, multimedia and development just to name a few.
The structure for each *.kde.org menu should be similar but change with their navigational needs. I will however take a more indepth look at your emails as soon as I get a chance and do some major updates to the requirements.
From: Mat Colton <mat.colton at web-xs.de>
To: kde-www at mail.kde.org
Date: Wed, 13 Nov 2002 22:48:29 +0100
Subject: Navigation Part II
I would like to go on explaining my thoughts on the global KDE.org navigation.
Where I stopped last night:
- The main navigation should go into the header since it is global
- It should constist of on a few links so we have a clear concept that will
work for as many sites as possible and make all participating sites
- The local navigation should be in the content area since the links in there
somehow have something to do with the content.
Now let's see if the concept really works. I suggested to use the following
global links (based on Sebastians ideas):
- Related Links
"Website Settings" is a further link but I'm not sure if all sites can offer
this option, so we'll put it away for now.
Now let's see if this global KDE navigation menu will work for the site of a
KDE application. For example, let's take http://kooka.kde.org . Don't flame
me for the code. :P
Ok, the Kooka website has the following links in the global navigation:
- News Archive
- Future Plans
Using the global KDE.org navigation labels, I would sort it this way:
Inform would include "News Archive" , "Future Plans", "Screenshots" and
Download would be a direct link to the download page.
Develop would be a direct link to the Libkscan page.
Related Links would be a direct link to the "Links" page which is not
available in the global navigation ATM.
Sitemap would be a direct link to , yes, you guessed it, the sitemap.
Leaves us with two links left over: "Home" and "Contact"
Oh yes, how could I forget that yesterday... Ok, they have to be a part of the
global navigation. If I include "Home" and "Contact" to the global KDE.org
navigation labels, then it will work for me on kooka.org.
By now we have the following global KDE.org links:
- Related Links
Getting pretty large... "Related Links" could go to "Inform". Not that we
should do it now. Just keep it as an option in case we feel the navigation is
to crowded later on.
Back to kooka.kde.org. If I redesign the navigation/site structure to the
KDE.org specs a visitor who has been on KDE.org will understand where to find
the information he is looking for. Even the accesskeys are the same. Not only
the *look* of the site will be the same as KDE.org, but also the *feel*. This
is very nice IMO.
I did this check with quite a few KDE related sites which are somewhat using
the KDE.org design. It worked just fine with most of the sites. But I would
like to show a problem I encountered more than once.
Let's try some other site, maybe http://www.konqueror.org/ .
I would sort it this way:
Inform would include the "Learn" links
Download would include the "Download" links
Develop would include ???
Related Links would include the "Family" links
Contact would include the "Contact" links
So it works fine exept with "Develop". IMO "Develop" should contain
information for current or potential developers. Konqueror.org doesn't seem
to offer information on that account. There are two solutions I can imagine:
1. Make a default page in case something like this occurs. A page in which a
webmaster can fill in a few fields, in the simplist case only linking off to
the basic developer support.
2. Drop that link out of the global navigation.
Hmm, which one would you prefer? Any better ideas? I think this problem can be
solved, so IMO the basic concept works so far.
I hope this post gave you a better idea of my thoughts on the global KDE.org
navigation I introduced in my original post. As you can see the concept is
easy to use/maintain, cross-site consistent in terms of look'n'feel and
kde-www mailing list
kde-www at mail.kde.org
More information about the kde-www