4 ms·

I didn’t know it was that controversial. I feel like that article is making a bit of strawman argument from the get go by talking about 1-3% failure rate from t

by aidos 6y ago

I didn’t know it was that controversial. I feel like that article is making a bit of strawman argument from the get go by talking about 1-3% failure rate from the backend. If I had a system that flaky, I’d be taking a good hard look at myself before blaming anything on my optimistic UI :-) There are other things to consider too. Like for example network failures vs backend failures. In the case of network failures you can actually notify users before they even try to take an action. So now you’re down to some diminishing case where your code is effectively wrong (maybe the client is too old), and again there are more elegant ways of handling that. Also, I bet you have the response back really quickly to make a call on it. Having a worked on unstable networks I can say that there are parts of slack’s implementation that suck - like if you try to change a message that hasn’t synced yet, they get into broken states with the edit. But that’s not the fault of optimistic UI, it’s other technical choices at play. I know you haven’t named a horse in this race, but I feel people hating on Slack for having an optimistic UI are a bit off base. Considering that I’ve sent (apparently) 2.5k slack messages in the last 30 days and I don’t recall any going wrong, I think they’ve got it right.

akiselev 6y ago
> I didn’t know it was that controversial. I feel like that article is making a bit of strawman argument from the get go by talking about 1-3% failure rate from the backend. If I had a system that flaky, I’d be taking a good hard look at myself before blaming anything on my optimistic UI :-) It's not a 1-3% failure rate for the backend, it's a 0.01-0.1% failure rate for each request between dozens of microservices each with their own bespoke error handling, each owned by a team with more political clout than the frontend guys/gals who keep reporting Sentry errors due to "UnknownNetworkError" or some other such nonsense, all wrapped in some spaghetti code frontend thats written like the whole thing is running locally.
brundolf 6y ago
On Slack it's only ever been an annoyance for me, because at least they visibly tell you when the message eventually fails to send. But on services like Twitter I feel gaslit when I've liked a tweet and then I scroll by it again later, un-liked. It undercuts my faith in the integrity of the entire interface. Any part of it could be lying to me in a way I may never find out about. Overall I strongly dislike this UX pattern. Users should have immediate feedback about actions that haven't completed, but that feedback should only tell them the truth: that the operation has begun.
TeMPOraL 6y ago
The problem with failures and optimistic UI isn't that failures happen often - it's that they're not uniformly distributed. I do not have a 1% or 0.0001% chance of experiencing failure any given message. I have 0.0001% chance of experiencing failure, unless I'm currently in a tunnel, or my ISP breaks something again, or [insert dozen other infrequent client-side failure modes], at which point my failure rate briefly hits 100%, and I'd very much appreciate if the UI didn't lie to me about it.
- aidos 6y ago
  That’s what I was saying above, you can detect those scenarios a lot of the time and handle them reasonably. Oftentimes they’re temporary and will resolve without losing any data (in a well designed system). Like I say, you can even head those off before the user knows about them. There are trade offs to consider in UX. You’re trying to make things as seamless as possible for the end user without distracting them with things they don’t care about.

by aidos 6y ago

akiselev 6y ago

> I didn’t know it was that controversial. I feel like that article is making a bit of strawman argument from the get go by talking about 1-3% failure rate from the backend. If I had a system that flaky, I’d be taking a good hard look at myself before blaming anything on my optimistic UI :-) It's not a 1-3% failure rate for the backend, it's a 0.01-0.1% failure rate for each request between dozens of microservices each with their own bespoke error handling, each owned by a team with more political clout than the frontend guys/gals who keep reporting Sentry errors due to "UnknownNetworkError" or some other such nonsense, all wrapped in some spaghetti code frontend thats written like the whole thing is running locally.

brundolf 6y ago

On Slack it's only ever been an annoyance for me, because at least they visibly tell you when the message eventually fails to send. But on services like Twitter I feel gaslit when I've liked a tweet and then I scroll by it again later, un-liked. It undercuts my faith in the integrity of the entire interface. Any part of it could be lying to me in a way I may never find out about. Overall I strongly dislike this UX pattern. Users should have immediate feedback about actions that haven't completed, but that feedback should only tell them the truth: that the operation has begun.

TeMPOraL 6y ago

The problem with failures and optimistic UI isn't that failures happen often - it's that they're not uniformly distributed. I do not have a 1% or 0.0001% chance of experiencing failure any given message. I have 0.0001% chance of experiencing failure, unless I'm currently in a tunnel, or my ISP breaks something again, or [insert dozen other infrequent client-side failure modes], at which point my failure rate briefly hits 100%, and I'd very much appreciate if the UI didn't lie to me about it.

aidos 6y ago
That’s what I was saying above, you can detect those scenarios a lot of the time and handle them reasonably. Oftentimes they’re temporary and will resolve without losing any data (in a well designed system). Like I say, you can even head those off before the user knows about them. There are trade offs to consider in UX. You’re trying to make things as seamless as possible for the end user without distracting them with things they don’t care about.