Uncategorized

The kde-www war: part 4

A brief history lesson. The introduction identifies KDE.org as a wall of text with a pretty frame and explains why there is a problem. Part 1 sets conversion goals on our two target markets. Part 2 restructures the sitemap to make sense. Part 3 dabbles a bit on concluding the design criteria for the homepage, and reveals the homepage.

In this part, we’re going to take a step back to the release of the homepage design from part 3, and talk a little bit about the science and justifications behind the design. Firstly, a quick note that the design was tweaked slightly after part 3, as the tweaked version can be viewed here.

All webdesigns are made up of three vital elements that work together to make a successful design. Keep in mind that these elements should be considered not just in webdesign but also by application developers.

Notice how the criteria outlined in part 3 addressed each of those 3 concerns directly. Now let’s took at how we’ve satisfied the criteria.

Let’s just briefly skim through brand – we have addressed this by emphasizing KDE’s visual identity:

  • The design has blue and white as its primary colours, which are KDE’s primary and secondary colours respectively.
  • Every single environmental visual element (ie – headers, footers, and non-content elements) on the page used visual styles from Plasma’s Air and Oxygen styles.
  • Every single functional visual elements (ie- the content element) on the page used KWin’s Air widget style.
  • All graphical symbology use Oxygen icons, especially to thematically link together concepts across the design.
  • The radical design choice of KDE’s first non-bordered layout corresponds to KDE’s philosophies of “Experience Freedom”, “Be Free” and “Breathe”.
  • The lightened fonts after tweaking now also corresponds to KDE’s aforementioned philosophies.
  • The iconic Kabel font is used for the KDE logo.

Now we can ask ourselves when we ask “What does KDE look like?“, as soon as we lay our eyes on this design, we can firmly answer “Yes. Of course! That is KDE!

Now let’s look at the content. Content should always come before function, as it sets the scene and helps our users understand what they should expect from the page. We start by giving the most important bite-sized factoids: what is new and awesome, for our existing users audience, and what is this KDE anyway? for our new users audience. We do this by giving a large banner to represent the latest news for the existing users, as well as a large, digestible (free from jargon) definition for the new users. What is more important is if we study why we placed the elements exactly where they are. Let’s study the eye-movements as a user scans the webpage – red being spending more time looking at it, and green being quick glances:

Firstly, let’s just jump back to reality. It is important to realise that people do not scan a page top-down, they glance top-down, then return to the top then proceed to zig-zag occasionally. This means that some people might jump from 2-5, instead of 2-3 (ie- visually oriented people). Also, people do not analyse in detail whilst glancing through – they search for vital factoids and discard everything else. These have good and bad implications:

The good – this pattern and step-by-step process to grasp interest is aligned with the goals/roadmap we outlined in part 1 of this series.

The bad – we are heavily relying on the effectiveness of elements 2 and 3 to provide the vital factoids.  These must grasp interest. Element 3 will target the text-orientated people, who will hopefully see:

Notice how we have successfully separated people from product, and are marketing KDE as a community. The user is immediately not looking at “Hey, download powerful software and a new desktop interface!” (akin to “hey, get free animated emoticons now!“), but instead looking at “Hey, I’m the most important person here, and something is happening which involves me. Something to do with powerful software and beautiful desktops, which are lovely keywords which everybody can say ‘yes I want it’ to. What am I missing out on?“. This will bring them to element 5 – to Discover KDE, and start their journey.

For the picture-oriented people, element 2 is our vital grasper. As the design stands now, it is obvious that the eye lingers longer over the left side of the image (put the more beautiful part of the image there, then?) but otherwise the image is completely unenticing and uninformative. It shows a rotated desktop screenshot and that’s it. This is bad. This should be changed. The blurb is useful though, as it not only says there is some sort of release with a really long fancy name (Software Compilation, anybody? 6 syllables?), but also zeroes into the single key features why it is so awesome. However there is clearly work to be done on defining a visual style for the header image.

Finally, let’s look at the function. What the user will want to do on the webpage.

This is a little tricky, as the homepage is a hub, not a content deliverer. It’s function is as a signpost and not an infographic. For this the design’s function is to direct users to the right page, and allow the user to understand the structure of the webpage, so that he knows exactly what to do next and how things are categorised.

We’ve already done a bit of this by piquing new users’ interests with the blurb and having their eye naturally fall onto the “Discover KDE” part. However let’s take this a step further by thematically linking certain keywords on the page through sequencing them in the same way, as well as using visual icons to mark their similarities. This can be seen below:

This helps the user understand the site’s structure, or three main “sections”, and emphasises their importance through repeating the sequence again and again. Thus the “About” and “Give Back” sections are already given less priority as expected given our goals outlined in part 1 as well as our restructuring labels in part 2, without entirely ignoring them.

This also performs a very important function of all design: the ability to give the user the impression that they have freedom to choose a path, that they are in control, but subliminally guiding them through a sequenced, optimum path. The user is presented with – yes – the entire sitemap. They can read through every single link and understand exactly what the page contains, but are still inclined to follow the three set paths for them. Also shown in the tweaked layout is that only the Community column is highlighted whereas other sections are greyed out – this will not be so on the homepage (all will be greyed out) but this helps users understand which section they belong in (other colour visual indicators will be in play later). This achieves the structural segregation that the original redesign was aiming for, without being too intrusive or clunky.

I’m going to stop here. Those were the main points I wanted to talk about to help raise awareness of the importance of design. I hope you enjoyed this series, and I’ve submitted it as a GSoC proposal, so if all goes well, we can start seeing things live soon!

Dion Moult

I've been developing software for well over 10 years, work as an architect (not the computer kind, the regular sort), and am classically trained as a pianist. I try to do the right thing when I get the chance in my field, such as through contributing to open-source communities and promoting sustainable living.

More Posts

Spread the love
Tagged: , , , , , , , , , , , ,

7 Comments

  1. Why you have software-community-development 3 times in the same page? Just 2 times, the first one with the big three icons for newcomers and the second top-right menu for the old ones, I think are enough.
    About and Giveback can stay in the bottom.

  2. Hello nick, thanks for your comment. On the homepage, 3 does seem like a bit much, but keep in mind that on subpages it will only appear twice. It has to remain in the bottom “sitemap” too, as otherwise it wouldn’t be a complete sitemap, thus potentially confusing users.

  3. I just have one thing I wanted to point out which relates to branding. At least within the Promo team we’re trying to move away from the old “SC” term which you’ve used in a few places in this series.

    Most of our recent debates on the matter have ended in people concluding that maybe it can still be a technical term used by developers internally to refer to the bundle of code that comes in the 6 month release cycles, but for anything public facing we’d rather just say “KDE software” or mention specifically what you’re talking about, e.g. Plasma Netbook, Marble, Amarok, etc. It seems to me that we’ve also eased up quite a bit on trying to correct people who are saying “KDE 4.x” to refer to the regular 6 month releases in an end user setting. There are some who still don’t like this way of referring to it, but I think the end goal of separating KDE “the community” from KDE “the software” along with creating more recognizable brands for the individual applications and frameworks has been mostly achieved if you look at the way most people describe things these days.

    In any case, great work on these articles and I do hope to see this work utilized on the site! Please be sure to loop the Promo team in if that happens so we can help with the marketing speak during the redesign :)

  4. Thanks for the heads up, Justin! I’ll remember to move it back to KDE Software. When we start developing content pages, we’ll start sending in content drafts to be proofread before publishing!

  5. Thanks for the series. I’ve really enjoyed reading it on PlanetKDE and I hope you get accepted as a GSoC.

Leave a Reply

Your email address will not be published. Required fields are marked *