Edition Smashing Magazine published an article in frontend-developer from Norway Denis Mishonov optimistic about the UI interface that does not wait for completion of the operation of the user, and immediately also moved to the final state, while the operation is still in progress. The designer said that in some cases it is necessary to use optimistic interface and when to use more traditional techniques. Edition vc.ru published a translation of the material. Three UI walk into a bar.
The first orders a drink, then a few more. A few hours later, he gets drunk, asks the score and leaves. The second orders a drink, pays for it immediately, orders, pays, and so on. A few hours later leaving the pub drunk.
Third, the interface comes already drunk — he knows how pubs, and prepared enough not to waste time. You heard about. This is the “optimistic user interface”.
Recently, discussing psychological optimization of performance at a number of conferences dedicated to frontend development and UX, I was surprised to see how little the community knows about the optimistic UI. Frankly, while that term does not even have a clear definition. In this article, we know which concept is based this theme, take a look at some examples and revise your psychological background. Then we will examine problems and key aspects of how to maintain control over this UX technique.
But before we begin, I confess, no physical thing can not be called “optimistic UI”. Rather, it is the mental model behind the implementation of the interface. Optimistic UI design has its own history and rationale.
Quite some time when the word “tweet” was used mainly to birds, Apple was on the verge of bankruptcy, and people still wrote the Fax number on his business cards, web interfaces were very ascetic. In most cases there was not a hint of optimism. Interaction with a button, for example, could happen in such a scenario. It may be quite inefficient in 2016, but oddly enough, the same scenario is still used in many websites and apps and is still part of the process of interaction for many products.
The reason is that the script is predictable and works more or less accurately. The user knows that the query went to a server (it suggests inactive button), and after the server responds, the page clearly shows the end of this “client-server-client” interaction. Problems of this kind of interaction is quite obvious.
Then came the so-called Web 2.0 has provided a new model of interaction with web pages. Its core steel technology XMLHttpRequest and AJAX. These new ways of interaction was supplemented by a loader whose sole purpose was the message to the user that the system is busy performing certain tasks. Now we dont have to reload the page after the server response.
Instead, we can update some of the already loaded page. This made the Internet much more dynamic, becoming smoother and more interesting experience for the user. A typical interaction now button might look like this.
A new model of interaction was addressed to one of the above-mentioned problems of the old method of interaction. Now the page refresh occurred without destructive actions, retaining user context and involving him in interaction much better than before. Such interaction schemes are widely used worldwide in digital media.
But there is one snag. You still have to wait for a response from the server. Yes, we can make the reaction faster servers, but no matter how much we try to speed up the system, users still have to wait. And they, to put it mildly, do not like to wait. For example, research shows that consumers experience negative emotions from slow or unreliable websites.
Moreover, according to a survey conducted by research company Harris Interactive for Tealeaf, the company, 23% of users admitted that they curse their smartphones, 11% yelling at them, and as much as 4% literally throw their phones when there is problem with Internet connection. Delays are among the problems. Even if you show very creative loading GIF, today this is not enough.
In most cases people used to associate the loader with the slowness of the system. Now the indicators associated with purely passive waiting when the user has no other choice but to wait for the server response, or simply close the tab or application. So, lets make steps to improve this kind of interaction — look at the concept of optimistic UI. As already mentioned, optimistic UI is nothing more than a method of human interaction with the computer.
In order to understand its basic idea, we stick to our scenario “, the user presses the button”. But the principle is the same for almost all types of interaction that you want to make optimistic. According to the Oxford English dictionary. Optimistic — ADJ., full of hope and confidence in the future.
Lets start with the part of “confident in the future”. What do you think. How often the server responds with error on user action. For example, if your API throws an error when the user clicks on the button.
Or maybe it keeps crashing when the user clicks on the link. Honestly, I dont think so. Of course, this may depend on the API server-level error handling, and other factors that you, as a front – end developer or UX specialist are not ready to understand. But as long as the API is stable and predictable, and the frontend UI working properly, the number of errors in response to user actions is rather low.
I would even say for sure that they will never exceed 1-3% of all errors. This means that 97-99% of cases, when the user clicks on the website, the server should respond successfully, without errors. Its worth to make it.
Think about this for a second. If we were in 97-99% of cases are confident in a successful response, we could be sure in the future these answers — well, at least much more confident about the future than schrödingers cat. We could write a whole new story about the interaction with the button: At least from the users point of view, nothing more — no need to wait to look at the broken button and rage from loading.
The interaction holistically, without gross interference of the system and its reminders about yourself. From the developers point of view, a complete cycle looks like this: Lets look at a few examples of optimistic interaction.
You are probably familiar with the button “like” in Facebook and Twitter. Take a look at the latest. To put “like” obviously, you have to press the button. But pay attention to its visual state when the user no longer presses on it and holds it on the cursor.
She instantly switches to the final state. Lets see what is happening at the moment with the development tools of our browser in the tab “Network”. Tab “Network” indicates that the request was sent to the server, but its still in processing.
The counter likes have not increased, but the color change makes it clear to the user that the response will be successful. After a successful server response counter is updated, but this transition is much softer than the instant color change. This gives the user a smooth, uninterrupted experience no conscious expectations. Another example of optimistic interaction can be seen in the social network Facebook with its special button husky.
The scenario is very similar except that Facebook updates counter instantly along with changing the color of a button without waiting for a response from the server. Although it should be noted one thing. If we see the server response time, we will see that it takes less than one second. Given that the model RAIL as the optimal response time for a simple interaction recommends that one-tenth of a second is usually too long.
However, the user does not feel the waiting time due to the optimistic nature of such interaction. This is another example of psychological performance optimization. But lets look truth in the eye.
There is still a 1-3% chance that the server will return an error. Or, perhaps, the user will be offline. Or, more likely, the server successfully returns a response, but the answer is the information additionally needs to handle the client. As a result, the user does not receive a signal of failure, but we can also consider the response as successful.
To understand what to do in this case, we need to understand why and how optimistic UI is primarily aimed at psychology. So far I have not heard that anyone complained about the above optimistic interaction in the major social networks. So, lets say, these examples have convinced us that optimistic UI works. But why it works for the user.
It works simply because people hate to wait. You can skip the following part of the article. But if youre still reading, youre probably wondering why this is happening. So, lets dig a little deeper into the psychological basis of this approach.
Optimistic UI contains two main ingredients that deserve a psychological analysis. When it comes to design optimistic UI, were talking about the best response time in the interaction with the computer. And recommendations for this type of communication has been around since 1968.
Then Robert B. Miller published a piece of work “response Time dialog box, in the communications between man and computer”, in which he describes 17 types of responses received by the user from the computer. One of these types Miller calls “response to activation of control” — the delay between the keypress and visual feedback. Even in 1968, it was not supposed to exceed 0.1-0.2 seconds.
Yes, model RAIL have not provided advice about time the Council came about 50 years later. However, Miller notes that even this short feedback delay can be too great for advanced users. This means that, ideally, the user should obtain confirmation of his action within one tenth of a second. This coincides with the time of one of the most rapid involuntary action, which can make a man blink.
For this reason a tenth of a second is perceived as a moment. “Most people blink about 15 times per minute and it takes average of 0.1-1.5 seconds,” says Davina Bristow, a researcher from the Institute of neurology at University College London, adding that at least 9 days a year we spend with closed eyes during blinking. Due to the immediate visual response (even before actually the request was completed) optimistic UI is one of the early examples of technology used at psychological optimization of performance.
But really the fact that people like interfaces that respond in the blink of an eye, shouldnt surprise us. And this is also easy to reach. Even in the past times we let go of the button immediately after pushing them, and that was enough to make the user action.
However, the inactive state of the interface means passively waiting. The user can not control the process. And its very frustrating for him. So we generally skip the inactive state of the button in the optimistic UI, we give a positive result instead of forcing the user to wait.
Lets move on to the second interesting psychological aspect of optimistic design to the UI processing potential failures. Generally, there is a lot of information and articles on how best to handle the error UI. However, how to deal with errors, we will see later in this article, the most important thing in the optimistic UI not how to correct mistakes and when to do it. It is natural for people to organize their activities in the form of blocks that culminate in the execution of any particular goal or sub-goal.
Sometimes we call such blocks “train of thought” or “stream of consciousness”, or simply “flow”. The stream state is characterized by peak enjoyment, energetic focus and creative concentration. In a state of flux, the user is completely absorbed in his activities. Tweet Tammy Everts illustrates this.
The Internet duration of such moments is much shorter. Lets go back to the work of Robert B. Miller. In the types of answers it includes:
He connects all this with the same two-second interval during which the user must obtain the appropriate type of response. Not going deep, it should be noted that this interval also depends on working memory (referring to the period of time during which a person can keep a certain amount of information in the head and, more importantly, to be able to operate it). For us as developers and UX specialists, this means that within two seconds of interaction with the user will be able to stream and focus on the answer he expects.
If during this interval the server responds with an error, the user will still be in “dialogue” with the interface, so to speak. Its like a dialogue between two people where you say something and your partner, to put it mildly, does not agree. Imagine if theres a long nodded, agreeing (equivalent to the indicator of a successful state in the UI), and then told you “no”. Awkward, though.
So, optimistic UI should inform the user of the refusal within two seconds. Armed with psychological advice on how to handle failures in optimistic UI, lets finally get back to the 1-3% failed answers. Still the most common opinion that I hear.
Optimistic UI design is a kind of grey scheme, fraud, if you will. That is, by applying it, we lie to our users about the result of their interaction. Legally, a court will probably support this point of view. However, I believe that this method of prediction and hope.
(Remember the definition of the word “optimistic”. This is where we allow some space for the part “full of hope”). The difference between “lie” and “prediction” how do you feel about those 1-3% of failed requests. Lets look at how optimistic the button “like” in Twitter behaves in offline mode.
But because the user is offline, the request fails. So, the refusal must be notified at the time of the thread States. Again, as a rule, the duration of the condition or two seconds.
Twitter reports a failure the finest way possible — simply returns the view button. An honest reader will say here, that you can go ahead and notify the user that the request is not sent, or an error occurred. This would make the system more transparent — but there is a trick or rather a series of questions.
Well, now we can agree that it all becomes a bit more complicated. At that time, as such error handling would be reasonable for, say, a major item on the website, for such a simple action as pressing the button, its redundant — from the point of view of technical development and working memory user. Yes, we must be willing to fail in optimistic UI, and we should report it as soon as possible so our optimism was not a lie. But it must be relevant to the context.
For failed Laikas thin enough to return the button to its original position, and that will be enough — only if the user is not “laykaet” status dear person. In this case, it should fire every time. You may see a different question. What happens if the user closes the browser tab immediately after you see a successful indicator, but before the server will answer.
The most unpleasant can happen if the user closes the tab before the request was sent to the server. But if the user does not have the superpower to slow down time, this is unlikely to happen. If implemented correctly optimistic UI and interaction apply only to those items that are never waiting for a server response is longer than two seconds, the user will have to close the tab during this two-second interval. Its easy to do by pressing hotkeys; however, as we see in 97-99% of cases the servers response is successful, whether the user closed the tab or not (it just means that the response is not received by the client).
So, this problem may occur only in those 1-3% that got server error. Again, how many of them are in a hurry to close the tab in two seconds. If they cant compete in the speed of closing tabs, I dont think the number will be significant.
If you dont think thats appropriate in your particular project and can have negative effects, then use tools to analyze user behavior. If the probability of such a scenario is quite high, then the optimistic limit the interaction of non-critical elements. I deliberately did not mention the cases when the server response is delayed artificially. As a rule, they do not fall within the area of UI design optimistic.
Moreover, we have spent more than enough time on the pessimistic side of the debate, so lets summarize some results concerning the realization of the good optimistic UI. I sincerely hope that this article has helped you understand the basic aspects of the concept on which the design is optimistic UI. Perhaps you would be interested to try this approach in your next project. If so, here are a few basic things to remember before you start.
As we can see, the design is optimistic UI is not new on the Internet and not particularly progressive method. Its just a different approach, a different mental model, which helps to control the perceived performance of your product. Based on the psychological aspects of the interaction between human and computer, the rational use optimistic UI can help you create a more smooth application on the Internet, and its implementation does not require too much.
But in order to make the template truly effective, and that our products are not lied to the users, you need to understand the mechanism of optimistic UI design. Send your speakers and front-end cases [email protected]