Recently, the concept of optimistic UI is gaining popularity. In my opinion, its advantages are greatly overvalued, and the flaws are hushed up. In this article, I want to more clearly demonstrate the flaws, as well as offer a decent alternative, which I called the Realistic UI.

TL; DR

→ Demonstrating the concept of Realistic UI
→ Source Code Repository

Background

In addition to Realistic UI, I was able to recall three other ways of interacting with the backend on the web and mobile.

1. "Traditional" UI

Before spreading AJAX, almost any action needed to reload the page, so the UI looked like this:

This approach is now quite common, but it is obvious that modern technologies allow us to achieve a much more pleasant UX.

2. "Block-the-world" UI

After the distribution of AJAX, developers were able to step forward and implement the ability to perform remote requests without having to reload the page in the browser for individual operations, as it was in the "Traditional UI". However, such web applications still remained “thin” clients in terms of architecture and did not have the ability to manage their state. Thus, switching to another page could interrupt the execution of a remote operation, and the best solution to this problem was blocking the interface and demonstrating the load indicator on the client side.

3. Optimistic UI

Further, with the advent and spread of the Single Page Application concept, it became possible to develop a fat client and manage the state of the application. Optimistic UI assumes that we, the developers, know what should happen as a result of the operation, and can immediately update the interface as if the operation had been completed successfully, and at that time, perform the corresponding AJAX request in the background. In 1–3% of cases, the operation will fail, and we will simply show an error message. Optimistic UI is actively promoted by Facebook, and their solutions like Relay use this mechanism by default.

Optimistic UI Criticism

Optimistic UI may seem like a good and fresh idea, but upon closer inspection it becomes clear that its use, if justified, in very rare cases. I can name the following problem:

1. Separation of operations into "important" and "unimportant"

Optimistic UI is not suitable for "important" operations, for example, if you buy movie tickets, then you need to know 100%, whether it happened, or an error occurred. Also, the Optimistic UI is not suitable for those operations for which the server forms part of the data that we cannot predict on the client side, such as unique transaction numbers.

This creates several problems at once. First, the service almost always contains several "important" operations, otherwise it is not very clear why it exists in principle. And this means that developers will have to implement and maintain two different ways of interacting with the backend: for "important" and "unimportant" operations, which will require more time and effort. On the other hand, users also need to get used to the fact that some operations are performed in one way, and some others. This can be a source of misunderstandings and problems, which in turn can increase user support costs and lead to a deterioration in UX, respectively.

Secondly, there must be a person who decides which operations are “important” and which are “unimportant”. Any decision will always be subjective. For example, a “like” may seem like an “unimportant” operation, but in fact, for some users of the service, the lack of likes can spoil the mood, and for someone a good evening. The very need to make such decisions takes time and effort, so it would be better for both developers and users to have a universal solution that can be used for all types of operations.

2. Problems of data synchronization, transactional and conflict resolution

Optimistic UI works well with the offline mode in theory. In practice, there are many problems that are well known to mobile developers.

First, transactional.

Yes, for the messenger the order of operations may not be decisive, but for other types of applications it is often not the case. And this means that it is necessary both on the client side and on the server to come up with mechanisms that would ensure the correct order of operations, which will require additional efforts and time.

Secondly, let's say the client has performed five different operations offline and is now trying to synchronize them with the server. The first two were successful, and the third ended in error. What should be done in this situation? Stop running? Roll back the first two successful operations? Try to do the fourth and fifth? And if they depend on the performance of the third? And how to report the problem to the user?

As we see, many questions appear, each of which requires thought and often an individual approach. Such solutions are very poorly supported and unimportantly scaled, since they are more a state of art than a replicable solution or a set of best practices. Also, there is a huge number of possible sequences of user actions, which makes the process of testing various combinations into hell.

3. Cheating user

When we demonstrate to the user that his action has been completed successfully, although in reality it is still being executed, we create the feeling that our system cannot be trusted in case of failure.

Realistic UI

Disclaimer

Although I came up with and defined the concept of Realistic UI, I do not claim the discoverer's laurels. As the principles of REST were defined more than 10 years after the widespread use of the Internet in its current form, the ideas of the Realistic UI can be found in various projects now. In particular, Azure and Google Cloud Platform control panels are implemented in accordance with the principles of Realistic UI.

Principles of Realistic UI

1. Only part of the user interface is blocked. For example, if a user fills out a form and presses the “Submit” button, no one will interfere with him going to another page or performing another independent action, provided that it is impossible to change the form data until the completion of the remote operation.

   
   

2. The UI contains a widget that displays all active operations. Using this widget, the user can track the current status of operations, as well as go to the appropriate page and / or part of the page if desired.

   
   
3. The UI contains another widget that displays the operations that failed. From this widget, the user can restart the execution of a failed operation, go to the corresponding page and / or part of the page, or ignore the error.

Realistic UI vs. Optimistic UI

Realistic UI provides a single mechanism for all types of operations.
Realistic UI does not deceive the user.
Realistic UI allows you to perform several operations at the same time, but ensures that they will be performed independently of each other, which greatly simplifies the process of conflict resolution.
Realistic UI gives the user a complete overview of the operations performed and performed.

Thus, Realistic UI takes the best features from all approaches of interaction with backends, but is devoid of most of the disadvantages.

Conclusion

I am very worried about the existing wave of HYIP around the concept of Optimistic UI, and I hope that I will be able to provoke a discussion that would be more objective in its assessment.

In order to demonstrate the ideas of Realistic UI in practice, I implemented a small Proof Of Concept, which can be viewed by clicking on the link .

I posted the source code for the demo on GitHub .

If my arguments seemed convincing to you, I will be very grateful for the retweet and the asterisk . I believe that it is extremely important to convey these ideas to colleagues, since the existing problems of the Optimistic UI can bring a lot of harm to those teams that decide to implement them without realizing all the possible difficulties.

Of course, I will be very happy with both objections and criticism in the comments, which will make the concept even better.