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 http://planetkde.org 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 :-)

[1] http://en.wikipedia.org/wiki/Fitts

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 OpenUsability.org, 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 kde-apps.org.

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