Hacker News Reader

Comment by jeromegn | Hacker News Reader

That's not an issue with the UI.

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.

View on HN

You're saying "hopefully" the user won't visit a different site in the same tab or close down the browser entirely after completing an operation. That's quite the hope.

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.

You do know that you can show the user a prompt warning them that they'll lose unsaved data if they close the page or go to another URL, right? That solves this issue.

Then what happens? How long is the user expected to sit there waiting for unsaved data to save that might never save?

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?

That's a UI issue. You can show a more prominent loading progress indicator if they elect to stay on the page after trying to leave it, so that they know when it's safe to exit.

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 problem with using email as an example is that it's too perfect. Everyone is comfortable with the concept of the outbox where messages go to be sent. Email messages are fully self-contained and independent from every other message. And while in an email client, all you do is send and receive messages, so any UI related to that is fully expected.

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.

Obviously you need to weigh the gains vs the development time required for adding and maintaining this, as with anything.

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.

You're right about that. I hadn't considered it.

I'm curious about what could be a better solution while maintaining that perceived speed.

Reply on news.ycombinator.com