Now that we know what we want to achieve and the structure of KDE.org, we can start thinking about the layout of the home page. The home page is – obviously – the most important page of the website. It acts as a central hub to link together everything that KDE has to showcase, it acts as the first stop for information for KDE newcomers, it acts as a publicity and news broadcast, it is the link between the various KDE sub-communities and communication channels, and most importantly, in today’s web-centric world, it defines KDE’s visual identity. After much debate, it had to satisfy the following criteria:

• Embodies KDE’s visual style and branding – ie, the Oxygen, Air, Breathe, and Be Free. It should be a design that when you see it, you say “that looks like KDE”
• It had to make people get KDE. To understand KDE not as a product and a software suite, but as a community. We want them to share with KDE’s passion. KDE has grown further than just a collection of apps and a desktop interface, and thus we can no longer be so shallow as to market it as such. We must follow our rebranding efforts to separate people from product, and emphasize open-source’s greatest strength – the community. We are a community, not a company. We create passion, not products.
• It had to showcase our latest and greatest event/release/activities. However we need to showcase it in a way that people understand. Saying “Akademy 2011 is here!” alone doesn’t mean anything. Nor does “KDE 4.6 released – experience freedom”. Let’s change that to have meaning.
• Clear segmentation between Software, Community and Development sections – to succeed where the current design fails. Let’s not make it a maze.
• Absolute directions towards the goals we outlined – Goal 1: to become a user of KDE. Goal 2: Say hi and tell us what’s up. Goal 3: would you like to scratch your own itch?
• Allow the user to understand how the site is structured and what exists without overwhelming them.

For this part of the war, I’m not going to write a wall of text. I’m just going to throw out the design right now, and let it speak for itself.

More to come. Let’s make a change.

No related posts.

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:

• Provide a smaller number of choices
• Properly categorise navigational items
• Remove stub pages that are unnecessary
• Remove “summary” pages that are unnecessary
• Hide pages that “only those looking for it should find it” (eg: About Free Qt Foundation)
• Expose more of KDE’s community, (forums/planets/irc/mail lists/social sites/ocs/etc)
• Guide users through our outlined optimum navigational route which is aligned with our marketing efforts (as identified in part 1)

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.

No related posts.

In my initial post, I talked about the wall of text. I described some of the symptoms of the wall of text, and proclaimed that kde.org is terrible. I listed some of the basics of cleaning up text, and gathered some information about the “why” of kde.org.

Unfortunately, KDE.org is representative of a very large and vibrant community, and although formatting and eyecandy insertions will come in good time, we have to first understand the site’s structure to make informed decisions before tidying up small details. KDE.org’s wall of text problem is not simply due to a few bad aesthetic choices, but instead a side-effect of a more fundamental problem in KDE-www’s structure.

When I defined the wall of text issue, I described the problem being boiling to the essence of what you’re trying to communicate to the audience, and how to present it. Thus let’s look at what we are trying to communicate to the KDE audience – of which there are essentially two parties:

The uninitiated potential KDE user

The new user is interested in the single question of “What is KDE?“. They will want to understand that KDE is a community, and that its product is KDE SC – of which is a multidimensional beast full of wonders both for end-users and developers. When this has been answered, we want to tell them “Why is KDE right for me?“, and finally when convinced, “How do I start?“.

New users have a very specific workflow, and so we should recognise this, tailor it to them, and remove any potential “sidetracking” factoids.

The existing KDE user

The existing KDE user knows what KDE is and is currently using it, but most importantly, the existing user IS KDE. The rebranding effort was not about changing KDE to KDE SC, but instead about separating product from people. Technically, open-source is simply a business model, but in reality, open-source is a philosophy constructed by people. KDE’s challenge is how to turn one of open-source’s most intangible qualities into an axiom for all users.

So let’s talk a bit about KDE instead of KDE: SC. It has a “magazine” of sorts, the Dot, which gives “official” news on the ongoing events in KDE. It has an active blogosphere by PlanetKDE, which is populated basically by the people behind KDE: SC, which report upcoming features, discussions about KDE-related topics, ongoing physical events, and ongoing virtual events. It has a micro-blogosphere, by buzz.kde, which highlights recent Flickr and Picasa activity, YouTube videos, Tweets, and Dents. KDE’s community also has the Forums, which acts both as discussions, support and brainstorm. There is a multitude of Wikis: Userbase, the by and for users, Techbase, the by and for developers, and Community, used to organise community activities. There is KDE e.V, which does awesome stuff which isn’t publicised enough, and a variety of groups in social networks such as Facebook and Linux.com. Freenode’s network has a collection of IRC channels where KDE enthusiasts hang out. There is a variety of regional communities which all hold their own KDE specific stuff, and an entire of network of community-contributed KDE resources through the OpenDesktop API, and various other KDE connections through the SocialDesktop.

For your convenience, I’ve bolded what is KDE in the above paragraph. KDE-www, being representative of KDE, must stress that this is what KDE is – firstly by presenting in a digestable form the amazing influx of activity from all of those sources, and secondly by making it easy for any KDE user, old or new, to find out where they belong, and how they can add to the community. If you look at KDE-www from this perspective, it’s not hard to come to the conclusion that KDE.org is terrible.

But where do we start?

Given such a complex problem, let’s start by mapping out the ideal routes for each user. Here’s the proposal:

When looking at the chart above, notice how we clearly separate KDE from KDE:SC. I would like to highlight that the two final goals for existing users are not mutually exclusive. You can both contribute to KDE:SC but at the same time contribute to KDE – as long as you communicate your activity.

Now that we have identified the ideal paths for our target audiences, we can start making informed decisions about restructuring KDE.org. But before I get to that in part 2, feel free to add your opinion.

P.S. There is some wrong terminology used when it comes to KDE:SC, it should be referred to as KDE Software, as SC is more of a technical term used to describe a specific subset of packages in KDE Software.

No related posts.

(Note: if you’re not interested in reading this post, just skip to the last paragraph where you can help give your 0.02 cents)

Somebody famous once said that it’s very easy to write. So easy, in fact, until the problem wasn’t with finding things to write about – it was finding things not to write about. The question was how to write concisely: boiling to the essence of what you’re trying to communicate to the audience, and how to present it.

But why is it so terrible? Despite what literature students tell you, people do not like to read. Ideally information should enter their brains without having to make any concious effort whatsoever. As interfaces are all about sharing maximum functionality with the user without sacrificing usability, knowing how to minimise (or present differently) the use of text is very important. Here are a few points to consider when critiquing – it is by no means complete and is not applicable in all scenarios.

You shouldn’t need explanatory paragraphs in your interface.

If the explanation is about your product, it’s ok to have it, but it shouldn’t be as long as a paragraph. If the explanation is about how to use your interface – that is the ultimate evil. The easiest way to remove these is to find isolate the most relevant element of the interface to which the explanation belongs to, then only make that explanation appear if the user is interested in that single option. Another way is to split up your interface into multiple interfaces to reduce the complexity of the things the user has to absorb in one go.

Don’t have more than 10 items in your main navigation.

Unless you expect a lot of repeat visitors who know exactly what they’re doing, of course. The point is that newcomers don’t like choice. They like the illusion of choice, but it is your job as the designer to secretly guide them through to the optimum “first impression” route. If you want to sell a product, you want them to be intrigued by X, then be introduced to Y, then be amazed by Z. And in that order. If you offer a service, you want to think what your target user’s daily functions are, and make sure those are in your main navigation. The rest, stuff it elsewhere.

Icons help. They really do.

Icons speak for themselves. A red X means more than a “No”. A greyed out X means more than a “Not available”. An “i” in a circle means more than “More information”. You can forego the word “Profile” altogether if you use an icon of a person. Plus, icons make your interface look prettier. If anybody isn’t sure what an icon does, they can just hover over it.

Be careful of how you present dates.

Dates are the easiest way to reduce readability of your interface. When given the date 04/05/06, Americans will read it 5th April 2006, Europeans will read it 4th May 2006, and Chinese/Japanese will read it 6th May 2004. The entire string “04/05/06″ looks like code, and your brain has to do an awful lot of deciphering to understand it. It’s often best to give a full string “4th May 2006″ if it’s in the archives where dates are important, a “Last Month” if the user is likely to only be interested in relative dates, or “4 May” (omitting the year if possible) if space is tight. The date is rarely the most important piece of information in a system, so hide it somewhere that only interested people would see.

Present your text semantically.

On computer systems it’s easy to think of text as lines with line breaks. Instead, get back to thinking of text blocked into paragraphs, with presenting one point per paragraph. If you have a list, use a list. Of course on the internet CSS makes this easy to do.

Create consistent visual format indicators.

Bolding text is good for emphasis, colour signify more information, italics hint at “quoted” text, font sizes represent importance, and alignment influences the workflow. It’s harder to do this on desktop applications, but still possible.

Over the next few weeks I will slowly document exactly how we can put this into practice through a live sample of KDE’s website. I will analyse each page and document it here. My objective is to not only beautify and improve KDE’s website (not only defeating the wall of text, but also improving it all around), but to also increase awareness about this in all of KDE’s applications.

Before I start, I need to collect some qualitative data from you, the community. Simply leave a comment to this post answering the following question:

Do you use KDE.org? (as in www.kde.org, not any subdomains such as the techbase, userbase, dot, etc)

If yes, was it a one-time “tour” use, or do you go to it regularly? If it’s a one-time, what do you expect kde.org to offer you? If you go to it regularly, what do you check most often?

Cheers, and until next time!

No related posts.

It is a fixed width, fixed height website design. Technically speaking, it’s a rather simple design. Most website frontend coders would just launch right into slicing, but this time I wanted to have some fun. I wanted the freedom that any slicer and designer yearns towards – perfect separation between presentation and content, and complete disregard for browser compatibility.

Yes, if you haven’t already guessed, I built this site with CSS3. The only images I used in the end were the green background image, and the splash screen background image (oh, and the leaf icons for the navigation, but those don’t really count).

Most of the layout was straightforward using things like the new border-radius and box-shadow tags. However the lump in the navigation bar posed some complications. In the end I was able to recreate it using a three-layered solution (via the z-index tag). The first layer held the navigation strip with shadow effects. The second (above first) layer created the lump in the navigation’s shape and shadow. A third layer mimicked the second except with a slightly decreased width, slightly offset at the top and a shadow of the same colour as the background to create a "fading" effect for the shadow on the sides. With position: relative, and offsetting to place them, I managed to recreate the effect pretty darn well, if I might say so myself.

Finally, I used Google’s Font API to choose a more appropriate font, applied text-shadows (with a different colour in my a:hover tags to create a nice glow effect) and stuck it up online for my friend to see. Here’s the result (output via Gecko renderer):

This multi-tab bar is a common webdesign element, so this trick might help other CSS3-yearning developers. Here’s the code for those who are interested. The design works in Firefox, Opera, and Safari. Chrome does not render rounded shadows correctly but otherwise works fine. It fails with IE8 and below. Haven’t tested IE9.

No related posts.

Firstly – the the WIPUP beta aftermath. Could’ve hoped for more users, but I’m happy with how people are picking up on it. So far all feedback has been positive, and we’ve picked up a good few members along the way, some of which have become users. Now that I’ve signed WIPUP up on Google Analytics, we’ve got shorter, sweeter reults:

Because I like looking at the results in percentage increases, I’ll let you make your own conclusions this time.

Meanwhile, a few noticed that this release’s splash was not made by me – rather it was contributed by Nathan from Cetan.ca. This means that if anybody wants to contribute splash artwork, I’d be more than willing to use it – provided that it’s abstract, and that it passes as aesthetically pleasing – and of course credits will be duly given.

The ThoughtScore Project has resumed production – and surprisngly to some – not in any graphical area, but rather in the script. I’ve submitted what I’ve started on it as a WIP available here, and once I implement the “paste revisions” idea for WIPUP suggested here, I’ll allow you to actually write parts of it (well, if you really want to – but no promises on accepting them).

I’ve also been, despite sans internet for 2 days in a wonderful place called Bandung (reaaally beautiful if you go to the right places) I’ve also been busy giving back to the community in KDE. We now have a lovely release counter image (demo’ed below), my submission to their KPresenter template contest, and a little progress on the upcoming release announcement for 4.5. Not to mention I’ve also been in the middle of setting up KDE’s site for development on my localhost to tackle “polish” issues, of which you may see some of my critique here.

Of course I’ve still been doing part/fulltime work doing webdevelopment (on my 3rd project now wheyhey), and so if you need any webdevelopering done you know who to poke. Also, being in Indonesia also means I’ve been rockin’ with my relatives.

Come on, a post like this with loads of links definitely means I’ve been busy. Excuse the insightful-informative post tradeoff.

No related posts.

Every month, the WIPUP website gets synchronised with the Git repository hosting the code. It wasn’t long ago at all since the February sync was performed (21.02.10) and since I’ve been having mock exams that generally means I have a lot of free time (well, a couple all-days after the mocks) which I’ve been a busy little bee whacking down features. So while I was initially fearing a "maintenance sync" I’m happy to announce a feature-packed release.

Release notes are in their full glory in the WIPUP Release, and comments should be left there, not here.

This is a massive update, and I highly recommend people to start checking out the rest of the site and try it out themselves.

Well, time for a break from updates then!

No related posts.

Windows Mobile 6.5.3 and below is widely regarded by many tech fads as a to-be-deprecated technology in favour of other smartphone OSes and possibly the upcoming Windows Mobile 7 OS, revealed just over a week ago. However much of the hidden credit behind the WM 6.x series lies in its ability to tweak and adjust the OS to such an amazing extent not really associated with Microsoft – all of these are found in 3rd party applications scattered around the internet that it takes such a long time to monitor the upcoming applications and find reliable ones. This gives the false impression that the system is underpowered. It wasn’t until almost a year ago that Microsoft released the Windows Marketplace, the equivalent of Apple’s App Store in order to solve this problem, but it’s a developer-initiative process to distribute using this system, and so many of the gems still remain hidden.

Those who have gone app-hunting would be familiar with sites such as freewarepocketpc, wm6software, pocketgear and the ever-so-reliable XDA-Developers forums. However we have a new kid on the block, BestWindowsMobileApps.com.

The site at first glance runs on WordPress with an aesthetic design that leaves little to be desired. This WordPress setup has all of the necessary plugins and additions which make the site appropriate to its purpose, including a featured application section, random apps, latest apps, social network sharing, related links (quite inaccurately labeled as a blog roll in our opinion), and the compulsory commenting system. It communicates its purpose extremely clearly and despite a seemingly random blank space on each sub-page near the header (probably for advertisements in the future), it looks extremely credible and up to date, which is a vital impression for such a site.

The site gives an unbiased review of applications submitted by developers and rates them on what I believe to be rather well-chosen sub categories: user interface, features, ease of use, and re-use value (if the app is a one-time use-and-forget or not), and for games graphics and sound ratings are also provided. Each of these are given a half-star rating out of 5 of which each rating is given a clear definition in their about page – 1 star for a application that wasn’t even worth the review and 5 stars for the perfect application that deserves recommendation to all WM users.

The site is two-tiered, splitting applications into two main categories, "Applications" and "Games", then further narrowing down the choice to your regular list of sub-categories such as communication, entertainment, lifestyle, media, etc. Although most of these portal sites have these categories this site is different in that it is completely centered around them instead of offering a more random browsing experience like others. Unfortunately there seems to be some navigation duplication in the main menu, such as Apps takes you to the same place as Categories -> App Store does, or we seem to have an unneeded single subcategory under Tools being Utilities, or that the supposedly macro-category of "games" is seen again inside Categories -> App Store, etc. Similarly we were shown this link to what seems like a "Games category" description page, but I haven’t been able to find a way to navigate to that page on the site. Perhaps because that page seems unfinished (some categories are not annotated) but this suggests a few fundamental navigation problems. This may serve to confuse newcomers but is a relatively easy problem to fix and on the whole provides a very instinctive navigational sitemap.

The list of applications is just as aesthetically pleasing as the rest of the site. It provides a quick snapshot of the name of the application, a dedicated icon (instead of other sites which rather badly autogenerate thumbnails) and a blurb. Although a little too much emphasis is placed on the date and reviewer than we’d like, we suppose it matches the feel of the site. Given that a one-liner summary of the app’s function is appended to its title it makes it really easy to find what you’re looking for.

An application’s review page does suffer from some visual glitches here and there that detract from the previous professional impression of the site. Some layout ideas could be rethought, such as placing the tags, post author and date and a rather large box with minimal information at the top instead of launching right into the review. However the review itself is presented in well-formatted narrative blog format not unlike this post and has plenty of app screenshots showing the app in action. It walks through the beginning impression, tours the features, and provides a consice summary to wrap up. The writing style is easy to understand and well-structured. Consistent throughout all reviews are a bullet pointed pros, cons and a possible improvements section at the end, your version number and price, the beforementioned star ranking system and an overall rating. A complementary link to the developer’s site is provided as well as a link to their sister site to download the product. The rest is taken up by social networking and comments which unlike most other review sites contribute quite intelligibly to the review.

Developers can submit their apps for review on quite ethical terms including unbiased reviews and understandable property rights. It’s a simple enough process and very appropriate.

Overall the site is quite polished with a few visual presentation quirks to work out. Some reviews are a little short (especially those with low rankings) but seem to communicate the message effectively enough. The duplicated navigation may be confusing, as well as some category structures needing to be rethought (for example, what is the "XDA dev" category?). The site is still quite immature in terms of content quantity (we’re predicting about 100 reviews, and we did notice some overlap in categories, which isn’t necessarily a bad thing) but from what exists, it’s some good quality reading for those on the hunt for the perfect application set. I must say I didn’t set my sights high given the existing cobbled and maze-worthy app portal sites but this one has potential.

No related posts.

Well, go check out the KDE.org website to see the real deal. For those interested in more details they can read the KDE Dot article about the relaunch. Pretty awesome, except that I was originally credited as "Doin Moult" (now fixed). Hopefully I should be poking my nose into more KDE www projects in the future.

Also happy to see a spike up to almost 1000 views in the past week of WIPUP updates. I know it’s unfinished and all, but I must say I quite like using the system. Perhaps in the future I should try out some other media types in my updates to see how well they fare.

No related posts.

Check out the latest mockup update here.

Past mockups viewable in full on my WIPUP profile.

No related posts.