Dion Moult Seriously who ever reads this description.

Application design polish.

Free software is great. Everybody loves free stuff. However there’s one common flaw experienced by a lot of free software – they look ugly.

The reason behind this isn’t because we have too many programmers (yes, we know you never have enough programmers) and have too little artists – no, the problem is a lot more subtle. The real problem is that there is no clear hierachy within the artists. There is no control. There is no clear structure, focus, and branding. The question so many artists fail to ask ourselves as a contributor to free software is – What do we want to communicate?

To illustrate my point, I would like to use Ubuntu as an example. Regardless of your prejudices for the distribution and/or Canonical, they did do something right – they have a brand. They have a clear, recognisable pallette and style – from colourschemes to typefaces. Why don’t you see it for yourself: go and visit Ubuntu.com. Notice the colours. Notice the icon styles. Notice the typography.

Another example of a project taking the steps in the right direction is KDE and their Oxygen iconset + plasma "Air" attempt. However there is still far to go.

However the issue does not lie with such large FOSS projects such as the above mentioned. Instead the real problem lies with smaller software and application created by smaller developer groups. The reason is because these small applications rarely have to worry about problems such as branding – instead they have to focus on creating an elegant application. Design elegance can only rely so far on the design of widgets in the UI toolkit used. The rest is really up to the developer. Allow me to give a quick visual example of Blogilo, a blog client which I’m using to type out this post. Take a look:

The untrained eye would not see any problem with the screenshot – however the application design above screams complexity. There is no elegance. There is no simplicity – no "flow" (a clear step by step separation of functions). A blog client is not a complex application like an IDE. It exists for you to add, edit, and delete blog posts. Nothing more. When stripped down to its basics, a blog client is naught more but a rich text editor with a few extra options. Instead we have frames within frames, accordion panels, tabs, and buttons strewn about. Overkill, in my humble opinion.

Design polish is a very hard topic to separate what is ugly and what isn’t. It’s blends over into many neighbouring topics such as usability, a macro-view of marketing (in this case, Blogilo is part of KDE), and functionality. If you are interested, however, I would like to direct you to this very interesting blog by Troy Sobotka, one of the folks behind Ubuntu, who discusses this in much more clarity and detail than I am capable of.

No related posts.


2 Comments

p. says: (3 September 2010)

The only aspect in Blogilo that I could detect was the grey colour scheme. How innately dull it is!

Having said that, the set up seems rather user-friendly. Simple.

Dion Moult says: (4 September 2010)

The grey colourscheme is based on my KDE colourscheme settings so that’s irrelevant ;)

As for user-friendly, it’s definitely easy to use, but that doesn’t necessarily mean it’s a polished design. Allow me to throw some questions:

Why, when the window is resized so small, is almost a third of my space taken up by a “media list”, of which I will only access whenever I want to add/edit pictures in a blog post? It would be better for this to be removed and perhaps sent to the sidebar. This strengthens the focus on the post itself, as well as makes the app still usable when resized like above.
The “close tab” button is stuck-on almost without thought on the right. Perhaps we should offer a “close tab” button on the tab itself instead of having to navigate to the opposite end of the screen.
We also see the title twice – once in the tab and another time in the field … directly below it. Is there a way to merge these appearances? Do we even need tabs in the first place? Tabs were built to quickly view available content and switch between them with ease, but how often is the user going to be switching between posts? I know I don’t jump from post to post when drafting an article and I doubt anybody drafts several at once. (tabs inside tabs is rarely a good design decision)
In the “blog posts” list on the right, there is no clear sign that it is a list. There are zebra stripes between items but the colour is much too faint to be easily seen. This gives the impression of a “wall of text” instead of a list you could easily skim over.
Again on the list, notice the “Ma” post is in blue. What does blue mean? Why are the rest black? Perhaps a small icon would be better in communicating the differences in status.
Below the list we have 3 buttons – none of which are immediately clear what they do. Only the “minus” button on the right is somewhat clear, remove post (yet even this is not standardised with other “delete” buttons in KDE). The other buttons are a mystery. Why is there a separator between the second and third buttons? What reasoning is there behind it?
Also, while I am writing a blog post, it would make sense that the priority should be on two things, the post itself and its related options. Then shouldn’t “post options” be the default panel instead of being minimised? Managing blog posts should be shifted down.
Why is there a separation between online blog posts and local entries? This is a nuisance to navigate between two different lists of posts. They should be merged into one list and have status icons (see above) to distinguish the differences between them.

So yeah, design polish is something that too many people don’t realise is so important. It’s something everybody appreciates but nobody actually notices.

Leave a Comment