HCI in Open Source

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

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