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

20 comments:

Anonymous said...

"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."

Sadly, the default "maximize"-behaviour in KDE makes the windows moveable, and hence not really maximized.. so therefore Fitts law only applies when the user has changed the option in kcontrol :(

Marcel said...

I've never noticed those unused pixels next to the scrollbar in a maximized application. Making them usable is just "The Right Thing"!

Anonymous said...

"Sadly, the default "maximize"-behaviour in KDE makes the windows moveable, and hence not really maximized.. so therefore Fitts law only applies when the user has changed the option in kcontrol :("

Go to KControl->Window Behaviour->Moving, uncheck "Allow moving and resizing of maximised windows".

I thought it was the default... If not it should be!

Re the blog: All good points. Someone do it!

Anonymous said...

The "In maximized windows make scrollbars edge aware" struck me. I consider it a huge advantage of KDE over Mac OS that you can resize windows at all borders, not just at the resize-handle at the bottom right (these "move window to the left, make it bigger" things are a nightmare).

To me it makes perfectly sense to be able to make a maximized window smaller by dragging the right border to the left (we can maximize it later again). And this contradicts your idea of making scrollbars edge aware. Who uses scrollbars anyway, now that we have mouse wheels?

Anonymous said...

Whilst I agree usability is good, I'm slightly worried that it will increase the "dead space" in KDE.

When I'm working on a fresh install of windows, the first thing I do is reduce the scrollbar size to 11 pixels and title bar to 18. 99% of the time I use my mouse wheel, so why waste all that space.

But in KDE you don't seem to be able to do this. Massive boarders and bars. Tabs in windows seem to have more space round them than the actual text in the middle takes up.

For me, usability also comes with the removal of the frustration of having to move windows round to see more information. Something I find myself having to do in KDE alot more than in Windows.

vladc6 said...

Another way to maximize the use of space in the taskbar is to make the buttons as big as they need to be to include all the writing if there is still space. Why cut the title in the middle when there is space to display it fully?

This is possible in KDE, but it is not the default -- I think the usability gurus should take a look at what's best.

Here's the bug I filled out last year about this issue:

https://bugs.kde.org/show_bug.cgi?id=109741

Evan "JabberWokky" E. said...

I've maxed out Fitts law in several ways, plus used some innovative KWin rules to create the following desktop:

http://www.cheshirehall.net/link/a/06.07.25.10.31.15.jpg

Note little things like the K menu and a new Konqueror session button are the in the "infinite" corners. Tabs are always on the bottom, so application and sub-application switching is all there (well, they are really just context indicators, as I use the keyboard to switch both apps and tabs).

"Edit left, view right" is the paradigm... Konqueror always sits to the right, file browsing or web browsing. Konsole, Kate, KMail, etc all live on the left. I can thus look things up for an email, edit a webpage and view the result or use both a full sized file browser and fill sized console... all without switching applications back and forth. My active process (workflow process, not computer process) is on the left, and ever flexible Konqueror is there to help on the right.

Joseph said...

"Who uses scrollbars anyway, now that we have mouse wheels?"
Whenever I'm looking at a long page that would take half an hour to scroll through with the mouse wheel. Also, not all people are using mice as pointers. Laptops are becoming increasingly common that use touch pads instead, and their scroll behaviour can be even more tiring on long pages.

Anonymous said...

I would disagree with quite a lot of this. Fitts' law may be holding up in terms of truth, but that doesn't mean it's always applicable to any given situation. Back in '92 or so, my AmigaOS 1.3 system had dedicated resize gadgets (aka widgets). I grew up with that and was used to it, but when I X's border-resize approach, I immediately thought it was much more elegant and usable. It's not easy to click quickly, but how often do I resize a window anyway -- especially when the window manager will remember preferred app/window sizes for me?

By all means, encourage adaptation for fitts' law, but please don't apply it to everything just because you can.

scokar said...

resizing

Resizing by window edges could be greatly enhanced by having the mouse 'stick' for a definable brief pause, as well as a cursor change, as you scroll over any 'resize' control: window edge, drag corner, etc.

scokar

Anonymous said...

space between menu entries: what lead to the current behavior was a suggestion by a "usability aware" lady from osnews.com (eugenia)... I think I'm going to change it in Plastik for KDE 4

Connect labels with their respective widget: as I said on kde-core-devel, I love this idea. I'm not sure if this is the most elegant way, but I'm quite eager to hack this into KStyle using eventFilter() stuff... :)

Make the whole width of checkboxes clickable: AFAIK KStyle (4) derived styles already have the whole checkbox label clickable, while in most Qt4 styles only the area around the text label is.

Introduce a dedicated resize handle: this should be discussed in the HIG, I think.

maximized windows make scrollbars edge aware: there is the switch "QStyle::SH_ScrollView_FrameOnlyAroundContents" for styles which would solve this for many cases (only used in Qt Motif stlye, I think - I need to play with it a bit more...). better support for things like this was promised to me for Qt 4.2 but nothing came out of it.

sgiessl

Anonymous said...

On the issue of putting the focus on a text box when clicking on "its" label, this should be a one-liner in most cases even in Qt3

Something like

label->setFocusProxy(lineEdit);

Maybe the respective developers just didn't know about it or about the usability improvement they'll get

segedunum said...

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.

If this means the checkbox, text label and the horizontal 'free space' beyond the label then just don't think about doing it. It is horribly annoying, because many people do click on free space to change focus.

Anonymous said...

Use toolbar icons with text
Don't do that ! Never ! Why ?
- it takes too much screen space. Remember that what is important is the document the app is displaying, not the application
- a lot of people around the world (not in the US) uses implicit communications, which means they are more used to icons or symbols than text

So my advice : always use icons only, with a feature to activate on an application basis text under icons. Please never do this globally as some apps will never need this (konqueror), others might (kontact).

Tina Trillitzsch said...

to the anonymous person above me: "which means they are more used to icons or symbols than text" - I would be very interested in the source for that, and its significance and implications for complex interfaces.

Anonymous said...

as well as a cursor change, as you scroll over any 'resize' control: window edge, drag corner, etc.

Have you ever used a computer?

Every window system I've ever used (including KWin) already does this.

To me it makes perfectly sense to be able to make a maximized window smaller by dragging the right border to the left (we can maximize it later again). And this contradicts your idea of making scrollbars edge aware. Who uses scrollbars anyway, now that we have mouse wheels?

That is configurable. It would (or should) be a simple matter to remove the 1 pixel border around the KHTML view. Then the scrollbars would be 'edge aware' if you have true maximised windows, and almost exactly the same as before if you don't.

Anonymous said...

@Tina Trillitzsch

The source is a Iranian professor I had when I was in the University of Technology of Compiègne, in France. He is specialized in the studies of cultural differences and their consequences in the daily life. Quite interesting I thought.

Anonymous said...

Somebody listened to you: Look at this blog.

It shows the code that makes Serenity style supports click on labels to activate the corresponding widget. One step in the right direction...

Regarding Fitts' law and window resizing, I discovered today(!) that KDE offers you the widest space as possible to do it: The whole window. Just try ALT + right-click. (I'm still wondering why I never tried this although I know ALT + click to move a window.)

Florian Grässle said...

@prevous anonymous
thanks for the tip. serenity rocks (wrt to clicking labels)! :D

Anonymous said...

I totally agree with the border-beside-the-scrollbar problem. I use a tablet, and grab the scrollbar to scroll. Why oh why is that border it the edge there?

People, you should also not argue too much about "this-is-better-than-that." Better if both choices were implemented, eh? We all have different preferences. Do NOT impose your preferences upon others.