Interface inertia

Raskin details the speed of user interaction with the computer, talking about the laws of Hick and Fitts. Author has several new thoughts on the topic, and they will be discussed in this article.

One small but sharp change in the design of iOS 5, the latest version of iPhone's firmware, prompted one thought. For quite logical reasons, Apple decided to put a button to go to your music store directly from the music player. Decided — and did it. And they did it this way:

The feature of this button is that the problem with it arises dynamically, during the usage of the interface, and it is completely invisible statically, when the user just looks at the screen. The problem is that in the list of songs of the selected album, instead of Store button there appears an another button called Albums and it returns the user back to the first screen with albums.

There is also a third button in the same place, it is already located on the playback screen of the track, and also leads one step back to the list of songs in the album.

So, with a fairly quick use of the player, the user can mistakenly press the "back" button twice, when it needs to be done just once. Thus, his finger will fall on the Store button, and the player application will switch to the store application, leaving the person in confusion and forcing to look for how to return back to music.

Since this erroneous action was carried out by inertia, we will call our law: the law of inertia.

The problem of typing on the keyboard

The law of inertia is not limited to a single example. It is everywhere.

The most important problem is when typing on the keyboard. Many experienced users are used to doing several things at once. The author often installs programs or updates, at the same time chatting with someone or writing a new article.

The problem is that under certain conditions, the installation program can suddenly require user's attention and pop out with its window on top of the others. And if at this moment the user types on the keyboard, the input focus will jump to the appeared window, the typing will continue in that window. Moreover, if the space bar or return key is pressed, among other things, this can result in pressing the active button in the window, which will confirm or cancel some action of the installation program. The latter can lead to unpredictable, sometimes very serious consequences.

One solution is to prohibit pressing buttons with spacebar. This would reduce the chance of doing unintended actions, but it would not eliminate all problems and would lead to a loss of control from the keyboard.

It is also possible to rework the OS notification mechanism in such a way that windows do not have the ability to pop up in principle, or have not always had the opportunity, or have had an unobvious ability to do so. Then notifications would be limited to flashing, jumping or other animation on the taskbar or in the dock.

But the best solution, I think, is to track the keyboard typing and delay the appearance of a third-party window until the typing is complete. In this case, there is a chance that the focus will still go to the opened window if its appearance after the delay coincides with the beginning of a new keyboard input. So, if possible, you should use some combination of this and the previous methods.

The problem of changing interface

An equally serious drawback is the sudden change of interface elements.

One of the most striking examples is the behavior of Mobile Safari browser. To save space in the browser interface, the "Update" and "Stop" buttons are often combined. When the page is loading, the "Stop" button is active, when the page is loaded, the "Refresh" button appears in its place.

The problem is that the user may want to stop loading the page at the very last moment, when the process is almost complete, and the buttons change. Thus, the movement of the finger begins when the "Stop" button is active, but the tap falls to the "Refresh" button. As a result, the page begins to reload.

This is one of the brightest examples of inertia in interfaces. The author has repeatedly got into this situation and is sure that he is not alone.

As a solution, you can suggest to delay the change of buttons for a while after the loading is complete.

A similar situation is sometimes observed on personal computers. For example, on some installation software, the user often has to press the "Next" button, and he, sometimes, does this automatically, not paying attention to the instructions on the screen. It is unlikely that this can lead to fatal consequences, but in general, by inertia, you can accidentally perform an unplanned action, if suddenly some other button appears instead of the "Next" button on the same place.

Notifications problem

The third type of problem appears in dialogs of warnings and requests. Working fast, the user can press the first button of the suddenly appeared dialogue. However, the button to press is not chosen by chance. This is influenced by two factors: the standard, familiar location of the button in the interface of a particular program and its size, as well as the complexity and readability of the caption on it.

In other words, if in the OS the "Yes" button is always located to the right of the "No" button, the user is trained to press the right button automatically. If you place the buttons in reverse, and also replace the short letters "Yes" and "No" with "Confirm Delete" and "Undo Delete", this conflicts with the user's habit and forces him to read the text and consider his choice.

Another good solution is offered by the authors of the Firefox browser. When you install a plugin, the browser prompts for confirmation from the user. However, the button "Install" is available not immediately, but after a few seconds.

Quantitative estimation of inertia of the interface

We can try to formalize the described features and derive a methodology for estimating interface inertia.

Obviously, the probability of performing an action by inertia is determined by:

Let the first user's typing speed be 360 characters per minute, or 6 characters per second. The first user uses a blind method of typing, and his reaction is 1 second.

Let also the speed of the second user will be 120 characters per minute, or 2 characters per second. The second user does not use a blind typing method, and his reaction is 5 seconds.

Let the dangerous key be the spacebar. The probability of a space in an average English text is 0.2. That is, the first user on average will press the space 72 times per minute, or 1.2 times per second. The second user presses the space 24 times per minute, or 0.4 times per second.

Let's calculate the inertia of the interface in the absence of a delay in the appearance of a "dangerous" interface element (an element that can be clicked with the spacebar, in our case). The inertia of the interface is proposed to be calculated using the following formula:

For the first user:

For the second user:

Let's calculate the inertia with a delay that is equal to the reaction time.

For the first user:

For the second user:

And let's calculate the inertia with the delay, that is 2 times longer than the reaction time.

For the first user:

For the second user:

Obviously, the longer the delay, the less the inertia of the interface. With a delay that is equal to the reaction time, the inertia is zero. At a delay of less than the reaction time, the inertia is positive, with a delay of more that the reaction time it is negative, that is, our "brake" is triggered in advance.

It is worth noting that the delay can not be too big. Otherwise, the interface will simply be blocked, and the user will be forced to wait until the unlock.

It seems reasonable to the author to make the delay such that the inertia is in the range from -1 to 0.