Recommendations for designing user interfaces (according to the book by Ruskin "Interface"). Part 1
The material that I am going to present is a summary of Jeff Raskin’s book, supplemented by some reasoning based on my own experience. The first post in this series - "Entry" - is here .
The first part describes the features of human perception that are important for the design of the interface, as well as the principles of interface design.
At any given time, a person can focus his attention on only one subject. It may be some real-world object (for example, a piece of paper), a specific area of the screen or a window, or maybe some process “in the mind” (for example, when a person thinks about his actions or something counts). The subject on which the attention of a person 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. With periodic switching of attention, for example, from the working area of the document to error reporting, the work efficiency decreases. This is due to the fact that when a locus changes, the “operational” information associated with it that is contained in the short-term memory is lost. Accordingly, when returning to the previous locus, this information must be somehow restored.
2. With close attention focused, all events outside the locus can be ignored or simply go unnoticed.
')
When performing certain actions time after time a person ceases to pay attention to their fulfillment - actions are performed unconsciously. Thus, a person forms habits - useful skills that allow you to quickly perform routine operations. The interface can both contribute to the formation of habits, as well as prevent it - depending on whether it can perform routine actions uniformly.
Habit can be harmful. A typical example is confirmation of command execution in a dialog box. If a dialog box appears every time when performing routine operations, then in the end a person stops reading the text in this window (and this is true not only for such “classic” users as accountants or secretaries, but also for the programmers themselves). Therefore, if a similar window appears when a user sends a command by mistake, he will confirm the command without thinking, because it has become a habit. This can have dire consequences if the team was irreversible and led to the destruction of important data. I want to emphasize that the example of harm from habit is a problem not for the user, but for the interface itself. One way to avoid such problems is to ensure command reversibility wherever possible.
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 interface states in which the same user's gesture is interpreted differently. A gesture can be typing a word, pressing a certain keyboard shortcut (for example, Ctrl-S) or a mouse button, even moving the mouse, etc. Modality is also a serious source of error when interacting with the program. Even a change in the state of an object (for example, from on to off) performed by the same gesture is modal, because to perform the desired action (“turn on”, “turn off”) it is necessary to know and keep the current state of the object in the locus of attention. As it was said in subsection 1.1, if a person’s attention is focused on something else, then information about the state of the object can be ignored, which will entail errors.
Fortunately, interface modality does not occur in two cases.
1. In the event that the context in which the gesture is performed is in 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 the user who wants to delete it when you click Backspace. The Caps Lock key, on the contrary, is modal in many cases, since retains its effect - changing the case of letters - and after the user's locus has shifted from typing the right word in upper case to other operations.
2. If during the execution of the gesture some key or several keys are additionally held down (for example, Ctrl or Ctrl + Alt). In fact, such a gesture is perceived as new, and therefore does not conflict with others. Raskin calls this modification "quasi-mode."
Since modality leads to errors of interaction with the program, a good principle for creating interfaces is the elimination of modality. One way to achieve this is to use “quasi-modes” (see also subsection 1.3).
The purpose of most programs is ultimately (should be) the simplification of 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 performed again, which cannot be called a simplification. Therefore, any program must ensure the safety of user data, be it a simple text message, a 3D model or a scientific article. Only the user can judge the importance of the data, but not the program with which it interacts. There can be a lot of ways to ensure data integrity: it is the automatic saving of any changes, the reversibility of operations, and the creation of a backup archive.
In the formation of many teams can be used one of two models:
1. First, indicate the object, and then the action to be performed with this object (the “object-action” model).
2. First specify the action, and then the object to which this action should be applied (the “action-object” model).
Preferred is the first model - "object-action". First, it eliminates many modal errors, since the switching action 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 kind of action with this object.
The use of the second model - “action-object” - is also permissible, but only in those cases when its use is sufficiently reasoned.
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 every elementary action in it can be performed in exactly one way (ie, with a gesture). Often, there are several ways to perform the same action: through the menu, keyboard shortcut, mouse click, etc. However, this practice makes it difficult to form habits, because the user must choose each time how to perform the action. And only when he begins to perform an action is always only in one way, i.e. he will reduce the non-monotonous interface to the monotonous one, he will have the opportunity to form the habit to perform this action. If you immediately design the interface so that it is monotonous, it will reduce the time of user training. An exception may probably be 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 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 neither one nor the other user group will be satisfied with.
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) how to control and influence the system.
In the absence of information about the state of the system, the number of errors made when working with the program increases. Informing the user about the state of the system includes including the provision of various kinds of feedback: highlighting the object that the mouse pointer is over, indicating that the user’s action is perceived by the program and is being processed, etc.
In the case when there is no visible information about how to influence the system, a person has to perform extra work related to obtaining this information, which is unlikely to contribute to focusing on his own tasks. A control can be considered visible if it is directly accessible for perception or has been perceived so recently that it has not yet managed to get out of short-term memory. In this case, the element should not only be visible in principle, but visible where the user expects to be seen, most likely in the locus of attention.
It can be assumed that precisely because of the visibility of graphical interfaces have become much more popular console. Although the latter can be quite convenient for work, but the “threshold of entry” for them is much higher.
A control is not only visible, but also consistent, if one user can determine exactly how to interact with it: buttons — press, scroll bars — move, etc. Thus, the principle of consistency complements the principle of visibility.
Interaction with similar in appearance elements and objects should always take place in a uniform manner, otherwise there will be errors associated with 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 clicked, and in another situation an element that looks like it needs to be moved.
The first part describes the features of human perception that are important for the design of the interface, as well as the principles of interface design.
1. Features of human perception
1.1. Locus of attention
At any given time, a person can focus his attention on only one subject. It may be some real-world object (for example, a piece of paper), a specific area of the screen or a window, or maybe some process “in the mind” (for example, when a person thinks about his actions or something counts). The subject on which the attention of a person 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. With periodic switching of attention, for example, from the working area of the document to error reporting, the work efficiency decreases. This is due to the fact that when a locus changes, the “operational” information associated with it that is contained in the short-term memory is lost. Accordingly, when returning to the previous locus, this information must be somehow restored.
2. With close attention focused, all events outside the locus can be ignored or simply go unnoticed.
')
1.2. Habit formation
When performing certain actions time after time a person ceases to pay attention to their fulfillment - actions are performed unconsciously. Thus, a person forms habits - useful skills that allow you to quickly perform routine operations. The interface can both contribute to the formation of habits, as well as prevent it - depending on whether it can perform routine actions uniformly.
Habit can be harmful. A typical example is confirmation of command execution in a dialog box. If a dialog box appears every time when performing routine operations, then in the end a person stops reading the text in this window (and this is true not only for such “classic” users as accountants or secretaries, but also for the programmers themselves). Therefore, if a similar window appears when a user sends a command by mistake, he will confirm the command without thinking, because it has become a habit. This can have dire consequences if the team was irreversible and led to the destruction of important data. I want to emphasize that the example of harm from habit is a problem not for the user, but for the interface itself. One way to avoid such problems is to ensure command reversibility wherever possible.
1.3. The issue of modality
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 interface states in which the same user's gesture is interpreted differently. A gesture can be typing a word, pressing a certain keyboard shortcut (for example, Ctrl-S) or a mouse button, even moving the mouse, etc. Modality is also a serious source of error when interacting with the program. Even a change in the state of an object (for example, from on to off) performed by the same gesture is modal, because to perform the desired action (“turn on”, “turn off”) it is necessary to know and keep the current state of the object in the locus of attention. As it was said in subsection 1.1, if a person’s attention is focused on something else, then information about the state of the object can be ignored, which will entail errors.
Fortunately, interface modality does not occur in two cases.
1. In the event that the context in which the gesture is performed is in 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 the user who wants to delete it when you click Backspace. The Caps Lock key, on the contrary, is modal in many cases, since retains its effect - changing the case of letters - and after the user's locus has shifted from typing the right word in upper case to other operations.
2. If during the execution of the gesture some key or several keys are additionally held down (for example, Ctrl or Ctrl + Alt). In fact, such a gesture is perceived as new, and therefore does not conflict with others. Raskin calls this modification "quasi-mode."
2. Principles of building interfaces
2.1. Lack of modality
Since modality leads to errors of interaction with the program, a good principle for creating interfaces is the elimination of modality. One way to achieve this is to use “quasi-modes” (see also subsection 1.3).
2.2. User data retention
The purpose of most programs is ultimately (should be) the simplification of 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 performed again, which cannot be called a simplification. Therefore, any program must ensure the safety of user data, be it a simple text message, a 3D model or a scientific article. Only the user can judge the importance of the data, but not the program with which it interacts. There can be a lot of ways to ensure data integrity: it is the automatic saving of any changes, the reversibility of operations, and the creation of a backup archive.
2.3. Formation of teams on the principle of "object -> action"
In the formation of many teams can be used one of two models:
1. First, indicate the object, and then the action to be performed with this object (the “object-action” model).
2. First specify the action, and then the object to which this action should be applied (the “action-object” model).
Preferred is the first model - "object-action". First, it eliminates many modal errors, since the switching action 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 kind of action with this object.
The use of the second model - “action-object” - is also permissible, but only in those cases when its use is sufficiently reasoned.
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 every elementary action in it can be performed in exactly one way (ie, with a gesture). Often, there are several ways to perform the same action: through the menu, keyboard shortcut, mouse click, etc. However, this practice makes it difficult to form habits, because the user must choose each time how to perform the action. And only when he begins to perform an action is always only in one way, i.e. he will reduce the non-monotonous interface to the monotonous one, he will have the opportunity to form the habit to perform this action. If you immediately design the interface so that it is monotonous, it will reduce the time of user training. An exception may probably be 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 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 neither one nor the other user group will be satisfied with.
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) how to control and influence the system.
In the absence of information about the state of the system, the number of errors made when working with the program increases. Informing the user about the state of the system includes including the provision of various kinds of feedback: highlighting the object that the mouse pointer is over, indicating that the user’s action is perceived by the program and is being processed, etc.
In the case when there is no visible information about how to influence the system, a person has to perform extra work related to obtaining this information, which is unlikely to contribute to focusing on his own tasks. A control can be considered visible if it is directly accessible for perception or has been perceived so recently that it has not yet managed to get out of short-term memory. In this case, the element should not only be visible in principle, but visible where the user expects to be seen, most likely in the locus of attention.
It can be assumed that precisely because of the visibility of graphical interfaces have become much more popular console. Although the latter can be quite convenient for work, but the “threshold of entry” for them is much higher.
2.6. Wealth
A control is not only visible, but also consistent, if one user can determine exactly how to interact with it: buttons — press, scroll bars — move, etc. Thus, the principle of consistency complements the principle of visibility.
Interaction with similar in appearance elements and objects should always take place in a uniform manner, otherwise there will be errors associated with 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 clicked, and in another situation an element that looks like it needs to be moved.
Source: https://habr.com/ru/post/96810/
All Articles