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