Log in

No account? Create an account
Fitt's law and GNOME - Arvind Narayanan's journal [entries|archive|friends|userinfo]

Fitt's law and GNOME [Jun. 16th, 2004|12:51 am]
Arvind Narayanan
[Tags|, , ]

A while back I wrote about why Fitt's law is important, and ended with the question, "So how does GNOME stack up?". I'll try to answer that question now.

What are the components that need to be Fitt's law aware? Clearly the panel, as it occupies screen edges. Metacity too, since window borders are often aligned to edges. Gtk+, for it draws most of the widgets. And individual apps, at times.

The panel is mostly perfect. There's no gap with the screen edge, and you can activate launchers or any other panel item by throwing the mouse. I believe the default of having two panels was made in order to make better utilization of edges. I think this is a great idea, although I'm a bit worried that having 2 panels means your icons are smaller (36 pixels instead of 48) and therefore more difficult to get at. And the hide buttons are not present by default, which is also great: you can activate the start menu by throwing the mouse SouthWest.

Gotta say that the panel beats the pants off Windows: not only is the Windows taskbar rudiculously short (24 pixels!) and hence more difficult to click on, it encourages the approach of putting application shortcuts on the desktop where its hidden from view and you have to minimize all your windows just to get at them.

There's one panel bug related to Fitt's law I've run into (not confirmed), but its an implementation bug not a design bug.

Metacity does pretty well too. The most basic thing is that windows shouldn't have borders when maximized so that apps can put their widgets on the screen edges, and this issue has been taken care of long back. Another major thing is that the minimize/maximize/close buttons should extend to the top edge of the screen when the window is maximized. The close button, in particular, should extend to the top right corner. Apparently this is a theme issue, and metacity is not at fault. Theoretically metacity could override theme behavior when the window is maximized, but workarounds instead of fixes is poor software engineering. A patch for Simple already exists, and someone needs to make patches for other themes or request their authors to fix them.

Another Fitt's law issue is that the titlebar should be big, but that's again a theme issue. The problem is that the minimize/maximize/close buttons aren't big enough. Windows XP solves this by making the titlebar really big -- 36 pixels I believe (the titlebar, with 5 UI elements, is 50% taller than the taskbar, which has over a dozen. What were these guys thinking!!).

Now I'm going to make a bit of a controversial suggestion. The minimize/maximize/close buttons should be made rectangular, i.e, wider. I know you're screaming "ugly!!", but hear me out. These are important buttons which should be easier to click. I often find myself often hitting close instead of maximize, and I imagine others do too. There was one theme in KDE 2.x (don't remember the name) which used wider buttons, and it didn't look too bad at all. A 2x ratio should look pretty decent. And its just a matter of getting used to anyway.

OK, on to gtk. Many of the widgets seem to be bigger in 2.x than in 1.x, so that's good. I don't know if its entirely a theme issue or gtk has anything to do with it, but in any case there's nothing to complain about. The only other thing that gtk could/should do is to make it possible for apps to put stuff at the edges if they want to do so. I don't think it currently lets you put a toolbar at the left edge, because there are borders around buttons which you can't choose to not have. But then the HIG lets you have vertical toolbars only in exceptional situations, so it isn't that big of a deal. The only other widget is the scrollbar. Fitt's law is particularly important for a scrollbar, IMHO, because it lets you do your work without taking your eyes off what you're doing (as opposed to, say, the close button, in which case you'd be taking your eyes off what you're doing anyway). Mozilla's scrollbar is already right aligned, so gtk isn't preventing you. On the other hand gtknotebook has a frame which it doesn't let you hide if there's more than one tab, so if the scrollbar is inside a notebook there's a problem. At least that's what I've been able to figure out. Unfortunately that bug has been RESOLVED NOTABUG, and I don't know why. Maybe I'm missing something, and if someone knows I'd be glad if you could tell me.

Individual apps: I haven't found any app other than mozilla/firefox in which the scrollbar works correctly when maximized. Perhaps what's surprising is that it does work in mozilla. I mean, how many developers have heard of Fitt's law anyway? I certainly hadn't until a few weeks ago. It would be great if the HIG made a mention of it.

OK, that's it for now. I'll be filing more bugs if I can think of anything else :)

From: (Anonymous)
2004-06-17 04:45 am (UTC)

Have you tried to contact hig@gnome.org, or usability@gnome.org?

As seen in the feedback section at the Gnome HIG page (http://developer.gnome.org/projects/gup/hig/)
(Reply) (Thread)
[User Picture]From: arvindn
2004-06-17 10:03 pm (UTC)

Re: Have you tried to contact hig@gnome.org, or usability@gnome.org?

Thanks for the suggestion, I'll do that.
(Reply) (Parent) (Thread)
From: (Anonymous)
2004-06-17 06:03 am (UTC)
If you're having trouble hitting the window borders in Metacity, try using Alt-space x to maximize/minimize instead of moving the cursor.

The old Fitt's law maxim about "the five easiest points to select" being the corners and current cursor position is bogus if your hands happen to be on the keyboard and not the mouse - in that case the space bar takes the cake.
(Reply) (Thread)
From: (Anonymous)
2004-09-20 11:24 am (UTC)


Obviously Fitt's "five mouse points" law doesn't apply to keyboarders much like the speed limit doesn't apply to pedestrians.
(Reply) (Parent) (Thread)
From: (Anonymous)
2004-06-19 08:23 am (UTC)

Titlebar button

Just a thought on the rectangular buttons, make them
the golden ratio(1.61803...) wider, instead of 2x. Looks
(Reply) (Thread)
From: (Anonymous)
2004-06-19 05:25 pm (UTC)
been reading asktog recently ;o)

and a note to the keyboard guy. of course none of the corners are easily reached when your hands are on the keyboard... fitts law applies to mouse interaction.
(Reply) (Thread)
From: (Anonymous)
2004-06-24 01:41 am (UTC)



Great article, I really enjoy learning more about usability.

How does the GIMP 2 fare in terms of Fitt's Law? We have limitations, mostly due to GTK+, but I'm sure that there are several things we can do better. I was interested in the comment on the asktog page that said that toolboxes should not have borders and be on the screen edge, not sure how we could do that.

Any general usability comments on the GIMP?

(Reply) (Thread)
From: (Anonymous)
2004-06-24 07:17 am (UTC)

Rectangular window buttons

Interesting reading. On the specific subject of metacity's ( or any
other similar WM's ) buttons, I am not sure that rectangular buttons
are really the way to go.
Preamble: I am in no way an UI expert. I work in IT, but I have no formal
education on the subject. I recently produced a few themes for gtk/metacity
and that led me to thinking about the issue and reading about Fitt's law
and, more in general, usability studies.

Fitt's law must be applied cum grano salis for two reasons
a) it is formulated for an unidimensional acquisition of a target
b) it doesnt take into account the price of errors

a) there were studies about generalization of Fitt's law to 2-D (or even
higher dimensional) environments. The main point was finding which function
of the dimensions of the target had to be used instead of the "width"
in the original formula. Statistically the best fit was for the "least
side" case, ie the formula holds well if you use as "effective width" the
lesser between width and height of your target.
(see http://jheer.org/blog/archives/000064.html )
In our case this means that having very wide buttons without increasing
height wont make the target more easy to acquire.

b) Fitt's law is about the time needed in aquiring a target. Your user
will sometimes click _before_ exactly acquiring the target. If the target
is an isolated button that is not too bad, but in the case of the
windows' buttons this can lead to clicking the wrong button.
Being one of the actions (close) usually irreversible, this can be very
annoying. It would be much better if we could isolate the close button
with a buffer inactive space, but in metacity this is only possible by
padding all buttons.
Having the user target an horizontally wider button will probably lead
to a "sloppy" approach (goggle for "bubble fitt" to see this happening
in tests with dynamically sized targets) in which the user is more
careless about the horizontal position of the pointer, thus the
distribution of clicks will probably widen, and the need for padding
spaces due to the close button will arise even more, thus needing even
more horizontal space.
After reasoning on these lines, for my themes I chose to trick the user
a little. I used wide buttons, with some inactive padding between them.
But graphically the button is smaller than the "real" active width (in
my case it is graphically square/round). The idea is that the user will
aim for the graphic, thus keeping hopefully a not-too-wide bell
distribution. Even acquisitions that are slightly off-target on the left
and the right will prelight the button, giving the user the required
feedback to have her click.
Move too much away and you fall into an inactive padding, avoiding mis-clicks.
It's true that the smaller graphic target might make you think that
Fitt's law will make this acquisition slower, but as soon as the pointer
enters the active area, the button prelights, and the user stops
adjusting, so that's not the same as using small buttons.
Well, enough subjective rambling for now :)

(Reply) (Thread)