Hacker News Reader

Comment by noahl | Hacker News Reader

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.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com