Modes and the user interfaceSoftware engineers should not fall into the trap of assuming the general population is as comfortable with modes as the typical engineer is.
Software designers are very familiar with the concept of modes. They regularly use them in software design, often drawing finite state machines to illustrate transitions between the modes used by the software. Only a small subset of the modes that software implements are visible to the user. These "visible" modes become part of the design of the user interface, which is a distinct element from the software design. Software engineers should not fall into the trap of assuming the users of the devices are as comfortable with modes as the typical engineer is. In this article we'll look at ways to reduce the use of modes in the user interface and how to establish which modes are advantageous to the user and which ones are disadvantageous.
Making modes obvious
Modes have a bad reputation with some user interface designers, a reputation earned by the many user interfaces that make terrible use of modes. My microwave oven has a grill mode and a microwave mode. I have often walked up to it, inserted some food, and turned it on for five minutes, only to realize later that I had the cooker in grill mode rather than microwave mode. The problem is not with the modes themselves, which are often necessary, but with the mechanism for informing the user of the current mode. Sometimes the clue is quite small and easy to overlook. My VCR has a play mode and a record mode. There is never any confusion, because the word PLAY or RECORD appears on the large one-line text display when one of those modes is active. So little other information is presented that I can not overlook this visual clue.
A classic example of making modes obvious to the user is exploited by most drawing packages. Drawing applications have different modes for filling, cutting, drawing lines, and a range of other adjustments. By changing the shape of the mouse cursor to reflect that mode, as shown in Figure 1, the user is unlikely to forget the current mode.
Figure 1: The mouse cursor is shown as a hand icon to indicate the current mode
Physical mode changes
Sometimes when a user switches modes, the device makes no explicit mode change. For example, a PC user might switch from using the keyboard to the mouse. The PC application doesn't need to take any special action when this mode change occurs. However the user has to make a physical movement to implement the change. An application that forces the user to often make this type of mode change will be more difficult to use than one that allows the user to switch less frequently. It's often impossible to limit use to one of these input devices, but you can reduce the number of times the user has to transition from one to the other.
Another example of a user mode change is when a cell-phone user switches from listening mode to key-entry mode. In a normal phone call, the number is dialed at the beginning and the user places the handset to his ear to conduct a conversation. However if the caller is accessing an interactive voice response (IVR) system he may regularly have to switch from listening to the automated voice to pressing a button on the keypad to select an option for the menu. On a cell phone this usually means moving the handset away from the user's head to access the keys. This setup is disadvantageous because the user can no longer hear the instructions. Physically separate handsets and keypads, as found on a conventional landline phone, would solve this problem.
Without control of the user's physical configuration we can still use our understanding of the mode changes to improve the interface. If the user presses a key and the following prompt starts immediately then the user may miss one or two words by the time he has replaced the handset to his ear. A short pause, or checking the prompts to ensure that the first word or two are not crucial will give the user time to make his mode change.
Whose problem is it?
Modes that map to the current user activity work well. My digital camera has a shooting mode for taking photographs and a playback mode for reviewing them. This makes sense because each mode maps to a specific user activity.
Figure 2: The yellow 2nd function key implements a shift mode
Modes that only exist to solve the designer's problems are usually bad for the user. My scientific calculator, seen in Figure 2, fails to map modes to activities. It has a yellow function key that gives access to the second function on a number of the keys. This yellow-function mode exists because the calculator has too few keys (or maybe too many functions). The mode does not map to my activity, and there's no obvious boundary between the functions that require the yellow-function key and the ones that are directly accessible.
A graphical embedded system often has a small number of screens to which the user can navigate. If each screen maps to the user's current mode, choosing which features belong on which screens falls into place naturally.
Consider the application of an automated syringe. These devices are used in laboratories to control how much solution is added to a mixture. The user configures the rate at which the plunger on the syringe will drive out the solution and the total volume to be delivered. The syringe has screens for activities such as calibration and cleaning of the device. Let's look at the screen that allows control of the plunger. Figure 3 shows a screen that allows the plunger to be moved forward or backward to fill or empty the syringe. The double arrow buttons allow the plunger to be moved at a faster speed.
Figure 3: A single screen to control filling and emptying the syringe
This screen is used for two activities: filling the syringe and delivering the solution. The user would explicitly change modes from one activity to the other by disconnecting the vial that provided the solution to fill the syringe and connecting the tube that leads to the container where the experiment takes place. Now that we've established that the user has two distinct modes of activity, we can improve the interface by creating a screen for each of those two modes. Each screen will be devoted to one mode, rather than having one screen that tries to suit more than one situation.
Figure 4A shows a screen that's only used for filling. The user does not care what rate the solution is drawn into the syringe so speed of the plunger is not variable. Since the user knows what volume he wants, we allow the user to pick this value and press a single button to set the activity in motion. The user doesn't have to watch the volume indicator and stop the syringe, because it has already been directed to stop at 100ml.
Figure 4B shows the screen used to deliver the solution. In this case we allow the rate to be set, since this could heavily impact the results of the experiment. While emptying the syringe the user isn't interested in the maximum volume that the syringe could hold and so the Max Vol field is not shown on this screen.
Figure 4a: This screen is dedicated to the task of filling the syringe
Figure 4b: This screen is only used while delivering
A number of other features fall neatly into place if the screens we design match the modes or activities of the user. For example the device may need to prompt the user to ensure that the syringe is connected in a particular way. If the device doesn't know whether the user is about to start filling or delivering, it may be difficult to give appropriate instructions.
Having more screens means more navigation. However if the screen changes match the user's mode changes, such as switching from filling the syringe to delivering, then the navigation of the GUI will become intuitive. In some cases navigation can be automated. For example, if the device can detect when a vial has been inserted, it could automatically present the filling screen.
The key to discovering the appropriate screens is to analyze the tasks early in the design. Establish a list of the activities and goals of the user. This list should be independent of the design of the device that's going to help achieve those goals. This independence enables you to identify the user's modes and use them to establish the modes or screens that are appropriate for the device.
Some designs can be simplified to remove the need for modes. An everyday device that incorporates two modes is the digital clock. Consider a simple clock that tells the time and doesn't have an alarm. We expect to see a running mode and a setting mode. The clock spends most of its time in running mode, but must be switched to setting mode when we want to change the time on the clock, say after plugging it in or when daylight savings time starts. Figure 5A shows such a clock. The Set button transitions to setting mode whereupon the digits will flash. Flashing is used to make the mode obvious, as discussed earlier. The Advance button moves the time forward once you are in setting mode. When the change is complete the Set button is used to revert to running mode, then the clock simply displays the time.
Figure 5a: A clock with a running mode and a setting mode
Figure 5b: A modeless clock, that can be adjusted at any time
We can eliminate modes in this design by having a single mode that displays the time and allows it to be altered. The + and - keys that adjust the time forward or backward could function at any time, as shown in Figure 5B. Because you no longer need a button to change the mode, we can provide a way of going backward as well as forward, for the same number of buttons. Alternatively we could have reduced this to a one-button design.
The moral of these examples is that modes are often not required. Eliminating them can lead to a design that's both easier and more flexible to use.
The same principle can be applied to more complex designs. Consider a handheld stopwatch, as shown in Figure 6A, with a Start/Stop button at the thumb, a Lap/Split/Reset button at the first finger position and a mode button in the middle. The two modes are "lap timing" and "split timing." In split-timing mode the Lap/Split/Reset button causes the time to freeze, until that button is pressed again to allow the count to continue. In lap-timing mode, pressing the Lap/Split/Reset button, while running, causes the time displayed to freeze, but the timer restarts from zero to time the next lap. This allows the user to see the time of a single lap, as distinct from the total time of the race so far. The Lap/Split/Reset button performs the reset-to-zero function when the timer has been stopped using the Start/Stop button.
Figure 6a: A stopwatch with Split mode and Lap mode
Figure 6b: A modeless stopwatch: the user can choose Split or Lap while the race is in progress
To use the watch properly, the user has to be sure that he is in the right mode. The design, however, could be made modeless. If the mode button were replaced with a Lap button, as shown in Figure 6B, the left-most button could retain the split-time functionality. Split and lap features are now on separate buttons so both can be accessed at the same time, and we no longer need separate modes for each. The device still would have only three buttons, and the user could access both the lap feature and split feature during the same race. Also the user could decide which feature he wants after the race has started, rather than having to choose a mode in advance.
Smile for the camera
In other cases, modes can simply vanish without requiring a new user interaction. My digital camera has a macro mode that allows the camera to focus on objects between 10 and 30cm from the lens. The user is required to select this mode by pressing a button with a tulip icon.
The user should change to macro mode when the object in front of the camera is less than 30cm away, but there's no reason why the camera can't change modes automatically. The auto-focus mechanism must establish distance from the subject in order to focus on it, so the camera has all of the information it needs. If the mode change were automatic there would be no need to indicate it to the user. The camera now has a range that extends from infinity down to 10cm, and, from the user's perspective, no special change happens when he transitions from above 30cm to below 30cm. Internally a mode change may mean that the camera uses a different focusing algorithm or has to move a lens to a special position, but there's no reason to make the user aware of that.
One of the most common mode errors occurs when the user forgets to leave the mode after the activity is complete. Jeff Johnson (GUI Bloopers, Morgan Kaufmann, 2000) uses the term spring-loaded to describe modes that revert to a default state after a time or after the user has finished a particular activity. The shift key on the keyboard is a perfect example. The capitalization mode is active while the shift key is held down, but the keyboard reverts to normal operation once the user releases the shift key.
By contrast the caps-lock key doesn't revert to a default. The indication that the user is in capitalization mode is usually an LED on the keyboard. This is rarely noticed by the user because his attention is on the screen and not on the keyboard. Most users find themselves inadvertently typing in all-caps far more often than they make productive use of the caps-lock key. I have even known users to remove the caps-lock key from their keyboards to avoid this particular mode error.
It's important to consider whether modal settings revert to default each time the device is turned on. As the designer, you have the choice: do you always keep the mode previously used or do you revert to a default mode? Remembering the user's preference is usually good practice, with some exceptions. If a device is likely to be used by many people, it may be better to always start them from the same place. The new user might not appreciate the previous user's settings. For example an information kiosk may have a large-font mode for users with weak eyesight. However, if the design assumes that each query is from a new user, leaving the device in large-font mode may be unwise.
Safety is also a reason to revert to a known state. Many medical devices have an alarm-silence mode. While these devices would typically record all settings through an off/on cycle, the alarm-silence mode always reverts to the audible state when the device is turned on. This is because the audible mode is safer—leaving a device in the silent mode might lead to an alarm condition going unnoticed for a time.
Safety considerations also lead us to ponder how difficult we should make mode transitions. In general it should be easy to transition from one mode to a safer mode. It should be more difficult to transition from a safe mode to a less safe mode. For example, an escalator can be stopped by pressing a red panic button. Hitting the button transitions the escalator to a safer mode. Starting the escalator again often requires a key and involves more steps because the moving state is more dangerous.
Some medical devices have a service mode that allows tests that troubleshoot the device. Many of these tests would be quite dangerous if run while the device is connected to the patient. The hazard of accidentally entering service mode while connected to a patient can be avoided by making the mode transition involve more than just a menu selection. Typically these devices force the user to turn off the unit and turn it on while holding down one of the keys on the keypad. By forcing the user to pass through the off mode to get to the service mode, we've reinforced the message that the unit shouldn't be in normal use when choosing the service mode. Users may find this cumbersome, but if it's emphasized that the extra steps are introduced for safety reasons then this mechanism is appreciated.
There are two important lessons to be learned from this article. The first is that reducing the number of modes will reduce the user's mental effort in using and navigating your interface. The second lesson is to design modes that match user tasks. This will reduce mode errors and will lead to a design that matches the flow of the user's activity.
Niall Murphy has been designing user interfaces for 12 years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy teaches and consults on building better user interfaces. He welcomes feedback and can be reached at firstname.lastname@example.org. Reader feedback to his articles can be found at www.panelsoft.com/murphyslaw.
Niall, good article. Another mode rule might be to design and structure your UI code to reflect your modes. This helps in debugging and maintenance.
- Mike Juran