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 translates into real-world GUI design. We will begin with some general considerations and conclude with some practical advice, also providing a simple demo application.
Introduction
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.
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 to the “natural” manipulation mode we use when manipulating a coffee mug. It’s as though 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 that illusion.
The so-called Deferred mode interaction allows users to manipulate the system without making the changes done definitive. Thus, we can devise mainly two ways of interacting with a piece of software, depending on the way changes are committed. If our particular interface allows for postponing changes until we want to apply them, we have 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 clearly conveying the state that this kind of interaction styles implicitly entails.
In Figure 3, the state diagram typical of deferred mode GUIs is depicted.
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 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 follows an ordered procedure (activation, manipulation, and deactivation with the eventual commit of changes). Think to the well-known file selection task:
- The task is activated by the user, by means of the “File, Open” menu command or the related toolbar button,
- The user manipulates the task data (here, files and directories) until s/he desires so,
- The user deactivates the file selection task, either by committing the changes (for example, selecting the wanted file and pushing 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 in regards to 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 for select incrementally).
Immediate mode tends to give more freedom to the user when 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 elaborate 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. 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 a GUI’s design.
A chooser is a part of a GUI specialized in the data selection task. Usually choosers are organized in dialogs, to better isolate the selection task. The file dialog 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.
Choosers
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 for isolating (and sometimes editing) the selection task 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.
Figure 4. The example application
When the “Text” button is pushed, a dialog pops up for manipulating the text, while pushing the “Color” button activates a color chooser for changing the color of the text, and finally, the “Icon” button triggers a file chooser for selecting 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 dialogs’ 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 pop-up secondary windows; in other words, such windows are logically bound to a main (or primary) window. Usually, GUI designers 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 disappear 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 end of the selection task. Dialogs like 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 (such as 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 (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 into the executable JAR file.
Thinking of the two basic interactions modes and the kind of interaction mode used in the chooser, we can write down the information contained in Table 1.
| Table 1. Possible combinations of chooser dialogs | ||
|---|---|---|
| Chooser Dialogs | Deferred mode | Immediate mode |
| Single-use | standard | X |
| Multiple-use | rare | occasional |
This table briefly discusses the available design choices and their use in professional GUIs.
Conclusion
In this article, we discussed the often overlooked issue of user interfaces’ interaction modes. After a theoretical introduction, we used a practical case (choosers’ dialogs) and a demo application for explaining practically the design choices available to GUI designers.
About the Author
Mauro Marinilli
