In this article I want to share with you an interesting approach of building user interfaces. But before we start, we need to dive into history and how UI worked many years ago.
The first approach
In good old days we had the following scheme.
A user clicks on a submit button, the browser sends a request (usually
post) to the server, server does some calculations and then returns a new HTML page as a response.
The only indicator that something is going on is the loader next to the address bar in the browser.
The second approach
Then some awesome folks invented AJAX that allowed us to update only part of the interface. Which drastically improved user experience. You can now show the loaders, update part of lists, tables, and all that stuff.
Which is great. But there is a thing that still is a problem. Maybe not a big one, but still: users don't like to wait.
I'll tell you honestly that I don't have any statistics but I talked to a few guys who worked in big companies, and they said that a delay of some tractions of a second might significantly decrease the number of sales.
Because users simply don't like to wait.
How it works in real life?
Imagine you order a pizza and chose cash as a payment method. The pizzeria instantly approves your order and starts cooking. And you trust the pizzeria that it will deliver your order on time. They don't even call you to approve your order.
But can they not deliver your order? Technically yes. Bad things happen.
Now, back to the UI/UX area.
First, let's roughly consider that any action that you make can be crucial or non-crucial.
If you take a loan and press the submit button, it's quite crucial that you know what the result is: whether you got the loan or not.
If you mark a to-do item done, it's not that crucial.
On the other hand, some of the operations are frequent (marking to-do items as done, hopefully), other operations are less frequent (taking the loan).
So the optimistic approach says that you can instantly tell users that their action has been successfully done even though you don't know yet the actual result.
For example, when a user clicks on the checkbox that marks a task as done, you can skip waiting till the request to the server is completed and instantly show the user that the task was marked as completed.
Even though it might not be true and it's a lie, if in 99.99% of cases such requests are completed successfully, you might consider applying such approach.
In this case it looks like your app works instantly, which is good for user experience. What's not good is that it might be a false impression.
What if the request fails?
That's a good question. In this case you should envisage that case and somehow react. The most obvious and simple way is to show some kind of a notification with an error message or something like that.
And then return to the previous state of the app (e.g. returning the task back to "not done" state).
Even though it might seem really ugly, the idea is that it should happen very rarely and it should be kind of an exception.
But the thing is: you still need to handle the case even if you don't apply the optimistic approach and wait for the response, right?
P.S. I have a short video on this topic, maybe you'll find it useful as well