posted by Thom Holwerda on Sun 11th Nov 2007 15:52 UTC
IconThis is the fifth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part V, we focus on modes.

Up until now, this series focused on rather well-known terms, but today, we will be taking on a term that many of you will not have heard of (in the context of user interface design, in any case): modes. I will start off by explaining what is meant by modes, I will give some examples, after which I will explain why some believe they are inherently evil (cue "mode errors"). I will end by explaining what can be done about solving the problems caused by modality in graphical user interfaces.

The definition of the word "mode" in a regular dictionary reveals little about its relation to graphical user interfaces. In order to get a better definition, we need to go to the man who spearheaded the campaign against the modal interface: Jef Raskin, co-creator of the Macintosh. In his well-known book, "The Humane Interface", he defines the modal interface in the following way: "A human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." In other words, the same user input can produce different types of output, depending on the state ("mode") the computer is in.

There are a lot of examples of this behaviour in today's user interfaces, the most prominent of that being the infamous caps. lock key. When the caps. lock key is active, any text that gets put into the computer will be displayed with capital letters; when the key is deactivated, the computer displays the text as lower case letters - two different "modes" or "states" that the computer can be in. Another example is, as weird as it may seem, the on/off switch on that same computer: it allows you to switch between two modes: on, and (surprise) off (you did not see that one coming, did you).

However, modality is much deeper entrenched in the world of computers than these fairly tactile examples seem to illustrate: consider a drawing or photo editing program. If you want to see one type of application that is filled with countless modes, load up your favourite image editor, and click on the various options in the tool window. When you have the paintbrush tool activated, you are in a different mode than when you have the pencil tool activated. Good luck counting all the different modes in your drawing application.

Another particularly cruel and inherently evil (I got a little opinionated there, did you see?) modal element on a computer is the modal dialog. The modal dialog is a dialog (or window) that blocks all access to its parent application until the dialog itself has been dealt with. My most infuriating example of a modal dialog is Firefox' settings window. When you open the settings panel in Firefox, and you have just one window open, all access to that window is blocked, meaning you are forced to deal with the settings panel before you can continue browsing. This gets particularly aggravating the moment you want to copy/paste something from that particular browsing window into the settings panel (like a link or a proxy .pac script URL); you must close all the settings panels, copy the URL and reopen the settings panel.

It can get even more cruel than that: modal dialogs that steal focus without the user's consent. I am not even going to explain the horror. Use your imagination.

Apple's Human Interface Guidelines also have some things to say on modes. "As much as possible, allow users to do whatever they want at all times. Avoid using modes that lock them into one operation and prevent them from working on anything else until that operation is completed. Mac OS X supports enhanced modelessness with drawers and sheets. Drawers provide additional functionality while allowing continued access to the parent window. Sheets are modal dialogs attached to a parent window, replacing the use of application-modal dialogs." The sheets part is a bit misleading, as those sheets are still very much modal in that they block all access to their parent windows.

Even though Apple advises against using modes, one of their most defining user interface elements is the poster child for modal behaviour: the global menubar atop the screen. If there is one prime example of a completely and utterly modal interface element, with basically an unlimited amount of modes (all depending on the amount of applications there are for OS X) it is OS X' global menubar. This is particularly interesting seeing Jef Raskin is the person who actually started the Macintosh project in the first place.

Table of contents
  1. Modes
  2. Mode errors; Preventing mode errors; Conclusion
e p (0)    29 Comment(s)

Technology White Papers

See More