Mastering Interaction Modes

by Mauro Marinilli

Learn how the basic modalities of user interaction translates into real-world GUI design.

In this article, we will discuss a basic issue that any user interface designer or software developer should be familiar with. We will see the basic modalities of user interaction and how these principles translate into real-world GUI design. We will begin with some general considerations concluding with some practical advice, also providing a simple demo application.


When we manipulate something in the real world (such as pouring some coffee in a mug, for instance) we do change the state of that object, directly and immediately. This seems obvious, but with the arrival of modern computers (and modern user interfaces) another alternative interaction mode has emerged, becoming the most commonly used interaction mode when interacting with such complex machines.

Take now an ordinary Web site, such as the one depicted in Figure 1.

Click here for a larger image.

Figure 1. An example of deferred mode interaction

In the user interface in Figure 1, we can manipulate the data presented onscreen as we need, but such data won't be saved until we explicitly request it. This is a big difference compared with the "natural" manipulation mode we use when manipulating a coffee mug. It's like we would fill our mug up until we discover it was dirty, so we cancel the operation to repeat it with a clean cup. In the real world, it's not possible to take back the time, but in complex machines (such as today's computing devices) it is possible to give the illusion of it.

The so-called Deferred mode interaction allows users to manipulate the system without making definitive the changes done. Thus, we can devise mainly two ways of interacting with software, depending on the way changes are committed. If our particular interface allows for postponing changes until we want to apply them, we have the deferred mode interaction. This is the most common interaction style. For example, the classic open file dialog (see Figure 2) is an example of such an interaction style.

Figure 2. The Open File dialog is an example of deferred mode interaction

The other interaction mechanism is called immediate because we don't need to commit the changes done through our user interface because they are instantly applied. An example of this interaction mode is some direct manipulation technique; for example, when changing the font style in our word processor, it immediately affects the selected text. Of course, we can restore the old settings (by means of the Undo command, for instance) but this is not the point. Here, we are discussing the mechanisms to make persistent (or committing, in programmer's jargon) the changes made to a given state of the system.

Note that non-trivial interfaces usually mix these two modes. We will see the practical aspects of interaction modes and their possible variations in the following section.

A subtle form of deferred mode interaction is used, for example, in the so-called desktop metaphor. When the user drags a file into a folder, the file is physically moved into that directory. In this case, we have an informal but effective kind of commit signal (when the user requests the execution of the performed operations) in the form of the drop gesture (when the user stops dragging the file icon, s/he is expressing the commit signal for that operation). Any intermediate state of the system (between the beginning of the manipulation and its commit) is considered invalid. The user affects the final state of the system only after the drop operation has succeeded.

Deferred Mode Interaction

Such an interaction mode is commonly used because it allows for greater flexibility and better error recovery.

This interaction style is not so common in cases where the interaction richness is low (this usually depends on technical issues). On voice interfaces, for example, (those where the system is being manipulated by voice) or simple wireless devices, usually there is no room for conveying clearly the state that this kind of interaction styles implicitly entails.

Figure 3 depicts the state diagram typical of deferred mode GUIs.

Figure 3. The state transitions implicitly used in deferred mode interaction

In this diagram, we have two main states, depending on whether the data being manipulated by the user has been committed permanently. The system changes between one of these two states, depending on the user request for commit (passing from the Temporary State to the Change Committed one) or the beginning of a new manipulation (hence, switching back to the Temporary State). In the "Change Committed" state, any data manipulated through the user interface has been permanently incorporated into the system.

Deferred mode interaction is widely adopted in GUIs because it lends to clearer designs, where each task follow an ordered procedure (activation, manipulation, and deactivation with the eventual commit of changes). Think to the well-known file selection task:

  1. The task is activated by the user, by means of the "File, Open" menu command or the related toolbar button.
  2. The user manipulates the task data (here, files and directories) until s/he desires to quit.
  3. The user deactivate the file selection task, either by committing the changes (for example, selecting the wanted file and clicking the "Open" button) or by canceling it (by clicking the "Cancel" button).

This structure is highly repetitive and can be applied to a wide range of tasks, hence the popularity of this interaction mode.

Immediate Mode Interaction

Even if less flexible than deferred mode, the immediate mode interaction is used in several practical situations. Professional GUI designers should consider carefully when using one mode instead of another, especially as regards choosing the immediate mode instead of the deferred one.

Immediate mode interaction is used mainly in the following cases:

  • There are not enough resources to use deferred mode so that this kind of interaction mode is the only way to go.
  • The selection task should be made available during normal use (for example, in showing some details of a complex structure). Usually, these kind of choosers are made available as non-modal floating dialogs.
  • The system should allow for repeated selections (for example, to see the changes done or to select incrementally).

Immediate mode tends to give more freedom to the user interacting with the system (and sometimes, especially for poor designs, in unforeseen ways).

Generally speaking, immediate mode is better suited for expert and repetitive users. Such an interaction mode tends to produce more cluttered screens (chooser panels, dialogs, and windows remain open to allow immediate mode interaction) and more elaborated interactions. Accidental selections are easier and often users need to receive some additional training about the use of such immediate-mode windows. For these reasons, this kind of interaction mode should be used with care, especially if the GUI is intended to be used by novice users and/or non-frequent users.

We are now ready to see a practical example of immediate mode interaction together with its variants.

A Practical Example

After a brief introduction to the theory of interaction modes, it is time to see them at work, practically. We will focus on the practical case of graphical user interfaces (GUIs), and in this vast realm we restrict our considerations to the design of particular parts of user interfaces called choosers. In this way, we discuss a very important part of GUIs design.

A chooser is a part of a GUI specialized in the data selection task. Usuallychoosers are organized in dialogs, to better isolate the selection task. The File dialog box, seen in Figure 2, is a well-known example of a chooser. In the rest of this article, we will use choosers as a practical means to explore interaction modes.


As we said, maybe the most useful way to discuss interaction modes is to introduce them by means of practical examples. Choosers are a common abstraction in modern GUIs to isolate the selection task (and sometimes editing) of some particular data. We provide a little Java application that shows these concepts at work. You can download the demo application from here and play with it. You need a J2SE runtime environment properly installed on your machine. Clearly, the topics involved in our discussion don't depend at all on the particular implementation technology used here (Java) and are general to any kind of GUI, on a wide range of computing devices. In this example, we have three different choosers used for manipulating some text and an image, both shown in a main window. In Figure 4, we see the main window and two choosers at work.

Click here for a larger image.

Figure 4. The example application

When the "Text" button is pushed, a dialog pops up to manipulate the text, while pushing the "Color" button activates a color chooser to change the color of the text, and finally, the "Icon" button triggers a file chooser to select a new image to show. These simple choosers are each an example of a possible combination of interaction modes and dialog properties. Before discussing the example, we need to add a last piece to our puzzle. We need to account for the dialog's behavior.

Reusable Dialogs

Following the example code provided, among the many possible choosers we now focus in this section on choosers contained in dialogs. Dialogs are popup secondary windows; in other words, such windows are logically bounded to a main (or primary) window. GUI designers usually distinguish between two different kind of chooser dialogs, depending on whether or not the choosers are reusable after a selection task has been accomplished.

That is, choosers depend also on what happens on them when the selection task is carried out. Usually, chooser dialogs are dismissed when the selection task is completed, as in the standard behavior of a file chooser that disappears after the file has been selected and the selection committed. This happens because we usually need to select a file and then use it. But, there could be cases where we would prefer to avoid dismissing the dialog after the selection task ends. Dialogs such as these are called multiple-use dialogs because they remain open even after the selection has been committed by the user, allowing for multiple selections.

These kinds of dialogs are useful when one needs to see the effects of the choice done, possibly modifying it (for example, repeating the selection).

In our example we use the following choosers:

  • A single-use, deferred mode chooser dialog for the image file selection
  • A multiple-use, immediate mode chooser dialog for color (the color chooser is shown in Figure 4)
  • A multiple-use, deferred mode editor dialog for text (such as the text chooser shown in Figure 4)

Note that the demo application is so simple that no extra check has been implemented (for instance, to avoid the instantiation of multiple choosers of the same type); its sole purpose is to illustrate practically the different types of chooser dialogs that are usually employed in a GUI. The source code has been included in the executable JAR file.

Thinking to the two basic interactions modes and the kind of interaction mode used in the chooser we can write, examine Table 1.

Chooser Dialogs Deferred mode Immediate mode
Single-use standard X
Multiple-use rare occasional

Table 1. Possible combinations of chooser dialogs.

This table briefly discusses the available design choices and their use in professional GUIs.


In this article, we discussed the often-overlooked issue of user interface interaction modes. After a theoretical introduction, we used a practical case (choosers' dialogs) and a demo application to explain practically the design choices available to GUI designers.

About the Author

Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to e-learning. You can email him at contact@marinilli.com.

This article was originally published on Wednesday Mar 19th 2003
Mobile Site | Full Site