Hacker News new | comments | show | ask | jobs | submit login

> "If my e-mail web app always instantaneously tells me "sent!", then I never have any idea if it actually was"

But you already have no idea if it actually arrives, let alone at the right mailbox, let alone was read/processed - until you get an asynchronous response.

And even if a web app blocks on 'sending mail', you can still suffer timeouts and disconnects, meaning the case remains of occasionally having to refresh and manually verify an action truly went through.

So if you're not concerned about those things, why be concerned about blocking on 'sent'? And if you are concerned about those things, how does non-blocking materially increase your concern? At least an asynchronous UI could automatically follow-up on a client-side send command that was never acknowledged.

Don't get me wrong; I can see an argument for operations that you truly do want to block all activity on until you receive a pass/fail. Email just doesn't strike me as a particularly good example of that.




Until the message has made it from my computer to the mail server, plenty of things I do could stop it from going out:

- I could quit my browser

- I could close my laptop

- If my train goes into a tunnel, I could lose my internet connection

…and I might never find out that the email didn’t make it, because my mail provider might never have found out that I was trying to send one. I need to know when the message is safely out of my hands.


> "I need to know when the message is safely out of my hands." So what do you do with IMAP clients? Those almost always have an async UI. Or clients operating through an intermediary (BES)?

I understand that for some messages, sure, you want an acknowledgement. I just don't see how that process is notably different for an async web client compared to what's already out there on desks and phones and particularly as compared to a blocking web UI.

If you had a blocking UI, any of those 'interruption' events could occur while you're staring at a spinner. And you (rightly) wouldn't know or feel confident that the message was sent until you re-established your connection and verified the item had made it to your sent items. Which is the same as it would be with an async client: it's an important email, so until you saw it in the Sent Items folder, you wouldn't have the warm-and-fuzzy feeling.


Not to mention that in any Internet mail system, the Sent Items folder has no real link to what's been sent; the fact that your outgoing emails also get appended to your Sent Items folder is a pure client convenience, done via a different protocol over a different connection with a different copy of the message body, and it's quite possible for them to show up even if the transmission itself failed.


Right, when things are important, you could just break the user's perception that things are happening instantaneously and give an asynchronous notification when the operation succeeds, instead of just when it fails, couldn't you?


Outlook and Apple Mail already solve this issue by showing a notification (audial or visual) when the email was sent. I don't see how the situation you're describing is any different to what has already been solved in desktop applications.

If your email never got sent to the server in the first place why could the website not use local storage to determine an error or not? Gmail uses constant POSTing with drafts here to solve that issue (not sure if it uses local storage).

I don't see why this UI couldn't show you a notification if Send was pressed and communication to the server wasn't successful. Especially since it is doing so much client side work already.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: