There are so many ways to design a graphical interface to a computer, one might often get lost in the process. I do at least. Thus one would like to determine a general and consistent set of guidelines for an interface.

Update: 7 September, 2005

Tog offers yet another take on Fitts’ law, and how it should be implemented in OS X. Note this article was written in 2000. Perhaps what bothers me most of all is that OS X offers no way of getting the trash can into the corner of the screen, although NeXTSTEP provided this as the default:

Note the Recycling Bin at the bottom right corner, making it easy to toss files. (photo courtesy of guidebookgallery.org)

Update: 6 September, 2005

I came across an interesting article today describing the use of Fitts’ law, that I also mention below. See Top 8 Reasons HCI is in its Stone Age. In the reader discussions following the article, two available implementations were mentioned, which take full advantage of the four corners of a screen. Symphony OS is a Linux distro. featuring the Mezzo Desktop, which assigns each screen corner to a particular way of computer interaction: computer view, program view, task view, and search view. Secondly, a new Mac OS X preference pane, called CornerClick is available. This program allows a user to assign files, folders, applications, scripts, or Exposé actions to the screen corners. Activation can be performed by mouse hovering or clicking. This implementation raises the bar over Quicksilver’s current screen corner implementation because it clearly shows the full name and icon of the target to be activated. The key and mouse gesture required for activation is also indicated. Many targets can be assigned to the same gesture, and many items can be activated from the same corner.

There are two problems with the current implementation of CornerClick. The most useful feature for me would be to use each corner as a folder drop box, such as a downloads folder, or favorites folder. As it works, the user can only open a Finder window in that folder. Secondly I would like to be able to assign one corner as the Trash can, but the ability to do this in a sense follows from the first issue. I suppose the real test of the utility of this application is whether I wind up using it. This will depend in part on whether I can remember which key commands and mouse buttons trigger which items (did command-click active my home or downloads folder?).

CornerClick shows which targets are assigned to each screen corner. cf Quicksilver’s implementation, below.

Date: 19 February, 2005

I currently run Mac OS X, and in my experience, a few actions are a bit too difficult to perform, at this time, although changes may arrive with Tiger. Obviously one would like to take advantage of Fitts’ Law, as well as the idea that the fastest way to perform an action from the mouse is through the contextual menu. Currently Apple takes minimal advantage of these two notions. The only default way to use screen edges is through Exposé or screen saver activation. While it may be nice for the former, general use of this feature is marred by false positive activation: simply moving a mouse to a corner will activate the action. Obviously Apple could implement a timing mechanism, where the mouse would have to remain in a corner for a small (1/10th second) or so before activation, or even require a mouse click. To this end, Quicksilver has recently added an action triggers ability, to assign any actions to screen edge events. What is better is the ability to customize the conditions under which the action is taken. For example, I have each of my four screen edges set up to launch one of {Finder, TextMate, Mail, Safari} upon a double click at the chosen corner.

Quicksilver edge actions: Notice a double-click at the bottom-right corner activates Mail

Notice how the edge emits a visual cue to indicate an action can occur, and a tool tip describes the action and how to invoke it. Elegant and useful. My only complaint is that there is no a priori indicator of what each edge might be set up to do; thus habituation of the actions take too long to develop.

This notion of habituation by visualization is utilized well by Apple’s implementation of the Dock. One associates an icon with an object (application, folder, or file), and thus the user instinctively knows what a click on the icon will do. However this concept is not currently coupled with either screen edges or a contextual menu event. Thus contextual menu (CM) plug-ins such as the shareware program ITTEC or Unsanity’s FruitMenu have become popular. These allow the user to right-click on the desktop or menu bar to access a customizable list of items, including applications, preferences, folders, files, and open windows. While these programs achieve their goals well, their largest issue pertains to standardization.

ITTEC allows the user to navigate folder hierarchies using a contextual menu

The default behavior of a program should be the most intuitive and useful-on-average setup: thus the major theme of Apple as a company. To be more technical: don’t overparameterize. This has been a major criticism of Linux, although in my opinion recent releases of KDE have taken care to simplify the interface details nicely. Specifically the issue with using an optional CM in OS X is expectation and consistency. Does the CM present the user with what the user would expect to see? Does the CM function identically to how the Dock’s folder hierarchies function, or are there surprises? Note I do not preclude additional features, but the basic and default behavior should be expected and consistent.

Another major issue is how to view and select open windows. Systems such as KDE and Windows adopt the "window is the application" approach, whereas Apple tends towards the hierarchical "system-applications-windows" approach. There is no clear winner here, since Apple’s approach supports modularity intrinsically, at the cost of modal behavior (ie, when you close the final window of an application, you remain in the focus of that application and do not focus on the next open window), whereas Windows and Linux take a more shotgunned approach which requires better window management at the system end and which better supports a multiple virtual desktop interface for modularity. Apple’s solution to window management is Exposé, a method of visually selecting windows. Its main disadvantage is its reliance on distinctive visual cues for each window. Users who regularly deal with visually similar windows such as Terminal windows, or ever column-view Finder windows may find it difficult to distinguish between these using Exposé. Of course Apple thoughtfully included the ability to right-click on an application’s Dock icon to textually select among open windows, but this is a modular solution, not a global one. To the rescue comes Witch, a new window switcher by Peter Maurer, the author of Butler. This utility functions analogously to Panther’s built-in Application switcher, but the items are open windows, grouped by application. Possibly one of the most anticipated features is the ability to minimize and zoom windows from the switcher, just as one can hide and quit an application from Apple’s app switcher. This utility includes already minimized windows in its list, a boon for Dock hiders.

Witch is a window switcher analogous to Apple’s built-in application switcher

In summary I don’t think there currently exists an ideal Mac OS X setup, at least not out of the box. While the Dock is a great step towards simplicity for the average user, Apple does not supply enough advanced features for the advanced user, notably a more general and better implemented edge actions feature, as well as default access to favorites and folders from a desktop activated contextual menu.

Fitts’ Law

Fitts’ Law is a distance, namely the length of a straight line from the position at which the cursor started to the closest point on the target. This law yields the average time it takes a user to get the cursor to the button, and is defined by the following: Time(msec) = a + blg(D/S+1), S is the target, D is the distance, a, b are estimated parameters. Jef Raskin suggests a = 50, b = 150 (from "The Humane Interface", by Jef Raskin, p93).