Mode (user interface): Difference between revisions
m Bot: Migrating 1 interwiki links, now provided by Wikidata on d:q6888088 |
m →Definition: Italics |
||
Line 7: | Line 7: | ||
== Definition == |
== Definition == |
||
A precise definition is given by [[Jef Raskin]] in his book |
A precise definition is given by [[Jef Raskin]] in his book ''[[The Humane Interface]]'': |
||
<blockquote> |
<blockquote> |
||
"An human-machine interface is modal with respect to a given gesture |
"An human-machine interface is modal with respect to a given gesture |
Revision as of 02:35, 1 May 2013
In user interface design, a mode is a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived different results than it would in other settings. The best-known modal interface components are probably the Caps lock and Insert keys on the standard computer keyboard, both of which put the user's typing into a different mode after being pressed, then return it to the regular mode after being re-pressed.
An interface that uses no modes is known as a modeless interface.[1] Modeless interfaces intend to avoid mode errors[2] by making it impossible for the user to commit them.
Definition
A precise definition is given by Jef Raskin in his book The Humane Interface:
"An 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." (Page 42).
In Raskin's sense and according to his definition, an interface is not modal as long as the user is fully aware of its current state. Raskin refers to this as 'locus of attention' (from the Latin word locus meaning "place" or "location"). Typically a user is aware of a system state if the state change was purposefully initiated by the user, or if the system gives some strong signals to notify the user of the state change. If the user's locus of attention changes to a different area, the state of the interface may then represent a mode since the user is no longer aware of it.
Examples
![]() | This section needs expansion with: the detailed description of typical uses of modes. You can help by adding to it. (December 2010) |
Several examples of well-known software have been described as modal and/or using interface modes:
- Text editors - typically are in insert mode by default but can be toggled in and out of overtype mode by pressing the Insert key.
- vi - has one mode for inserting text, and a separate mode for entering commands. There is also an "ex" mode for issuing more complex commands (e.g. search and replace). Under normal circumstances, the editor automatically returns to the previous mode after a command has been issued; however, it is possible to permanently move into this mode using Shift-Q.
- Emacs - has a special mode for issuing commands, which is entered by pressing the control key plus a letter key. This differs from vi in that the mode always ends as soon as the command is called, when the sequence of key presses that activates it is completed. Emacs also has many "major and minor" modes that change the available commands, and are automatically invoked based on file type to more easily edit files of that type. Modes are written in Emacs Lisp, and all modes may not be included with all versions.
- Cisco IOS - certain commands are executed in a "command mode".
- Tools chosen from a palette in photo-editing and drawing applications are examples of a modal interface.
- Video games can use game modes as a mechanic to enhance gameplay.
- Modal windows block all workflow in the top-level program until the modal window is closed.[3]
Mode errors
Modes are often frowned upon in interface design because they are likely to produce mode errors when the user forgets what state the interface is in, performs an action that is appropriate to a different mode, and gets an unexpected and undesired response.[4] A mode error can be quite startling and disorienting as the user copes with the sudden violation of his or her user expectations.
Problems occur if a change in the system state happens unnoticed (initiated by the system, or by another person, such as the user who was previously using the machine), or if after some time the user forgets about the state change. Another typical problem is a sudden change of state that interrupts a user's activity, such as focus stealing. In such a situation it can easily happen that the user does some operations with the old state in mind, while the brain has not yet fully processed the signals indicating the state change.
A very frustrating type of modality is created by a mode where the user does not find a way out, or, in other words, where she cannot find how to restore the old system state.
Examples of mode errors
- The most common source of mode errors may be the caps lock key. Other common modes available in PC keyboards are Insert and the other lock keys, Num lock and Scroll lock. Also dead keys for diacritics create a short-term mode, at least if they don't provide visual feedback that the next typed character will be modified.
- A frequent example is the sudden appearance of a modal error dialog in an application while the user is typing, known as focus stealing; the user expects the typed text to be introduced into a text field, but the unexpected dialog discards all that input and may even interpret some keystrokes (like 'Y' or 'N' for 'yes' or 'no') incorrectly.
- The Unix text editor vi can be notoriously difficult for beginners precisely because it uses modes, and earlier versions configured mode indication to be turned off by default.
Assessment
Modes are intended to grab the user's full attention and to acknowledge the content present in them, in particular when critical confirmation from the user is required. [5] This later use is criticised as ineffective for its intended use (protection against errors in destructive actions) due to habituation. Actually making the action reversible (providing an "undo" option) is recommended instead.[6] Though modes can be successful in particular usages to restrict dangerous or undesired operations, especially when the mode is actively maintained by a user as a quasimode.
Modes are sometimes used to represent information pertinent to the task that doesn’t fit well into the main visual flow.[5] Modes can also work as well-understood conventions, such as painting tools.[4]
Modal proponents[who?] may argue that many common activities are modal and users adapt to them. An example of modal interaction is that of driving motor vehicles. A driver may be surprised when pressing the acceleration pedal does not accelerate the vehicle in the forward direction, most likely because the vehicle has been placed in an operating mode like park, neutral, or reverse. Modal interfaces require training and experience to avoid mode errors like these.
Interface expert Jef Raskin came out strongly against modes, writing, "Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces." Later he notes, "'It is no accident that swearing is denoted by #&%!#$&,' writes my colleague, Dr. James Winter; it is 'what a typewriter used to do when you typed numbers when the Caps Lock was engaged'." Raskin dedicated his book The Humane Interface to describe the principles of a modeless interface for computers. Those principles were implemented in the Canon Cat and Archy systems.
Some interface designers have recently taken steps to make modal windows more obvious and user friendly by darkening the background behind the window or allowing any mouse click outside of the modal window to force the window to close – a design called a Lightbox[7] – thus alleviating the risk of modal errors. Jakob Nielsen states as an advantage of modal dialogs that it improves user awareness. "When something does need fixing, it's better to make sure that the user knows about it". For this goal, the lightbox design provides strong visual contrast of the dialog over the rest of the visuals. However, while such a method may reduce the risk of inadvertent wrong interactions, it does not solve the problem that the modal window blocks use of the application's normal features and so prevents the user from taking any action to fix the difficulty, or even from scrolling the screen to bring into view information which they need to correctly choose from the options the modal window presents, and it does nothing to alleviate the user's frustration at having blundered into a dead end from which they cannot escape without some more or less destructive consequence.
Larry Tesler, of Xerox PARC and Apple Computer, disliked modes sufficiently to get a personalized license plate for his car that reads: "NO MODES". He has used this plate from the early 1980s to the present, on various cars. Along with others, he has also been using the phrase "Don't Mode Me In" for years as a rally cry to eliminate or reduce modes.[8]
Bruce Wyman, the designer of a multi-touch table for a Denver Art Museum art exhibition [9] argues that interfaces for several simultaneous users must be modeless, in order to avoid bringing any single user into focus.[10]
Design recommendations
Avoid when possible
![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/9f/Arret.jpg/220px-Arret.jpg)
Alternatives to modes such as the undo command and the recycle bin are recommended when possible.[11] HCI researcher Donald Norman argues that the best way to avoid mode errors, in addition to clear indications of state, is helping the users to construct an accurate mental model of the system which will allow them to predict the mode accurately.
This is demonstrated, for example, by some stop signs at road intersections. A driver may be conditioned by a four-way stop sign near his or her home to assume that similar intersections will also be four way stops. If it happens to be only two way, the driver could proceed through if he or she sees no other cars. Especially if there is an obstructed view, a car could come though and hit the first car broadside. The stop sign alleviates the problem by showing small diagrams describing which of the directions have a stop sign and which don't, thus improving the situational awareness of drivers.
Proper placement
Modal controls are best placed where the focus is in the task flow.[11] For example, a modal window can be placed near the GUI control that triggers its activation. Modal controls can be disruptive, so efforts should be made to reduce their capacity to block user work. After completing the task for which the mode was activated, or after a cancel action such as the Escape key, returning to the previous state when a mode is dismissed will reduce the negative impact.
Quasimodes
In the book The Humane Interface, Jef Raskin championed what he termed quasimodes, which are modes that are kept in place only through some constant action on the part of the user; such modes are also called spring-loaded modes.[12] The term quasimode is a composite of the Latin prefix quasi- (which means almost, to some degree) and the English word "mode".
Modifier keys on the keyboard, such as the Shift key, the Alt key and the Control key, are all examples of a quasimodal interface.
The application enters into that mode as long as the user is performing a conscious action, like pressing a key and keeping it pressed while invoking a command. If the sustaining action is stopped without executing a command, the application returns to a neutral status.
The purported benefit of this technique is that the user doesn't have to remember the current state of the application when invoking a command: the same action will always produce the same perceived result.[13] An interface that uses quasimodes only and has no full modes is still modeless.
The StickyKeys feature turns a quasimode into a mode by serializing keystrokes of modifier keys with normal keys, so that they don't have to be pressed simultaneously. In this case the increased possibility of a mode error is largely compensated by the improved accessibility for users with physical disabilities.
See also
- Application posture
- Automation surprise
- Error message
- GUI
- Human computer interaction
- Interaction design
- Modal window
- Modalities and modes
- State (computer science)
- Text mode
Notes
- ^ Usability Glossary: modeless
- ^ Usability Glossary: mode error
- ^ "How to Use Modality in Dialogs". Oracle Corporation.
- ^ a b Usability Glossary: modal
- ^ a b Infragistics.com. "Modal Panel - Context".
{{cite web}}
: External link in
(help)|author=
- ^ Aza Raskin, A List Apart: Never Use a Warning When you Mean Undo
- ^ Jakob Nielsen, Alertbox. "10 Best Application UIs".
- ^ Origins of the Apple Human Interface by Larry Tesler, Chris Espinosa
- ^ Technology for Experience's Sake: Guest Post by Bruce Wyman
- ^ Bruce Wyman's post at the ixda.org mailing list
- ^ a b Infragistics.com. "Modal Panel - Implementation".
{{cite web}}
: External link in
(help)|author=
- ^ Usability Glossary: spring-loaded mode
- ^ Spring-Loaded Modes, Jakob Nielsen.
References
- Buxton, William A. S. (1995). "Chunking and phrasing and the design of human-computer dialogues". In Baecker, Ronald M. and Grudin, Jonathan and Buxton, William A. S. and Greenberg, Saul (ed.). Readings in human-computer interaction : toward the year 2000 (2 ed.). San Francisco, Calif.: Morgan Kaufmann. pp. 494–499. ISBN 1-55860-246-1.
{{cite book}}
: Unknown parameter|acmid=
ignored (help)CS1 maint: multiple names: editors list (link)
External links
- Modelessness in UsabilityFirst glossary
- Modelessness in Apple's HIG guidelines
- Definition of mode error at Usability First
- An Example of a mode error in Excel
- John Rushby. Using Model Checking to Help Discover Mode Confusions and Other Automation Surprises. A paper discussing an automatic method for locating mode errors.
- Jakob Nielsen on Spring-loaded modes