Tuesday, September 06, 2005


I finally managed to play around with some of the photos I made during the touristic visit to Malaga on Thursday last week. The result: one of those nifty panorama photos

Of course I wanted do to do this with linux and free software only. So It took me some time to find and install the programs I needed (namely hugin and pano-tools). About 15 minutes I spent clicking together control points to virtually stitch pictures together into one piece. Another 30 minutes of intensive guessing later I finally figured out who that guy on the right was: It was our tourist guide. Ask him if you want to know more about the buildings you can see on the 600 KB full sized panorama picture ;-)

Tuesday, July 05, 2005

Radio button hell

What's wrong with the following dialog?

Both options are mutually exclusive. In the example above one shouldn't use checkboxes but radio buttons. So it's clear for the user that only one option can be activated at the same time, that she has to choose between the one or the other. The dialog should look like this:

Pretty simple, pretty straightforward. Fortunately this kind of mistake became very rare. I actually had to invent an example because I couldn't find one in the wild. That's a good sign :-)

The ones of you who are actively using the new designer from Trolltech's Qt4 (and heavily switching its user interface mode ;-) ) may have an idea where I got the inspiration for that little example. It's borrowed directly from designer's "Edit" menu. There you'll find a "User Interface Mode" entry. It looks like this:

Have a feeling what might be wrong with the above menu entries?

These menu entries look like checkboxes, but behave like radio buttons. In Qt4 (and in previous Qt versions) both the radio button like and the checkbox like menu entries look exactly the same. So there is no visual hint about what's going to happen if a user clicks on such an entry. It could be either the one or the other type of menu entry. To be absolutely sure the user has to check back on that menu entry to find out what happened. Insane, isn't it? This is how it should look like:

GTK, the various Java toolkits, even Windows, they all are doing it like that, are doing it right. Why not Qt? It's not as if the engineers at Trolltech didn't know about that. I sent the trolls a bug report one year ago to make them aware of this issue, actually got positive feedback and hoped they fixed that shortcoming with the new version of Qt4.

Unfortunately they didn't :-(

Saturday, April 30, 2005

Usability in practice?

At my university students get the chance to offer courses in which they teach others things they have extra knowledge of or are especially interested in. The topics usually deal with "Programming with the penguin", "Developing an OpenGL game", "PHP + MySQL", "XML for Beginners", "Linux for Switchers" and the like. Since the software ergonomics lectures the students have to attend here cover pretty dry and old stuff Tina and I thought it may be a good idea to offer a course "Usability in Practice" to give others insight about how usability is done in practice. The proposal was accepted, and we started preparing the course.

While other courses normally get crowded in no time, exactly three (3) people showed interest and registered for "Usability in Practice". We postponed the date, prolonged the registration time and tried a more offensive approach by sticking posters everywhere. In the end it's four (4) people (whoohoo! one more! :-)) who will finally listen to what we have to say about the usability lifecycle, card sorting, paper prototyping and heuristic evaluation. The not so overwhelming interest may have to do with how usability is perceived among the students at my university. It's still considered as boring and unnecessary.

Anyway, during the course the current usability efforts of open source software in general and KDE in particular will be covered as well. So who knows... maybe one of the participants gets interested and wants to get involved and contribute.

Sunday, April 17, 2005

Kpdf usability inspection

I just finished my first usability inspection on Kpdf. It is a really enjoyable PDF Viewer for KDE. Despite of its -compared to that commercial beast acroread- fairly early state of development KPDF is already quite usable. So the issues that were discovered mainly dealt with naming/wording/sorting of menu and toolbar entries. Another problem I found was the similarity of icons. It is difficult to differentiate "Previous Page" from "Back" visually if their toolbar icons look the same.

An old notorious friend crossed my path while going through the various actions: the menubar hiding issue. There must be an easy way to recover the menubar in every view/tool/mouse mode apart from "ctrl+m". Otherwise users may feel stupid and blame themselves for losing "that thing with the names at the top of the window". I hope there will be a KDE wide solution for the menubar issue some day, so users can transport the knowledge they gathered from one KDE application to the next.

Now I am looking forward to discussing the findings with the Kpdf developers. It's a gift from god for openusability engineers to get involved in software development at such an early stage. Usability engineers of commercial products can usually only dream of that ;-)