Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: