Mode (user interface): Difference between revisions

Revision as of 01:04, 15 August 2023

Revision as of 03:13, 9 November 2023

Line 45:

===Examples of mode errors===

* The most common source of mode errors may be the [[caps lock|Caps Lock]] key. Other common modes available in [[PC keyboard]]s are the other [[lock key]]s, [[Num lock]] and [[Scroll lock]], and often the [[Insert key]]. [[Dead key]]s for [[diacritics]] also create a short-term mode, at least if they don'tdo not provide visual feedback that the next typed character will be modified. While the Lock keys on PC keyboards are designed with the intention that they be used as modal keys, the IBM PC hardware design does not require these nor any other specific keys to be modal but allows software to treat any key as modal. (The PC [[BIOS]] normally implements Caps Lock, Num Lock, and Scroll Lock states, so the modality of these keys may appear intrinsic, but it is neither technically nor practically necessary to use the BIOS for keyboard I/O, and in fact most modern operating systems do not use BIOS keyboard I/O.)

* PC users whose language is not based on the [[Latin alphabet]] commonly have to interact using two different [[keyboard layout]]s: a local one and [[QWERTY]]. This gives rise to mode errors linked to the current keyboard layout: quite often, the synchronization of "current layout" mode between the human and the interface is lost, and text is typed in a layout which is not the intended one, producing meaningless text and confusion. Keyboard keys in user interface elements like "(y/n)" can have opposite effect if a program is translated.

* A frequent example is the sudden appearance of a [[modal window|modal]] [[Alert dialog box|error dialog]] in an application while the user is typing, which is a form of [[focus stealing]]; the user expects the typed text to be introduced into a text field, but the unexpected dialog may discard all the input, or may interpret some keystrokes (like "Y" for "yes" and "N" for "no") in a way that the user did not intend, often triggering a destructive action that cannot be [[undo|reverted]]. Programmers can mitigate this by implementing a short delay between the modal dialog displaying and it beginning to accept keyboard input.

Line 81:

Alternatives to modes such as the [[undo]] command and the [[Recycle bin (computing)|recycle bin]] are recommended when possible.<ref name="Implementation">{{cite web|url=http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Implementation|title=Modal Panel - Implementation|website=Infragistics.com]|url-status=dead|archive-url=https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx#Implementation|archive-date=2013-05-06}}</ref> 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.<ref>{{cite journal|url=https://dl.acm.org/citation.cfm?id=358092|title=Design rules based on analyses of human error|year=1983|doi=10.1145/2163.358092|last1=Norman|first1=Donald A.|journal=Communications of the ACM|volume=26|issue=4|pages=254–258|s2cid=47103252|doi-access=free}}</ref>

This is demonstrated, for example, by some [[stop sign]]s at road intersections. A driver may be [[Operant conditioning|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. An improved design alleviates the problem by including a small diagram showing which of the directions have a stop sign and which don'tdo not, thus improving the [[situational awareness]] of drivers.

===Proper placement===

Line 94:

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'tdoes not have to remember the current state of the application when invoking a command: the same action will always produce the same perceived result.<ref>[http://www.useit.com/alertbox/springload.html Spring-Loaded Modes], Jakob Nielsen.</ref> An interface that uses quasimodes only and has no full modes is still modeless according to Raskin's definition.

The [[StickyKeys]] feature turns a quasimode into a mode by serializing keystrokes of modifier keys with normal keys, so that they don'tdo not have to be pressed simultaneously. In this case the increased possibility of a mode error is largely compensated for by the improved [[accessibility]] for users with physical disabilities.

==See also==