But there's a third choice, which I hope is the sort of thing he meant:

as soon as you send a message, it goes into a little list on the side of your screen of things that are transferring to Google's servers. You can see it there, and you will see it go away when it has been transferred, so you know what's going on. But in the mean time, you can go back to your inbox, look at other emails, or do whatever else you want. That's how an asynchronous interface should be done.

One thing I didn't notice the article mentioning is that it's possible to have blocking only for certain parts of an interface. So if you press a "load picture" button, then maybe a gray square with a spinner will appear, but the rest of the interface should continue working as usual.

I think this is very key - you can take away blocking from a lot of scenarios without hurting user confidence/comfort if and only if you add an "aside indicator" to give the user peace of mind about important things that they want confirmation on and about the progress of the system. But, yes, they should be asides.

You mean like the "sending..." indicator at the top, that still lets you browse the UI while it's sending the email?

I think he more means like the "Background Send" lab in Gmail, which gives you progress ("Sending in background..." -> "Sent.") while still allowing you to continue to browse the UI.

The default "Sending..." notation blocks you on the same page, doesn't it?

Hmm, mine doesn't, but maybe I have that enabled. I thought that was the default behavior...

This is what MS Outlook does, as much as you might hate the program. Outlook gives you lots of information on whether and when your mail is still sending, if there was an error, etc. It is tolerant of closing the window or losing network connection. And sending a mail doesn't get in the way of doing other things in the program.

maybe i don't have experience with many other mail programs but this is what thunderbird does also, its not unique to outlook. I hate outlook because its slow (UI search and UIwise) and because its stupid enough to think that storing all its mail data in a monolithic file or small number of files is a good idea, hello corruption problems.

This is kind of what the gmail mobile web app does .. As soon as you click send a blue bar at the bottom shows there's a pending outbound message and you're free to browse other mails until it gets sent.

It's same in Outlook and other mail apps.

Yes, this is so blindingly obvious that I'm surprised we don't see it happen more often.

It doesn't block the UI and yet it still gives the user an indication when the actions are in progress/completed.

Example: the progress bars Gmail uses when you add several attachments in quick succession.

Technically, seeing the spinner doesn't block you from doing other things, if there are other UI elements that exist on the page. Problem is, sometimes, web devs make the entire page a lightbox, and you can do nothing else except watch the spinner.

One of the Gmail labs allows you to do this (assuming I understand what you mean) - it's called "Background Send".

So instead of blocking and showing the "Sending..." message, it redirects you to the main inbox and shows a "Sending in background..." message, until the message has been sent. Of course, Gmail is so fast for me that usually I'm barely back at the inbox before the message is finished! :)

But at that point, you still have a blocking call to put it on the queue at Google's servers. Which can just as well be, well, a mail server (which maintains a queue of itself). So adding another layer of abstraction on top of it kind of defeats the purpose.

Interesting point, but what happens if you click "send!" and then close your laptop. Is your message sent or not?

While your point about the server-end being a queue is true, there's an expectation once your message is offloaded onto Google's queue, they will reliably process the message in a reasonable amount of time.

How is that call to put it on the queue "blocking"? "Blocking" is being used here to describe the UI preventing the user from further interaction (such as reading a different email) until the server acknowledges receipt. You can still wait for queue acknowledgement without preventing the users from browsing to other parts of the app.

Ah, but the queue doesn't exist on Google's servers. It's purely on your computer.

So the idea is that instead of time-consuming, blocking operations, you have fast blocking operations that put things in queues, and the queues then handle the slow operations.

GMail Labs has a "send in background" feature which does exactly this.

The SINGLE biggest e-mail scaling mistake we made at AOL was to insist that the client stay in a wait state until we were Absolutely. Positively. Sure. that the message was guaranteed to have been delivered.

It ended up turning what could be a shared-nothing transaction (like every other ISP) into a network-wide two-phase commit requiring (at the time) millions of dollars of fault-tolerant hardware.

Meanwhile, guess what? You have no idea if that mail is queued at your ISP because the destination is down on a volume with a writeback cache on a RAID drive with a dead battery. You can never be 100% confident unless you have delivery status notifications, and those are pretty much dead these days.

There's a huge difference between "we have received your email and will make every effort to deliver it to the recipient" and "the recipient has received your message in their inbox". For purposes of "can I close my browser window?", the former is fine! Sounds like AOL decided on going for the latter?

Yep. It wasn't even so much a conscious initial decision as a conscious decision not to change the semantics once we got big.

At first, all mail was local, and so naturally was stored in a database, like most non-Internet mail servers of the day. It was what Dave Crocker called "rock mail" - I stick a message under a rock, and you know to look under that rock for your message.

The bigger we got, the harder that was, in the days where horizontal scaling by moving I/O to another machine was just as expensive (because the network was even slower than the disk). But we were sure that our distinction was important, and Internet-style queued mail was widely considered flaky (due in no small part to our own poor Internet delivery, no doubt). So we kept it, to the point of storing user mailboxes on Tandem NonStop machines that did multi-site replication with SQL implemented at the drive controller level.

Many of our scaling challenges were due to decisions that made sense early on and that we consciously refused to ditch; I wrote a bunch up here:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

Beautiful! Perhaps this should be a thread on its own.

Would it be bad form/karma whoring for me to submit it? I'm new..

Gmail actually has a wonderful middle-ground solution.

In Google Labs, there's a feature called "background send." I love it. It shows "sending in the background," allowing you to go do other things. If you try to close the tab/browser, it warns you the same way it warns you when sending normally.

> "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.

I hear you, but I think that this can be solved with the UI instead of a blocking approach. The synchronization status of the app (and even individual records) can be shown without preventing a user's next action. As Alex states in his article, you can also warn users about pending requests when they attempt to leave the page or close the browser.

I think this is what the author meant. Any desktop mail app does't block on send, why should a web app?

This isn't how most client side email apps work. For example, on both the Mail app for mac and ios, the UI for sending is dismissed immediately. You know when it's sent when you hear the whoosh sound (or when you look to see that there is nothing left in your outbox).

Bottom line: you can have a non-blocking UI while still communicating to the user when there are problems.

I'm sure there are other ways we can indicate that an email that was supposed to have been sent was sent without blocking the whole UI. I think that was the point. Don't block the user from getting stuff done.

This. In the case of Gmail specifically, there can actually be data loss, if you're disconnected from the network and the app optimistically closes out the message screen. So not only was it not sent, it's not even in your Drafts folder, because the web page couldn't reach the server.

Good thing that there's local storage that JS apps could be using to cache outgoing emails until confirmed they were sent.

The discussion was on the pitfalls of the user not knowing something was sent, and one of them is data loss. The fact that a web app /can/ ameliorate a lost connection is orthogonal. If the user was told the email was "sent" he's going to feel free to close out all instances of e.g. Gmail, so that clever Javascript isn't going to be running. If -- if -- he re-uses this same browser in the future, which is not guaranteed since he thinks the email was sent and may have no concept of browser storage anyhow, the email may send then, which could be hours, days, weeks or months later, unexpected behavior which will cause unexpected results.

Your sentence makes rafts of assumptions.

I think there's a better solution for e-mail. The moment it reaches the server the UI unblocks.

Later, if there is an issue with sending your e-mail it alerts you inside your browser. If you're unreachable through your web browser it sends you a text. What's wrong with that?

So what you are saying is that the server, upon receiving the email request, immediately sends a 200 OK response and sends the email request to another server (or spawns a new thread). Isn't this probably what happens anyways? In the case of Gmail it's likely a comet request that is held until the email is finished sending. Is the former method really that much better?

Or could it be that you only expect the "sent!" message because that's been the norm up until now? Would you agree that at the very least a "sending" message should be non-blocking?