What follows is the introduction from Cocoa Pie Menu Implementation [pdf], a paper written for 05-631 Software Architectures for User Interfaces as taught by Jason Hong:

Fitts’s Law tells us that the time to target an object on a screen using a mouse or similar input device is a function of both the size of the object and the distance to do that object. The Macintosh operating system as well as its predecessors have exploited this: The main menu was placed such that the items could be selected at the absolute top edge of the screen. This gives the menu items an essentially infinite size in one direction, allowing for easy selection by a flick of the mouse in the general direction of the item. Thus, the menu item is easier to select and can be selected much faster.

Linear menu items are almost the antithesis of an exploitation of Fitts’s Law. All of the items are the same size, and they are all laid out in the same direction. The only difference selection-wise between one item and another is the exact amount of distance traveled, which comes down to item height (the smallest of the two dimensions of a linear menu item).

In a pie menu, each menu item is a slice of a circle. When the menu is brought up the cursor is at the center of the circle. Clicking in the center dismisses the menu. With this design, each menu item differs from the other by actual direction. Distance is the same to each menu, but since each pie slice is in a different direction, the user only has to move the mouse in the direction of the item. This sounds good in theory and it bears out in practice: Users can select items from pie menus faster than they can select items from linear menus.

In theory users can also learn pie menus better and faster than linear menus. It should be easier for users to proceduralize and remember a simple physical direction than an order in a uniform list.

While pie menus may have many advantages, they are not particularly common in real world applications. A lack of pie menu libraries in the most common user interface toolkits does not help. I therefore decided to implement a pie menu in Cocoa, Apple’s toolkit for Mac OS X, which I will release as a Framework (a relocatable dynamic library for Mac OS X). The goal is to eventually be able to replace the contextual menus in mainstream applications such as Safari or Mail. Third parties could also make use of the Framework in their own applications.

Ignoring the cognitive science debate about which model of temporal attention is correct, I concluded:

The progress bar increases attention to the internal clock, causing a greater accumulation of time pulses, which means a more accurate perception of how much time has elapsed. Without the progress bar, the participant is attending to the concurrent task quite a bit more and does not accumulate as many time pulses. …

It is clear, though, that the lack of progress bar does cause an underestimation of time for the 5-second duration. While current models predict this, it is a somewhat counterintuitive result and has interesting applications for computer interface designers—progress bars should be left out if the task is 5 seconds long (and perhaps less).

It was nice to find, via Coding Horror (and there via FriendFeed), that Chris Harrison of the HCII along with others have done more extensive research [pdf] in a paper published in UIST’07. They did not look at different durations like Daniel and I did, but they did further investigate different types of progress bars. Basically, pauses and hiccups in progress bars cause users to believe something is taking longer:

However, progress bars with dynamic completion conditions and roughly estimated durations (e.g., defragmenting a hard drive) can be augmented in two significant ways. First, since users seem to have a strong aversion to pauses especially towards the end of an operation, progress bars can be designed to compensate for this behavior. An intelligent progress bar can cache progress when the operation is first starting to mitigate negative progress behaviors (e.g., pauses or slow-downs) later on. Secondly, progress can be downplayed in the beginning and accelerated towards the end, providing a sense of a rapid conclusion that is highly favored by users in our experiment.

I think it's important to understand the effects that progress bars have on people's perception of task duration. We spend an awful lot of time staring at progress bars waiting for things to finish—designers should be aware that they have the means to make these waits feel as smooth as possible. For short tasks—a threshold somewhere between 5 and 10 seconds—the appropriate choice is no progress bar at all. For longer tasks, one should be trying to start that progress bar as early as possible and keep it running smoothly. I hope we see more work along these lines.