Interaction Serenity

Just unpacked yesterday: Logitech Z-5500 Digital speakers. I’ve been looking to go toward digital connections for my sound for quite some time and these were part of a decent sale on Amazon last month. I was hoping to go with a receiver and some box speakers, but my issues with the state of receivers with multiple HDMI inputs could fill another article.

The device pictured to the left (click to enlarge) is the Control Panel. It functions as the center of the speakers: audio input connects to it, it controls power, and it features an IR receiver for remote control.

Like everything in the massive Z-5500 box, the Control Panel is quite large; taller than a Wii standing up. On this large Control Panel is a large blue-backlit LCD display. Most of the time this simply displays the input cable type and the signal processing that will be done on that input. When I change volume or other settings, the display switches to display that information. After a few seconds, the display reverts to the default information.

The backlight, however, remains on. Here we are with a device that is by its very design going to be sitting near the center of my entertainment system and it is going to constantly glow blue. Always. Yes, the power button glows a very bright blue, but the display itself is quite sizable. When I have all of my lights off, attempting to play a dimly-lit game or watch a movie, I have this giant glowing blue area staring me in the face.

The information display is entirely transient. I do not care which input is currently being used after I have selected the correct one.

The design solution is simple: simply turn off the backlight after several seconds of inactivity. Turn it on briefly when something changes. Information I do not need should be invisible.

This is the first in a series of articles which will simply be blog versions of sections of papers I wrote in university. I hope to follow up with some more recent information, but for the time being, at least things will be more easily Google-able than just large PDFs!

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.

As part of my undergraduate coursework, I put together a small study with Daniel Dickison to look at the effects of progress bar speed on apparent task duration. It was just for an experiment design class, so it wasn't published, but I have the poster [pdf] and the paper [pdf] up on the web for the curious.

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.