[jpastika]

I recently used several of the techniques described, but I carefully chose when and where to implement them. For example, when a user "deletes" an item, rather than removing anything from the DOM before the request, I hide the appropriate elements, send the request, and if successful, remove DOM elements. The advantage of this approach is that the UI feels snappy, but it is easy to fall back if something goes wrong. Being optimistic that things will "just work" is alright in a fairly controlled environment, but when mobile is introduced, a mix of optimism with a soft fallback is a good approach.

[huhtenberg]

From the UX perspective this approach is still wrong. Any sort of operation that may fail needs to provide an intermediate indication of an in-progress activity.

For example, if an item is updated and the backend balks, but in 10 minutes, there is no clear and concise way to indicate this error to the user unless the item was marked as "in-progress". If the backend is normally snappy, then it might make sense to delay showing the in-progress indicator (so that the majority of users won't ever see it), but discarding it altogether is not a way to go.

Another example, say there is a list of items keyed by a name. I delete A, then rename B into A, and then the deletion of A fails. Ain't that a pretty mess to shovel yourselves out of?

That's not to say that there aren't certain UIs that could be made to work in "instant" fashion, but realistically there's just not very many of them there.

[jpastika]

You make some good points, but I don't think the approach I describe is wrong, unless like you said, I allowed requests to go on indefinitely. In the scenario you describe, it certainly makes sense to block the UI if editing uniquely identifying information is co-mingling with delete actions. I think the point we are both trying to make is that creating responsive applications should not be at the expense of the user's understanding of what is happening. This is a difficult balancing act, but perception is an important part of the UX, and whether we like it or not, if using an application feels faster it will generally be perceived as a better experience.

[huhtenberg]

> ... it certainly makes sense to block the UI ...

There's no need to block the UI. It is perfectly sufficient to disable just the affected item.

> ... creating responsive applications should not be at the expense of the user's understanding of what is happening.

In this case you are bound to repeat the Microsoft's Distributed COM fiasco. They tried to blur the line between accessing in-process, in-machine and over-the-network services behind an abstract API. It was nice in theory, but practically it was a disaster. It is really hard to write a meaningful app - even an asynchronous one - when an API call can take between few ms and several seconds to complete.

In case if the parallel is not clear - their idea was the same as yours - "devs need not to know what's happening". This does not work. Devs need to know, as do users in your case. Perception is indeed an important part of the UX, no arguing there, but the UI needs to be designed in a way to preclude them from making false assumptions that would prove frustrating and disastrous should the backend go kaput. Faking snappiness does the opposite, it makes believe.