5 ms·

> This interaction and updating phase is often asynchronous by nature, as the app waits for a response from the backend whether to update the data or not. The u

> This interaction and updating phase is often asynchronous by nature, as the app waits for a response from the backend whether to update the data or not. The update is usually based on the success of the action triggered by the user. > An Optimistic User Interface is when a user triggers an action and the UI updates immediately, even though there may be a request pending. This is also called "lying to your users"

darzu 8y ago
That's too harsh. It depends on the operation and the probability of success. If the operation is non-critical and succeeds 99.99% of the time, it makes perfect sense to show the user an "optimistic" result. This is the same principle that multiplayer games use. When a game character is moved in a particular direction, the client shows "optimistic" movement before the server confirms the movement. This is the difference between a playable and unplayable game in many cases.
braythwayt 8y ago
My bank lies to me all the time. I deposit a cheque, and it puts the funds in my bank. Once it decided I was trustworthy, it even let me spend the money right away. It turns out, though, that it might take _weeks_ for the cheque to clear, and they reserve the right to reverse the deposit and ding me for an NSF fee at any time. Users often prefer optimistic processes to ACID trips.
pault 8y ago
Generally speaking, optimistic updating should have some type of UI to subtly display the network status so the user is aware of what is going on under the hood, but the network activity doesn't block them from performing additional actions. This model brings a whole boatload of complexity to your implementation however, so be prudent with where and how often you apply it.
- bpicolo 8y ago
  It's often not worth the overhead to develop for small bits like `likes`. For small, 30-50ms requests they're not going to notice anything either way. A brief flash of an icon isn't useful.
  - dcd0101 8y ago
    If we’re only talking about operations that are fast, nearly bulletproof, and trivial, then I’m even less sold on the idea. In the article it describes reverting the state of the component if the action fails, asynchronously. IMO that’s much worse than briefly representing a progress state for a few ms.
  - fenwick67 8y ago
    > It's often not worth the overhead to develop for small bits like `likes` Two things. 1. Likes are not a small detail of a social network app 2. If you're handling a failure state when the HTTP request comes back (like the author does), handling the success state is just an `else`
mamcx 8y ago
A good example of a "correct" way to do this is whatsapp. It signal when 1)it send 2)it get accepted 3)it get read Is optimistic, but is not lying. But if it make believe something have happened whitout proper feedback....

darzu 8y ago

That's too harsh. It depends on the operation and the probability of success. If the operation is non-critical and succeeds 99.99% of the time, it makes perfect sense to show the user an "optimistic" result. This is the same principle that multiplayer games use. When a game character is moved in a particular direction, the client shows "optimistic" movement before the server confirms the movement. This is the difference between a playable and unplayable game in many cases.

braythwayt 8y ago

My bank lies to me all the time. I deposit a cheque, and it puts the funds in my bank. Once it decided I was trustworthy, it even let me spend the money right away. It turns out, though, that it might take _weeks_ for the cheque to clear, and they reserve the right to reverse the deposit and ding me for an NSF fee at any time. Users often prefer optimistic processes to ACID trips.

pault 8y ago

Generally speaking, optimistic updating should have some type of UI to subtly display the network status so the user is aware of what is going on under the hood, but the network activity doesn't block them from performing additional actions. This model brings a whole boatload of complexity to your implementation however, so be prudent with where and how often you apply it.

bpicolo 8y ago
It's often not worth the overhead to develop for small bits like `likes`. For small, 30-50ms requests they're not going to notice anything either way. A brief flash of an icon isn't useful.
- dcd0101 8y ago
  If we’re only talking about operations that are fast, nearly bulletproof, and trivial, then I’m even less sold on the idea. In the article it describes reverting the state of the component if the action fails, asynchronously. IMO that’s much worse than briefly representing a progress state for a few ms.
- fenwick67 8y ago
  > It's often not worth the overhead to develop for small bits like `likes` Two things. 1. Likes are not a small detail of a social network app 2. If you're handling a failure state when the HTTP request comes back (like the author does), handling the success state is just an `else`

mamcx 8y ago

A good example of a "correct" way to do this is whatsapp. It signal when 1)it send 2)it get accepted 3)it get read Is optimistic, but is not lying. But if it make believe something have happened whitout proper feedback....