Recommendations for designing user interfaces (according to Raskin's book “Interface”). Part 1

    The material I am going to present is a generalization of the book by Jeff Raskin, supplemented by some reasoning based on my own experience. The first post in this series, “Introduction,” is here .
    The first part describes the features of human perception that are important for designing an interface, as well as the principles of building an interface.

    1. Features of human perception


    1.1. Focus of attention

    At any given time, a person can focus his attention on only one subject. It can be some kind of object of the real world (for example, a sheet of paper), a certain area of ​​the screen or window, or it can be some kind of process “in the mind” (for example, when a person thinks about his actions or calculates something). The subject on which human attention is focused will be called the locus of his attention. At least two features of human perception are associated with the locus of attention.

    1. By periodically switching attention, for example, from the workspace of a document to error notifications, work efficiency decreases. This is due to the fact that when the locus is changed, the “operational” information associated with it, which is contained in short-term memory, is lost. Accordingly, when returning to the previous locus, this information must be somehow restored.

    2. With close attention, all events outside the locus can be ignored or simply go unnoticed.

    1.2. Habits

    When performing certain actions over and over again, a person ceases to pay attention to their implementation - actions are performed unconsciously. Thus, a person develops habits - useful skills that allow you to quickly perform routine operations. An interface can both help to develop habits and prevent it - depending on whether routine actions can be performed uniformly in it.

    The habit can be harmful. A typical example is confirmation of the execution of a command in a dialog box. If a dialog box appears every time during routine operations, then in the end a person stops reading the text in this window (and this is true not only for such "classical" users as accountants or secretaries, but also for programmers themselves). Therefore, if a similar window appears when the user gave the command by mistake, then without hesitation, he will confirm the command, because it has become a habit for him. This can have sad consequences if the team was irreversible and led to the destruction of important data. I want to emphasize that the above example of harm from a habit is not a problem of the user, but of the interface itself. One way to avoid such problems is to ensure that teams are reversible everywhere,

    1.3. Modality problem

    A significant obstacle to the formation of user habits when working with the interface is the presence of several modes in the interface. Modes are states of the interface in which the same user gesture is interpreted differently. A gesture can be a set of words, pressing a certain combination of keys (for example, Ctrl-S) or a mouse button, even mouse movement, etc. Modality is also a serious source of errors when interacting with a program. Even a change in the state of an object (for example, from switched on to turned off), performed by the same gesture, is modal, because to perform the desired action (“turn on”, “turn off”) you need to know and keep the current state of the object in the locus of attention. As stated in subsection 1.1, if a person’s attention is focused on something else,

    Fortunately, interface modalities do not occur in two cases.

    1. In the event that the context in which the gesture is executed is at the user's locus of attention. For example, pressing the Backspace key while typing could be considered modal, since the result of this gesture depends on which letter is in front of the cursor. However, this letter is in the locus of attention, since it is precisely its user who wants to delete it by pressing Backspace. The Caps Lock key, in contrast, is modal in many cases because retains its effect - changing the case of letters - and after the user's locus of attention has shifted from typing the desired word in upper case to other operations.

    2. If during the execution of a gesture any key or several is additionally held (for example, Ctrl or Ctrl + Alt). In fact, such a gesture is perceived as new, so it does not conflict with others. Raskin calls such a modification "quasi-mode."

    2. Principles of building interfaces


    2.1. Lack of modality

    Since modality leads to errors in interacting with the program, a good principle for creating interfaces is to exclude modality. One way to achieve this is to use “quasi-modes” (see also subsection 1.3).

    2.2. User data security

    The purpose of most programs ultimately is (should be) a simplification of the work performed by man. User data is the result of a person’s work. If this result is lost, the work will have to be done again, which cannot be called a simplification. Therefore, any program should ensure the safety of user data, whether it be a simple text message, a 3D model or a scientific article. Only the user himself can judge the importance of the data, but not the program with which he interacts. There can be many ways to ensure data safety: this is the automatic saving of any changes, the reversibility of operations, and the creation of a backup archive.

    2.3. The formation of teams on the principle of "object -> action"

    In the formation of many teams, one of two models can be used:

    1. First, indicate the object, and then the action that must be performed with this object (the "object-action" model).

    2. First indicate the action, and then the object to which this action should be applied (model “action-object”).
    Preferred is the first model - the "object-action". Firstly, it eliminates many modal errors, since switching actions is usually accompanied by switching operating modes. Secondly, it is easier for a person to perceive, since, as a rule, the user's locus of attention is already on the object when it becomes necessary to perform some action with this object.
    The use of the second model - the “action-object” - is also acceptable, but only in cases where its use is reasonably enough.

    2.4. Monotone

    Habits can be formed in a person only if each action can always be performed in the same way. An interface can be called monotonous when each elementary action in it can be performed in exactly one way (i.e., by a gesture). Often, for one and the same action, several ways of execution are provided: through the menu, by a combination of keys, a mouse click, etc. However, this practice makes it difficult to form habits, because each time the user must choose how to perform the action. And only when he begins to perform an action always in only one way, i.e. he will reduce the non-monotonous interface to a monotonous one, he will have the opportunity to form a habit for performing this action. If you immediately design the interface so that it is monotonous, this will reduce the user's training time. An exception is probably the case when an interface is designed for users with different devices. For example, some users use a desktop PC with a keyboard and mouse, and some use a tablet PC with a touch screen. However, in this case, it is worth thinking about other alternatives, for example, finding an interaction method that will be applicable on different devices, or developing different versions of the interface for different devices. Otherwise, there is a risk of creating an interface that will not suit either group of users. for example, finding a way of interaction that will be applicable on different devices, or developing different versions of the interface for different devices. Otherwise, there is a risk of creating an interface that will not suit either group of users. for example, finding a way of interaction that will be applicable on different devices, or developing different versions of the interface for different devices. Otherwise, there is a risk of creating an interface that will not suit either group of users.

    2.5. Visibility

    The program interface should promptly inform the user about:
    1) the current state of the system and the change of state as a result of user actions;
    2) methods of control and impact on the system.

    In the absence of information about the state of the system, the number of errors allowed when working with the program increases. Informing the user about the state of the system includes, among other things, providing various kinds of feedback: highlighting the object that the mouse pointer is over, an indication that the user’s action has been accepted by the program and is being processed, etc.

    In the case when there is no visible information about the ways to influence the system, a person has to do the extra work associated with obtaining this information, which is unlikely to help focus on one’s own tasks. A control can be considered visible if it is directly accessible to perception or has been perceived so recently that it has not yet managed to exit short-term memory. Moreover, the element should not only be visible in principle, but visible where the user expects to see it, most likely - at the locus of attention.

    It can be assumed that precisely because of visibility, graphical interfaces have become much more popular than console ones. Although the latter may be quite convenient for work, the “entry threshold” for them is much higher.

    2.6. Solvency

    A control is not only visible, but also consistent if, by its appearance alone, the user can determine how to interact with it: buttons - click, scroll bars - move, etc. Thus, the principle of consistency complements the principle of visibility.

    Interaction with similar-looking elements and objects should always be the same, otherwise errors will occur related to the modality of the interface. An example would be an interface in which in one situation an element that looks like a button needs to be pressed, and in another situation, an element that looks like this should be moved.

    Also popular now: