Saturday, July 22, 2006

Small steps to a Fitts'er KDE

Fitts' Law is one of the rare reliable predictive models in human-computer interaction[1]. Basically it says that the bigger the target the easier it is to reach. It is e.g. used to measure how easily a widget or button can be accessed using the mouse as a pointer. A well known example of Fitts' findings applied to reality is Apple's menu bar placement. It's at the top with no pixels between it and the screen edge. Reaching for the menu entries in it makes it vertically infinitely large, and as a consequence very easy to reach.

In KDE there are also places where Fitts' Law has successfully been applied. Think of the window buttons in maximized windows. They are "sucked" to the screen borders. Reaching for them is a matter of throwing your mouse into the appropriate corner -- no precise vertical aiming is necessary.

However there are various places in KDE and Qt where rather small changes would lead to an essentially Fitts'er KDE:

  • Use toolbar icons with text
    Icons in combination with labels are a dream team in terms of icon readability and recognition. But not only that, another big plus is the increased target area one can click to execute the action behind the icon.

  • Take advantage of unused space between menu entries
    I spotted a rather odd behavior in various KDE and Qt styles: If you have a look at the menu bar in e.g. Plastik (KDE) or Plastique (Qt4) and move your mouse slowly from "File" to "Edit" you will notice that there are a few pixels in between where neither of the entries gets selected. See the image below for demonstration of the same weird behavior in the KDE style "Lipstick".

    It should be pretty easy to extend the target size of each menu entry. Just make use of that precious space in between. Enlarge the clickable area on both sides of a menu entry by a few pixels like in the screenshot shown above. Clearlooks from GTK is already doing it that way -- as is Qt4's "Windows Style".

  • Connect labels with their respective textboxes, dropdowns,...
    In HTML there is that handy <label for=id> tag that makes the label of a form a click target. So instead of having to click inside a textbox you can also click the label next to it. Try it below!

    As already mentioned on kde-core-devel this behavior should be possible with Qt. I hope this is going to be the default behavior for labels in connection with focusing text boxes, spin boxes, sliders, drop downs etc. But I guess I'll have to nag again at akademy ;-)

  • Make the whole width of checkboxes clickable
    Another strange behavior in Plastik/Qt3 styles: Hover your mouse over the right side of the label of a checkbox. You will notice that while the checkbox gets highlighted you can't actually check it. See the screenshot below for a hopefully clarifying illustration.

    This bug seems to be fixed in Qt4. Now only the checkbox and its respective label lead to the mentioned highlighting.

    While this is one way to fix the bug, another way would have been to make the whole width of the checkbox a click target -- similar to how GTK does it. I am currently not sure which behaviour is the better one. The GTK way could possibly lead to accidental activation of widgets in case people are used to click the seemingly free space to give focus to the dialog. Another topic to discuss within the KDE HCI group...

  • Introduce a dedicated resize handle
    Qt4 already uses one in its previews, the vast majority (all?) of KDE applications however relies on users fiddling with the borders of the windows. What I am talking about is a dedicated resize handle in the bottom right corner of resizable windows. It screams "drag me to resize the window!" and "don't waste your time with those tiny window borders! I am much bigger and thus easier to target!". The dedicated resize handle is right:

  • Populate taskbar from left to right instead of from top to bottom
    In its default setting the taskbar has two rows which are filled from top to bottom. This means that the first taskbar entry doesn't make use of the screen edge - it is the second one that does. The third one then appears next to the first one - in the upper row and far away from the edge.

    This is a rather strange behavior. Yet it could be easily fixed by filling the taskbar from the bottom left to the bottom right first and then populating the upper row. This would also mean less task entries dancing around if one in between gets closed.

  • In maximized windows make scrollbars edge aware
    Now do the following: fire up konqueror and browse to Maximize konqueror and try to throw your mouse to the right edge of the screen in order to grab the scroll bar. You'll notice that you have to move your mouse one or two pixels away from the screen edge to do so. It would be much better if users wouldn't have to aim precisely at the scrollbar but could use the "infinite" width of the right screen edge.

  • Make systray "edge aware"
    Now let's have a look at the systray. There you'll notice that you have to move your mouse a few pixels away from the edge of the screen to be able to select a systray icon. If something similar to the systray prevails in KDE4, it should be a version that is "edge aware".

For users all these steps would mean only small, rather invisible changes. But still they'd magically support them whenever they switch applications, resize windows, scroll pages or reach for a menu entry. Let's do it for KDE4 :-)


Sunday, April 30, 2006

OpenUsability & Kuroo at Linuxtag 2006

It's that time of the year again... Linuxtag! This year Linuxtag will take place in Wiesbaden and not -- as in previous years -- in Karlsruhe. For me personally Karlsruhe was the better choice since a few old friends live there (hello Gaugi!). Linuxtag has always been the chance to meet them for a little chitchat.

Linuxtag 2006 in Wiesbaden is nevertheless likely to become a special one for me: it will be the location of the first Kuroo developer meeting. Karim is flying over from Stockholm, Bjoern and I are travelling from Berlin. Together we will meet at the OpenUsability booth on Friday and Saturday to talk about where Kuroo is heading and discuss further strategies.

OpenUsability will again be present at Linuxtag 2006. You can find us at booth 4a where we will be happy to inform about usability involvement in open source projects. Apart from that we are going to conduct a live usability test of the still new Kuroo interface. For your reading pleasure we will provide you with some good usability books. They are best enjoyed on our comfortable sofa that will help you take a break from an otherwise busy Linuxtag 2006.

Thursday, February 09, 2006

Kuroo - a GUI for gentoo's portage meets OpenUsability

Back then at akademy (remember, remember those hot days in September?) Tina and I gave a talk about personas. Together with the attendees we discussed target user groups for a graphical frontend for portage, gentoo's package management. A few months earlier Karim Ryde happened to registered at, seeking usability advice for his project Kuroo - a KDE frontend for portage. Now put these efforts together, add another usability engineer from OpenUsability, namely Bjoern Balazs, and what do you get? Right, a surprisingly usable GUI for portage.

Based on the findings from the personas talk and the previous kuroo versions Karim, Bjoern and I evaluated use cases and discussed the set of necessary features. Then Bjoern came up with a mockup in Qt Designer which we further refined in various irc sessions. Here's a very early and outdated mockup screenshot we used as a basis:

The main changes Karim in the end implemented are:

  • We reduced the number of tabs and replaced them with a QListBox (let's call it a "icon menu list"). This makes the whole GUI look cleaner and provides the possibility to use the queue icon from the icon menu list as a guide in the package view.

  • The category tree view was replaced with two lists side by side. This gives us a much better overview over the categories and available subcategories. Believe me, browsing the portage tree has never been easier!

  • Kuroo now features a powerful filter mechanism. You can filter all packages or preselect a category and subcategory. If you filter all packages, kuroo grayes out the categories that don't return any hits. The filter line filters as-you-type and notifies you visually if a package matches your query. It's a filter mechanism that should satisfy both beginners and power users.

  • The all new package inspector offers easy access to package specific version and use-flag settings. To avoid clutter and information overflow details about each package like changelog, ebuild, dependencies moved there and away from the main window.

  • The queue view shows progress bars to reflect the status of enqueued packages. You can get a quick overview over which packages are already emerged and how long approximately the remaining ones will take.

  • Plus the usual "many many more changes" ;-)

  • The old kuroo 0.71 with a lot of tabs at the top and bottom and two tree views (click picture for a larger view):

    The brand new kuroo 0.80beta1 featuring the icon menu list and the new category selector (click picture for a larger view):

    For more screenshots visit Kuroo at

    If you are using gentoo and prefer KDE applications, you may want to give the Kuroo 0.80beta1 ebuild a try. Especially the filtering mechanism beats the pants off the emerge shell commands. Stop by at #kuroo on freenode and tell us what you think about the new interface. Feedback and bug reports are highly appreciated :-)

    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 ;-)