Mastering Interaction Modes
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.
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.
Page 1 of 2