When an average user completes an action and sees the results instantly, he's not wondering if something went wrong, or if something is ongoing. They've already had UI feedback suggesting a successful result.
It goes without saying that mechanisms in the back-end need to be implemented in order for AUI to provide a great user experience.
For instance: - On error, an action should be retried. - Long-lived processes should be queued and upon failure, requeued.
Hopefully, the user won't reload the whole javascript app before this action is successfully completed and should never notice it failed in the first place.
It's not perfect, but I find that it is better. There's definitely work to be done on the error handling front. The UI should be able to clearly notify the user when something he previously did, didn't work.
Merely notifying the user, long after, that an error occurred and his work is not saved is hardly sufficient. Even assuming that the user doesn't leave your app, they could easily be off doing something else miles away from that operation.
I'm curious about what could be a better solution while maintaining that perceived speed.
And what about the second point; How useful is it to alert the user that something they thought was done wasn't long after they've stopped caring about it?
And on the second point, presumably you'd always show some kind of indication that the message is sending, just not one that blocks the rest of the UI.
This is how desktop mail clients I've used work. The sending indicator is small, but if I try to exit before it's finished sending, it blocks the exit and alerts me about it.
The real question is how would this apply to applications slightly more complicated. An app where operations have consequences beyond just the single item you are working on; were users are clicking "save" and not "send"; and users go from working on entirely different entities. It seems like this adds a lot of additional complexity for very little perceived performance gain.
In terms of the user experience, if the perf gains are small enough, then the chance that the user tries to exit while a request is in-progress should be slim, so interrupting their exit is fine as an edge case, and the gains in responsiveness should be weighed against your core user or business metrics - several hundred ms extra delay per action can have a significantly negative impact.
If the gains are large enough that the user is likely to interrupt something when exiting, then blocking the entire UI for each request is a terrible experience and you need to do something about it anyway.