 |
|
Fitts' law is one thing that most of those who have to design an UI don't know about. This is not always a problem. Fitts' law is a mathematical model, so knowing it entirely is close to useless. Knowing the principles that arise from it are the really good ones. Nevertheless, for the sake of complexity, I'll make a quick run through the math behind it. If you hate math, don't need it or really don't care about the mathematical analysis of corners, skip this. Actually take it as a friendly advice and skip it unless you're just curious.
Fitts' law describes, in essence, the time needed for a human to perform a certain move. The move is supposed to be aimed and quick. In other words, it has a target and, ideally, it must be performed as quickly as possible. Put in one of its common mathematical forms, it resembles Shannon's theorem. Actually this is called the Shannon formulation.
Mt = a + b log2(frac (D, W) + 1),
where Mt is the (average) time needed to complete the movement. a and b are constants that can be determined by drawing a straight line to the measured data. D is the distance from the starting point to the center of the target, and W is the width of the target measured along the axis of motion. Empirically, we can consider W to be the allowed error of the movement so that it still hits the target, but not in the center. W should be in the interval [ - frac (width, 2), + frac (width, 2)], where width represents (guess what...) the target's width.
This formulation obviously describes a tradeoff between the time and the width of the target. Empirically, we can realize that the bigger W is, the smaller will the movement time be, while a bigger distance increases the movement time. We can also point out some obvious things:
Fitts' law has been facing some undermines, since it normally reffers only to one-dimensional movements. However, it has been expanded for two-dimensional moves by the Accot-Zhai steering law. I will not cover it in here though, since I am not covering Fitts' law entirely in fact. Fitts' law also fails to address some issues (colors for example), but we can empirically guess some implications of these “issues”. Another argument is that Fitts' law describes untrained movements, not movements with several years or months of practice behind. We will talk about this, too.
Despite these counter-arguments, even reffering to Fitts' law in its non-expanded, strict formulation, we can still conclude that:
Do note that these are not universal rules. Some UIs apply them, but in such a poor way that they are rendered useless.
I will start with corners because, despite being the most easy to touch (and least attention-drawing) parts of the screen, many UIs fail to use them as they should.
We can say that corners are infinite targets because no matter how much you would move your mouse past two edges, you simply can't go outside. That means their actual width is infinite.
Even more, corners are at the intersection of two other infite targets. This makes them even easier to acquire.
Corners don't apply only to screen edges. Window corners are also easy to acquire when the mouse pointer is inside a window.
Since corners are so easy to acquire, they should be used for the most frequent actions that can be done on the desktop. These include pull-down menus for starting applications, thrash cans for dragging objects to, common desktop-related function (show desktop, switch desktop) and so on. A special use of the corners is attracting the icons on the desktop. NeXTStep and the NeXT-like interfaces do this and I will cover it here.
Gnome is a desktop environment for X11. While Gnome itself is an environment in the broad sense of the word (it includes its own suite of pograms), it is more commonly identified with the desktop-managing part of it. This is why, from now on, I will do that too, mostly to avoid cluttering too many words.
Gnome has one central part – the Gnome Panels. A Panel is, at the surface, close to the Windows Taskbar, only it's more configurable. You can have as many such panels on the screen as you want, as long as there is at least one out there.
Various functions can be added on the panel. For instance, you can add a Show Desktop button on the panel. This button will minimize all windows when it's pressed.
You can position this button straight in a corner of the screen. It's enough to position the panel to one of the edges, then move it to the edge of the panel. Now, no matter how much you will move the button further from that corner, you will be able to press the button. This may not seem much, but the Gnome Panel resolves two issues that others don't. I will explain one of them immediately. The other one is related to the fact that you can resize the panel until its size is just big enough to contain the button, not taking up a whole edge. And I will discuss that, too.
When Microsoft released Windows 95, they presented the Start button as a great innovation. Those who laughed at that weren't few. Mac users have had it since the first release, and many people out there found it rather ironic that you have to click Start in order to shut down your computer.
There is also one catch about this Start button. While its placement might seem perfectly fine (it's in the corner after all), it's not. The UI designers magically considered that there should be a small space between the Start button and the edges of the screen (see Figure 2). This means that the Start button is not in the corner, it's one pixel away from the edges. Besides, placing it at the bottom of the screen also means that it's even easier to move your mouse way past it (you can move the cursor “under” the bottom edge of the screen). Clicking on the very edge of the screen has simply no effect at all. This renders placing it close the corner almost useless.
BeOS is a slightly less-known Operating System. I won't go into any details about it, but if you want to learn more, have a look at the Resources section.
BeOS features its own Start-like menu. It is placed in the upper-right corner of the screen and doesn't have the pixel-related problems found in Windows. The only problem is, it's badly placed.
Clicking the Start-like button will launch a pull-down menu, with a few submenus. However, since there is no space left, despite the fact that arrows show the submenu will be opened at the right of its parent, it really gets open at the left. This makes it hard for the user to choose an option because one move above or under the parent closes down the submenu and, in order to get it back, you must hover your mouse over the parent again. This option is even more weird, as the rest of the interface is pretty well designed and BeOS doesn't support any languages like Arabian, where people read right-to-left. The lesson here? Place them in corners, but choose the corners.
The reason why window decorations are in the corner has less to do with Fitts' law and more with the way our brain sees objects, and the window as an UI concept in general. Basically, windows should present contents, so window manipulation widgets should be on the edges of it, and corners are intuitively easier to find. Why am I talking about this here? Because we're still talking about corners and Fitts' law.
Many interface choose simple decorations for this reason. NeXTStep interface, for example, has only two buttons: a Close button and a Minimize button.
 |
You can get a window menu by right-clicking the titlebar. The menu offers a wider range of functions for that window.
Other UIs have a different choice: the window menu can be pulled down using a button at the right of the screen. Most Motif environments do so.
|
Figure 5. Titlebar used by mwm (the Motif Window
Manager) and the window options menu
|
What's the problem with these you may ask?
First of all, the Close function is the one most users would want to access, since they can already maximize, minimize, restore, move and resize the window using the icons on the desktop or other widgets on the window. However, Close is always the last option, not just in mwm, but in quite about all such menus. The time needed to point at it is the largest out there. Besides that, the menu goes over the text.
Well, PieWM is a window manager quite close to the better solution. PieWM uses pie menus.
Unfortunately, PieWM doesn't quite get it right either, because the menu is in another window, while it's true best application would be as a popup menu. Why? Because, when popped up, all items are equally distanced from the center which is the current pointer location, and that is the instant target. A pie menu popped up as the window operations menu would be the ideal solution. Unfortunately, I'm unaware of any implementation that does this, and PieWM is rather old.
Screen corners have just one slight problem: except for the case when they are obviously integrated into something (like the Amiga or Mac OS menu bar), they should not contain any functions that are particular to a single sittuation. In other words, if you write the next window-based text editor, don't put the Save button in a corner just because everyone can use it: it will be annoying and will probably go unnoticed as well. Screen corners are for functions that can be accessed all the time and in most sittuations, so it should stay that way.
The four edges of the screen can also be considered infinite targets. However, we must make a clever distinction here: yes, screen edges are infinite targets, but not everything on a screen edge is an infinite target. In other words, a button on the edge is not an infinite target.
However, items placed on the edge of the screen are easier to acquire because there are less ways to miss them. In fact, as you can see in Figure 7, there are some cases when they can't be missed at all.
The principle above is used by the NeXTStep interface.
You can think of the screen as if it was a window. Actually, X11, the dominant Unix window environment, defines one window as the root window. This is the first and omnipresent window that is as big as the screen (or, if you choose to use X11's virtual screen option, as big as the virtual screen). So many of the principles about windows apply here as well: the most important information should be in the middle, where the user's attention is, and the background information and specific function-performing widgets should go at the edges.
The edges of the screen are (fortunately) straight. This means that tidying information along them is pretty easy, and no, they do not require any sort of supplimentary bars along them. So in case you thought I'd give a few bad words about the Windows taskbar, yes, you're right. It's the next worst idea after the browser-shell hybrid.
I am not going to go into much detail about NeXTStep either. I have provided some links in the Resources section for those interested in more than just its GUI.
The interesting thing in our talk is the dock. What is the dock?
The Dock is the trail of icons on the right. Icons on the right are used to launch various applications. You can see that there is another set of icons at the bottom-left of the screen. All running applications have one of those. They represent the task, and if an application has multiple minimized windows, they are present there as well, along with the window title. A double-click on one of these icons will un-minimize the window if minimized. The icons down there can be dragged around as you wish, so you can easily re-arrange them if needed.
You can also see a greenish icon in the bottom-right. That's the Recycle Bin. You should already be able to tell if it's placed well.
In this case, the Dock is very easy to use. Not just because Fitts' law says so. There is one more thing in there.
It's called spatial positioning. And the easiest example I can give is the one on your keyboard. If you are a fast typer, you are one because you already know where each key is. When you want to type the 'a' character, you no longer have to look at the keyboard, compare each key with your mental image of the 'a' character so you can type it. You already know where it is. The NeXTStep interface allows the same thing: instead of making you run through menus or selecting an application from a window, after a few launches you already know where you need to point and double-click to launch an application. Funnily enough, the fact that there are no written names on the dock, just icons, contributes to this. Image and shape recognition is something we are almost born with, reading is something which we have a harder time to learn, and those with visual problems will have more trouble reading a small name than learning how a 64x64 pixel icon looks like.
There are a few catches with these design, but they don't get in the way of this interface incredible ease of use and consistency. First of all, maximized windows will be 64 pixels shorter than the screen's full capacity, both horizontally and vertically. This is a small disadvantage though, because NeXTStep uses a global, vertical menu so you will rarely maximize the windows anyway. This saves a lot of screen space. Not only the dock is saving it, but above all, the window and application icons you saw at the bottom-left. When there is no task running, no space is taken down there. So the task list doesn't use more space than it needs. The second disadvantage is that if an application's icon is not descriptive enough, you may not be able to identify it. It's why NeXTStep has some of the best icons and each application defines its own, standard icon, so that it won't have different icons on different systems.
Trouble is, you may ask, what do you do with shortcuts to files? They would all look the same, wouldn't they? Well, yes, they would, but for some reason nobody complained about it. Actually I don't remember seeing anyone who used them in NeXTStep, and, to be honest, since I don't own a NeXTStep (I would buy one if transport taxes would be decent at least), I don't even know if you can do that. What I do know is that this is a major problem of the Mac OS X dock.
Something close to the NeXT dock (but not as efficient) is the on that can be found in QNX. However, QNX uses a “hierarchy” of dock buttons (a button can be clicked to vertically expand a wider range of buttons) and there is also text on them.
Adding text underneath a button's icon is normally a good thing, because it makes it bigger. However, the QNX buttons are very thin. Not only does it make it harder to learn a button's location (due to expanding buttons you never know what button is in a place anyway), but they also seem smaller and are harder to hit.
Trying to write about the window taskbar is a very difficult task for me. You probably got used to my sarcasm and jokes when staying technical, but this time it's different. There are so many bad things about this taskbar that I risk turning this essay into an anti-taskbar paper.
The first big problem of the taskbar is its utter waste of screen space. In Figure 9 you can see the taskbar with just one, singe task. While in Windows XP, the UI designers seem to have solved the pixel-margin-related problem, they still haven't solved another one: in the case above, more than half of the space taken by the taskbar is wasted. There is no task to display on it, no clock or system tray, no menu or applet, nothing. Still, the remaining space cannot be used for anything. Even if you can (sometimes) leave a window over it, the first click anywhere on the taskbar will bring the taskbar up, over that window.
To solve this problem, Microsoft's UI designer came up with a solution. Auto-hiding the taskbar. If the taskbar is not used, it will hide itself, and hovering the mouse close enough to the edge will bring it up. Unfortunately, this is even more inefficient, for two reasons. First of all, since the taskbar is hidden, if the user wants to click on window's entry in the taskbar to bring it up, he has no idea where that entry is placed on the taskbar. So he will have to move his mouse not only to bring up the taskbar, but also to click on the entry he wants after the taskbar is visible. The second reason is that the space still can't be used for much: hovering the mouse over it will bring up the taskbar. This leads to almost hilarious sittuations when the user can't reach a window's resize widget (bottom-right corner) because it's immediately covered by the taskbar.
Ironically enough, some X11 windowing environments like KDE or Gnome have been featuring an auto-expanding panel (one that expands with the number of task entries on it) for years now. However, not even these can solve another problem of the taskbar.
On the NeXTStep, icons describing a task are fixed-size and, despite taking up a small horizontal space, they are very descriptive. The taskbar can fit four or five entries in best cases, but after that, things start to go wrong. Since they don't fit anymore, entries start to be resized. And things can go even more wrong than the hell you can see in Figure 11.
This certainly isn't helping those with visual problems anymore. Not only is the text impossible to read (it's truncated to two or three letters anyway), and the icons are so small that they are as unhelpful as the text. Various attempts at changing this has been made (allowing the taskbar to be enlarged so that more icons cand fit, grouping windows of the same application in a single entry, usage of virtual desktops using 3rd party applications) but all these efforts have not made the taskbar more efficient. The usage of such a plainly wrong design is even more weird since older Windows version have used NeXT-like icons with great success. The fact that the taskbar isn't placed at the top (where it could be an infinite target) is also a mistery: the top of the screen isn't occupied anyway, and placing it at the bottom make the Start menu the only menu unfolding towards the top instead of unfolding towards the bottom of the screen.
Mac OS and Amiga OS use a slight variation about the top of the screen. No windows have menu bars. There is only one menu bar on the screen, the one of the active window.
Fitts' law is categorical about this: the top-screen menubar is easiest to reach, simply because it's an infinite target. There is simply no way a Mac user could miss it, he just has to throw his mouse towards his screen. Acquiring a menu item in a menu bar from an individual window is rather difficult to do.
However, there are a few arguments against this today. The single most disturbing problem is the one when there are more windows on the screen. One argument is that if there are five or six windows on the screen, it is difficult to see what window holds the current menu. This was the case in older Mac OS versions. Today, it's not a problem, due to the impression of depht given by certain effects (especially shadows under windows). In fact, the menubar-in-window principle is more problematic in the Unix world, where it is not uncommon for a window to hold menubar with functions that affect another window.
The edges are periferic by their very definition. It is why critical or otherways important messages should not be displayed there. However, usage must be very careful because it's very easy to waste the screen space (see the windows taskbar example).
The edges shouldn't be used for delimitation of virtual desktops. This is a common problem in the case of some X11 window managers, where we also get hilarious sittuations when the user can't reach a resize handle because he immediately goes to the next workspace.
Edges are fine for displaying non-critical information though. Clocks, calendards, news scrollers and other such things may fit well there.
http://www.x.org , home of the Xorg, a widely-used implementation of the X11 protocol
http://www.xfree.org , home of XFree, the traditional X11 implementation
http://www.gnome.org , one of the widely used desktop environments for X11. Licensed under GPL.
http://www.crynwr.com/piewm/, home of PieWM, a window manager with pie menus. Pretty archaic and it will probably be of interest to you only for the pie menu.
http://www120.pair.com/mccarthy/nextstep/intro.htmld/ , a quick introduction to the NeXTStep environment
http://www.gnustep.org/ , a free (as in beer) re-implementation of the NeXTStep API
http://www.windowmaker.org/ , a X11 window manager resembling the NeXTStep environment
http://www.afterstep.org/ , another window manager, derived from fvwm and bowman. Unlike bowman (no longer available anywhere but from dedicated mirrors, drop me an email if you cannot find it) and WindowMaker, it doesn't aim only to imitate the NeXTStep environment, but also to add new features. And it's quite sucessfull, too.
http://www.bebits.com/ , a repository of BeOS software. The wiki on the website may be of more interest to you if you never used BeOS.
http://www.qnx.com/ , homepage of the QNX operating system.
http://www.amiga.com/amigaos/ , the Amiga OS homepage. Believe it or not, the Amiga is still quite alive.
