Dion Moult Seriously who ever reads this description.

The kde-www war: part 2

Before I begin this (delayed) post, I would like to reemphasize that a sub-agenda for these blog posts is to raise community-awareness about design issues in KDE. The website is certainly not the only area where there are design flaws, and I was very happy to read over my Christmas holiday a couple a blog posts here and here by Aurélien Gâteau about design issues within applications. I hope we can see even more of these :)

In the initial post, we talked about the elephant in the room: the wall of text that is KDE.org. No solutions were presented, but symptoms were outlined. Then, in part 1, we discovered that the wall of text was partially a side effect of a deeper problem within KDE – the structure, or lack of it. We discussed KDE’s marketing objectives, and the corresponding misalignments within KDE’s website. We finished off with outlining the ideal situation in the future. Today, we are going to talk about achieving it.

KDE has a lot to offer. Our goal is to filter down what it offers based on their relevancy to target user groups. So before we start, let’s look at the current state of KDE’s immediate “sitemap” – this is what the visitor is presented when they first look at the site. I’ve divided them into columns that they belong in, and briefly described in bullet-points what each page does.

Yes, that was long.

Too long. In fact, let me break down the issues here:

Too much choice.

This is the biggest problem here. KDE has a lot to talk about, but newcomers don’t want to be slammed with all of that in one go. For websites belonging to smaller services, each navigational item can highlight a different issue without overwhelming the visitor, because each wrap nicely around a single point of focus. KDE has multiple points of focus. Thus, it should only provide navigation items which hit each topic, not sub-topic. Here are two other websites which deal with the same problem very effectively: Mozilla.org and Opera.com. As you can see, Mozilla ignores submenus altogether, and Opera has a very clear breakdown of the topics they deal with. All in all, nobody should ever be presented with 44 navigational choices.

Imbalance in choices.

Not only is too many items in “About KDE” confusing to the user, some areas in the Community section really seem like pagefiller on what doesn’t need to be included, and others are just a massive list of items. In contrast, the Workspaces section only has 3 links – which combined together really fail to deliver what they could potentially deliver. The user is left with a “is that it? Pages upon pages of history and verbose description about KDE’s past, and only a couple screenshots about what it’s like now?“.

Double entries in the navigation.

A big problem here is that the navigation headers themselves are links to a page instead of a plain divider as it is meant to be. For example, the “About KDE” is a link, and “Community”, “Workspaces”, “Applications” etc are also links. Often this results in the page being simply a summary of all of its sub-pages, which means information repeats itself, two pages have to be maintained in the future instead of one, and users get confused of where the “official” source of information on a topic is. The summary often seems half-motivated, just to fill up a page, with the only exception being the Dev. Platform page.

Ambiguity in categorisation.

The most immediate ambiguity that shouts out at me is the “Support” category. I immediately thought “How to Support KDE”, as is the norm on most other sites out there, but it turns out that it is actually “End-user Docs/Help”. Apparently I was not the first to be misguided, as seen by the later-added “Join the Game” link, which is therefore miscategorised. Similarly, a lot of the “Community” which I identified in my part 1 is nonexistent in the Community section, but is instead filled with links about “KDE: The Foundation”. The Workspaces and Applications category is also separated, even though it need not be – as they are often bundled together when presented to the user. The result of this is a half-assed workspaces section of the site which really undersells what we have to offer.

So, what now?

We have to completely reorganise the website, obviously. The new navigation has to:

Now that we have a clear list of goals, I spent a few days brainstorming and designing a new structure along with the kde-www folks. Here’s the finished product:

Less choice, less confusion.

This new structure narrows down the number of items to 29 areas. However, we’ve decided to not immediately present all 29 to the user, instead settling for showing only 4 items, Community, Software, Development and Support, with the About items hidden in the footer (only those searching for those pages should find it, we shouldn’t showcase it). We’ve merged the Workspaces and Applications sections into Software, which essentially is a visual tour through KDE, instead of splitting it up into single, solitary pages. The community section actually does have community links this time, and we’ve narrowed down the Development items to the bare essentials (open for debate, as the -www folk aren’t desktop-devs), as in general the devs know where information is kept. Ideally, the Development section’s objective is to make it easy for new coders to join.

It is a little hard to describe, but many pages have been merged and some even completely removed, and I won’t go into details describing why every choice was made.

Points of focus

I’ve highlighted with a blue square several points of focus, this are in general more important navigational items, as they represent key sub-topics in each section. Later on in the design phase we shall discuss how these can be emaphsised visually.

Aligned with marketing’s optimum navigational route

I’ve made two arrows in the diagram above, one blue and the other red. The blue represents the optimum path for our new users. It starts them off with “We are KDE”, to answer their question “What is KDE?”, then guides them through the Software section, a visual mosiac of pretty colours, screenshots and beautifully presented features to persuade them “Why is KDE awesome and why should I use it?”, finally, we land them at the “Get KDE Software” page, once they’ve said “OK, you’ve had me convinced. Let’s get started”.

The red arrow is slightly more complex, for people who already use KDE. Their landing page is the “Get Involved” page, of which the objective is to answer the question “Where do I fit in?” When answered, we will direct them to one of our many community outlets within the community section and help them start their journey with KDE. Alternatively, should they be interested in joining the technical aspects of KDE, they can learn about the Dev Platform, and get redirected to the Techbase, which should turn them into super geeks in no time.

That’s it for part 2.

Thanks for reading and I hope you’re enjoying this series. There’s still a long way to go, and you can actually keep up to date on it via the WIPUP project here.


16 Comments

David Greengas says: (6 January 2011)

Excellent work! I am very impressed with the level of thought that you put into this. For me, though, support means end-user help. This may be due to my personal experience and the culture of my current employer. To me, “Get Involved” implies what you put as Support. Perhaps it is the “Join the Game” section. If the purpose of Support is to support the KDE community and not help for the user visiting the page, then perhaps changing the title to “Support KDE” would make the message more clear. Now that I am thinking about it, isn’t development a form of supporting KDE. I understand that development is very critical and many visitors may wish to develop for and/or using KDE technologies, but could it be part of the support section?

I am really looking forward to seeing your ideas implemented at kde.org.

Dion Moult says: (6 January 2011)

Yeah there is a lot of ambiguity on this, I’ll have to consult a thesaurus later on. Thanks for the support! (no pun intended)

frank says: (6 January 2011)

Something to think about: I was looking for the 4.6 RC2 tarballs and thus discovered that there is no download page anywhere in the menu. Eventually, google directed me to download.kde.org. (wtf)

Also some more, albeit slightly unrelated, general rant about the presentation of the site:
What is it with the big banner graphic at the top? Don’t the webdevs use netbooks from time to time?

Plus, I’m glad I surf with disabled Javascript by default. I’d go nuts if I had to use a menu that takes that long for transitional animations.

Dion Moult says: (6 January 2011)

About your point on the download page, it’s in the roadmap to be addressed.

The presentation of the site is also being addressed, you might want to check out the WIPUP project I linked to in the post to keep up to date (still a work in progress, of course!)

The current plan is to eliminate a dropdown menu like that, instead we will only show the top 4 topics.

pvandewyngaerde says: (6 January 2011)

i recently mailed kde-webmaster to ask if there was a mobile version of the site (for smaller devices) because i could not find one. I did not get a reply.

maybe this is something to think about to create if there isn’t one.

Dion Moult says: (6 January 2011)

I don’t know of a mobile version of the site. That’s definitely something to consider in the future, but for the moment we’re taking things one step at a time.

Aurélien Gâteau says: (6 January 2011)

Great work! It’s nice to see people really thinking about the organization of a site which is an important representation of the project.

Other (somewhat unrelated) pet peeves of mine regarding the site:

– Breadcrumbs are difficult to find and to read: the fact that they are at the very top of the page does not help the user to relate them with the menu. And the fact that they use bullets instead of arrows to separate items make them look like separate categories: it does not express a parent/child relation.

– Overuse of the blue color. This one is highly subjective of course, but I think the site would look much better with a white background for the content box (I like the blue background on the left and right borders)

Dion Moult says: (6 January 2011)

Thanks Aurélien! We were actually planning to remove the breadcrumbs – if a user needs breadcrumbs to comfortably navigate a website, the website is structured badly.

Overuse of the blue colour is a tough one to tackle. Firstly because KDE doesn’t have an official secondary colour, or really any defined colourscheme. However we _are_ getting sick of the colour blue, and will definitely get more colour into the site.

Stéphane Péchard says: (6 January 2011)

Thanks to have done this precious and courageous work, this was highly necessary in my opinion!

nick says: (6 January 2011)

For secondary color I propose a pale pink like the “Cherry Blossom” color scheme.

mutlu says: (6 January 2011)

Excellent work! Your proposal is indeed way better than what we have now. Thank you for your work!

maninalift says: (6 January 2011)

Personally, I don’t experience the kde.org website as hard to take-in / parse / navigate. It is laid out in sections and I can quickly find what I’m looking for.

Perhaps it can be improved or other people have a problem with it but I don’t.

Jackie says: (6 January 2011)

Man, your blog posts are always walls of text! Can’t be bothered to read them, really! Any chance you stop being so verbose? Or give a summary at the top? Kbyethanks!

Markus S. says: (6 January 2011)

Great work!

Dion Moult says: (7 January 2011)

Jackie, unfortunately to actually describe what’s going on I do have to make it verbose. There are situations where verbosity is appropriate and situations where it isn’t :)

If you want a TL;DR, just look at the pictures, it shows you before and after.

Links 7/1/2011: Linux Foundation Expands, GTK+ 3.0 is Near | Techrights says: (8 January 2011)

[…] The kde-www war: part 2 Before I begin this (delayed) post, I would like to reemphasize that a sub-agenda for these blog posts is to raise community-awareness about design issues in KDE. […]

Leave a Comment