Asynchronous UIs - the future of web user interfaces

http://alexmaccaw.co.uk/posts/async_ui

by maccman • 15 years ago

485 148 15 years ago

alexmaccaw.co.uk

padenot• 15 years ago

For what it's worth, GMail proposes a lab feature that enable asynchronous email sending (i.e. `Send` is clicked, and you go back immediately to the last location, while the email is sent in background).

dearmash• 15 years ago

Nice to see people testing out <script> tags in the demo. Also glad to see the tags instead of being navigated away from the page.

Surprised a little to see the demo is actually being edited by multiple people, presumably from yc.

zachallia• 15 years ago

it's amazing how such a small slice of time can have such huge impact. definitely excited by this and other approaches to increase perceived speed!

jashkenas3• 15 years ago

Nice post. I'd like to briefly respond to the bit about the difference between Spine, which generates pseudo-GUIDs for models created on the client, later overwriting them if the server responds with a real id; and Backbone, which has a "cid" (client ID) for every model regardless of the canonical server ID.

The reason why Backbone provides a persistent client id for the duration of every application session is so that if you need to reference model ids in your generated HTML, you always have something to hang your hat on. If I have '<article data-cid="c530">' ... I can always look up that article, regardless of if the Ajax request to create it on the server has finished or not. With Spine's approach: '<article data-id="D6FD9261-A603-43F7-A1B2-5879E8C7926B">' ... I'm not sure if that id is a real one, or if it's temporary, and can't be used to communicate with the server.

Optimistically (asynchronously, in Alex's terms) doing client-side model logic is tricky enough in the first place, without having to worry about creating an association based off a model's temporary id. I think that having a clear line between a client-only ID and the model's canonical ID is a nice distinction to have.

phzbOx7• 15 years ago

Would using only a CID be a solution?

From the server perspective, it stores the real ID and the CID given by the client. In the extremely rare case where CID could be duplicated, the server could send back an error with an unique CID and the client would update itself.

That way, we're sure the ID is always unique on the server, but the client simply use a cid. In fact, the 'cid' could even be abstracted away by calling it ID. I.e. the server has 2 ids, the server one and the client one.. the client doesn't need to know the server-side one.

roc5• 15 years ago

> "In the extremely rare case where CID could be duplicated, the server could send back an error with an unique CID and the client would update itself."

That's exactly the catch.

If you still need to consider CID collisions and write code to handle a potentially-different canonical server ID, there's no conceptual or complexity savings. You're not doing 'only' a CID; you're doing all the same work.

jashkenas3• 15 years ago

Sure, if you want to get fancy you can always do something fancier.

But in many apps, your server-side IDs are auto-incrementing MySQL or Postgres ids, or even a Flickr-style ticketing ID server. You really don't want your DB to be worrying about what are essentially transient JS/HTML references.

danmaz742• 15 years ago

Couldn't you just allocate a pool of IDs to each session (open client), and let the client generate real, unique IDs directly using them? This way you wouldn't need collision detection, synchronization, etc. You only need a big enough IDs space, or a way to reuse IDs of the pool that weren't actually used by the client (by including them in new pools).

nazar• 15 years ago

I am afraid that would create a mess in a db(its just my guess). Though your idea sounds nice to my ears. The hardest part would be if session runs out of id-s I guess. One can never allocate optimal pool of IDs for every user, there are always going to be "bad cases".

bchallenor• 15 years ago

That's what (N)Hibernate calls the hilo algorithm. Compared with GUIDs, it has the advantage that IDs are somewhat sequential. (Random keys are terrible for index fragmentation.)

http://stackoverflow.com/questions/282099/whats-the-hi-lo-al...

dnagir2• 15 years ago

The use of temporary GUIDs might be ok when those are used INTERNALLY only and not exposed outside.

What happens with Spine, though, is that those IDs are used in a URL.

So in the example I get the URL for the newly created page: http://spine-rails3.herokuapp.com/#/pages/34B3CC88-32CC-4D08...

Who of you can actually access it?

That isn't right. The GUIDs should be internal only.

This leads us to the complexity of the "Async" UI in general. In order to redirect (navigate) user to a proper URL you DO need to wait for the response from the server.

But the real async UI should just allow user to do something else. It doesn't mean it should not WAIT for the server response.

Detrus• 15 years ago

But from reading the article he says that with Spine, using either the temp or final ID in your app will work. It seems to handle the temp to final ID linking under the hood.

That's assuming I'm reading the article correctly.

dnagir2• 15 years ago

That is notncorrect. GUID is only preserved within one single page. Go to the example, create a page. Copy the link and open in a new tab. You will see.

zv• 15 years ago

Nice idea, definately not new. There is one major problem with this approach - you save document, request processing, you navigate away from page, start new work, after 30 secs your request failed. Now the code complexity for you to handle this situation is high. Multithreaded/asynchronous systems are always hard.

phzbOx7• 15 years ago

The author specifically talks about that in the article saying that you can catch "leaving a page" and notify the user that there's still something pending and data would be lost.

And in the case of a big error, you can either refresh the page.. or clear the models and resend them in json format to stay sync with the server. It might be a little more complicated, but with a good framework, not that much more. I.e. multithreaded code is a pain.. asynchronous or not, it's a pain. And, in the rare case where you really need to wait for the server to answer back, well, use a loader. But there's a difference between using a loader when you absolutely need it, and everywhere. Think of how apps work on the desktop.. everything is lighting fast, but in some rare occasions, it blocks. What is better? Something that always block or something that sometime block?

gurraman2• 15 years ago

Does it also prevent the browser from crashing if there's still something pending? :)

roc5• 15 years ago

A lot of data entry is hard to unwind and correct in those kinds of situations; where a multi-step process is fully filled out and submitted based on key initial data that's later found to be wrong/invalid.

But I find that you often wind up having to write code to deal with that anyway, to handle cases of inadvertent user errors.

(e.g. I reserved a flight, room and rental car in Kansas City, KS -- but I was supposed to be reserving a flight, room and rental car in Kansas City, MO.)

So while I'm intimately familiar with and sympathetic to the challenge and complexity involved; I don't know that it's additional challenge or complexity.

tacoe• 15 years ago

http://www.d-e-f-i-n-i-t-e-l-y.com/

james332• 15 years ago

Anyone have an opinion on if Spine is the best for this as apposed to something like Backbone?

bryanh2• 15 years ago

Good discussion here: http://forrst.com/posts/Backbone_js_Spine_or_other-LZy

seiji• 15 years ago

Obnoxious: "Comments are only visible to Forrst members. Log in or Request an invite."

jashkenas3• 15 years ago

Sure, certainly ;) I'll just leave these here: http://documentcloud.github.com/backbone/#examples

... but really, if you're building a large JS app, it doesn't matter particularly which library you pick -- the main benefit is simply to get your state out of the DOM and into rich, reusable models that make it easier to reason about and manipulate.

james332• 15 years ago

Am I the only one that finds it odd that Spine doesn't do this with their own site?

phzbOx7• 15 years ago

Well the website is mostly static; that'd be overkill. Maybe the author wanted to use another library to create the documentation automatically. But, you've got a point saying that if it's not your first choice for simple static pages, it's a bit scary to use it for huge production website. I.e. Django might be overkill for a simple static page, but it's still trivial to use it for that.

tlack• 15 years ago

I have some APIs I have to call that take up to 5 seconds to return and resist caching (hotel availability, for instance). Would those delays become even more jarring with an approach like this?

phzbOx7• 15 years ago

You pointed a good example of where this wouldn't work. However, you can still make everything else asynchronously fast; and use a loader when it needs to really wait for 5 secs.

For instance, take gmail. Some part might hard to use that way.. for instance, chat communication where you somewhat need to receive the answer of the other person to show it. However, adding labels, deleting a message, etc.. that can all be made asynchronously.

jpastika2• 15 years ago

I recently used several of the techniques described, but I carefully chose when and where to implement them. For example, when a user "deletes" an item, rather than removing anything from the DOM before the request, I hide the appropriate elements, send the request, and if successful, remove DOM elements. The advantage of this approach is that the UI feels snappy, but it is easy to fall back if something goes wrong. Being optimistic that things will "just work" is alright in a fairly controlled environment, but when mobile is introduced, a mix of optimism with a soft fallback is a good approach.

huhtenberg2• 15 years ago

From the UX perspective this approach is still wrong. Any sort of operation that may fail needs to provide an intermediate indication of an in-progress activity.

For example, if an item is updated and the backend balks, but in 10 minutes, there is no clear and concise way to indicate this error to the user unless the item was marked as "in-progress". If the backend is normally snappy, then it might make sense to delay showing the in-progress indicator (so that the majority of users won't ever see it), but discarding it altogether is not a way to go.

Another example, say there is a list of items keyed by a name. I delete A, then rename B into A, and then the deletion of A fails. Ain't that a pretty mess to shovel yourselves out of?

That's not to say that there aren't certain UIs that could be made to work in "instant" fashion, but realistically there's just not very many of them there.

jpastika2• 15 years ago

You make some good points, but I don't think the approach I describe is wrong, unless like you said, I allowed requests to go on indefinitely. In the scenario you describe, it certainly makes sense to block the UI if editing uniquely identifying information is co-mingling with delete actions. I think the point we are both trying to make is that creating responsive applications should not be at the expense of the user's understanding of what is happening. This is a difficult balancing act, but perception is an important part of the UX, and whether we like it or not, if using an application feels faster it will generally be perceived as a better experience.

outside12342• 15 years ago

what are people using on the backend for apps like this? I was just starting an app with approach like this (both for these reasons and to harmonize across web and mobile clients) and I was planning on using RoR given its first class support for JSON and maturity. Thoughts?

dgeb4• 15 years ago

Rails and Node are both good options for the backend. I found Alex's screencast on integrating Spine and Rails with the spine-rails gem to be a good introduction:

http://vimeo.com/30976192

radicalbyte• 15 years ago

I did a bit of work towards this last year: the user experience is really nice, comparable to Silverlight or Flex. Only both Silverlight and Flex have a much nicer development experience at the cost of a plugin.

maximusprime• 15 years ago

Ajax is so 2005. At least use Comet, Websocket or SPDY where available.

callmeed2• 15 years ago

I'm curious how SEO will play into this trend of async UIs and JS frameworks.

In 2 of the example studies given (Amazon and Yahoo!), we're talking about content/commerce sites where rankings matter.

If you reduce load time by Xms and increase conversions by Y%, your net gain could still be negative if you get bumped to page 3 for important searches and lose traffic.

Do any of these JS frameworks consider SEO and have appropriate features built-in? (I'm thinking of things like hash fragments)

Can someone who runs a content/commerce site that cares about SEO comment on this?

notatoad• 15 years ago

this article is talking about UIs, and more specifically user-interaction driven interfaces. it shouldn't be relevant to SEO at all, because it concerns what happens after the page loads, not the initial page load (which is what the search engine sees)

callmeed2• 15 years ago

Well, the UIs have the links (like the "show" link in the example) and search engines follow links, so I'd say it's relevant ...

thaumaturgy• 15 years ago

I'm about to launch a new version of my business's website today which incorporates the asynchronous UI concept while keeping SEO in mind.

I settled on building a JS-free version of the website using the templating system I've developed for the backend, and then loading in JS at the end of page load which replaces and rebuilds the site into an interactive UI for users with JS enabled.

Assuming Google doesn't try too hard to execute JS on the page, it should get a clean, "normal" version of the site, with all text & menus and everything else accessible, while users get something a little bit different (but with the same content).

marquis• 15 years ago

We do the same thing. Our CMS delivers views based on the type of agent and whether JS is enabled or not. It allows our users who aren't able to handle all the fancy UI stuff (we have some blind users) to use the site without losing any functionality, much like Gmail static. With the proper design it's really simple to extend and add content this way.

mikeryan• 15 years ago

Both Spine and Backbone have the ability to use hash fragments via their routing mechanisms.

fiatpandas2• 15 years ago

For me, when something loads too fast, I think something broke because my brain has been wired to learn than actions through a web browser are generally not instantaneous and take a bit of time. Even if it's just a fraction of a second.

I really like this idea, but for some reason I think my brain would be more comfortable with a ajax spinner appearing for 300ms rather than an instant page load. For instance, I built something recently which loaded images on a page via ajax calls. It happened very quickly, 50ms maybe. The loading seemed way too fast so I actually delayed the images by about 300ms. It seemed a much more comfortable delay, and a few of my non-developer friends agreed.

Is there a sweet spot, or am I crazy? Let's just ignore amazon and google's data for the sake of argument.

damoncali• 15 years ago

I know what you mean, but I think you'd get over it pretty quickly with exposure to the new way.

dgeb4• 15 years ago

My solution (for an app in development) is a status indicator that shows users when they're offline, sync'ing, or sync'd.

fiatpandas2• 15 years ago

I think something like this will be key. For me, as absurd as it sounds, the delay is the indicator. That indicator needs to be replaced if actions are to become instantaneous.

wahnfrieden4• 15 years ago

This demo needs to listen to hash-change events so that it goes back when I hit back in my browser. It's otherwise a good example.

azov2• 15 years ago

There's a difference between a non-blocking UI, and the UI that hides progress of an operation that actually takes time. I'm all for non-blocking UIs, sure, let me do other things while I wait. I'm not so crazy about hiding progress. Call me a control freak, but I do want to see that the action I requested is actually completed, not just appears to be.

jeromegn3• 15 years ago

I don't think that's true for most users. Coders might think of it that way because they understand the complexity of apps.

When an average user completes an action and sees the results instantly, he's not wondering if something went wrong, or if something is ongoing. They've already had UI feedback suggesting a successful result.

wvenable4• 15 years ago

But if the operation fails but appears to succeed the user has an even bigger problem.

azov2• 15 years ago

You can say truth 90% of the time and still be considered a liar. The value of your feedback goes through the floor if it doesnt accurately reflect the state of the system. Telling the user that something is done when it isnt is plain and simply wrong.

crazygringo• 15 years ago

For truly trivial things like upvoting comments, fine.

But for sending an e-mail? Not in a million years. I want to see the spinner, and then know that it was actually sent, so I can close my web browser.

E-mails can sometimes be terribly important things.

If my e-mail web app always instantaneously tells me "sent!", then I never have any idea if it actually was -- how long do I have to wait to know before it tells me, "sorry, not sent after all." What if the app doesn't get back an error code, but the connection times out? What if the app doesn't implement a timeout?

Basically, if I don't get a real, delayed, "sent" confirmation, then I know there was a problem and can investigate or try again. But if I get an instantaneously "sent" confirmation, and then don't get a "sorry, there was a sending error" message, I can't be 100% confident that the data actually got to the server, because maybe there was a problem with triggering the error message. And since I'm a web developer, I can imagine all SORTS of scenarios that a programmer might not account for, then would prevent an error message from being displayed.

mapgrep2• 15 years ago

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.

iam2• 15 years ago

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

barefoot• 15 years ago

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?

MatthewPhillips• 15 years ago

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?

dgeb4• 15 years ago

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.

mirkules• 15 years ago

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

noahl2• 15 years ago

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.

stingraycharles• 15 years ago

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.

glhaynes• 15 years ago

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.

iam2• 15 years ago

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.

hammock• 15 years ago

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.

minikomi• 15 years ago

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.

StavrosK2• 15 years ago

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

relaia2• 15 years ago

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! :)

roc5• 15 years ago

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

Sidnicious• 15 years ago

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.

joeyespo• 15 years ago

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.

outside12342• 15 years ago

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.

jaylevitt6• 15 years ago

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.

hannibalhorn• 15 years ago

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?

jamesjyu• 15 years ago

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.

marknutter2• 15 years ago

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?

yuliyp• 15 years ago

I really dislike the attitude of "errors are rare, so don't spend much time on them" espoused by the article. Errors are rare in the sense that you will often miss them, but most of your users will run into them.

Let's say your AJAX requests have a .1% chance of failure. If your users perform a thousand actions each on average, then 50% of your users will have been exposed to your error flow. Hope it's better than "Sorry, an error occurred."

Individual errors are rare compared to successes. Overall errors happen all the time.

wanderful• 15 years ago

I wouldn't say he's saying spending less time on them. He's saying that they are the exception, so don't make the whole interface depend on the possibility of them. Proceed assuming the optimal case and when they do happen, provide a safe, friendly means of dealing with them.

HnNoPassMailer• 15 years ago

TL; DR:

  The idea is that you update the client before you send an Ajax request to the server.

"Optimistic updating", not "Asynchronous UI". The UI is already asynchronous (regardless of UI updating order).

  "request/response model".

"Pessimistic updating" -> i.e. update UI only after successful response

secoif• 15 years ago

Agreed. Optimistic/pessimistic UI communicates the concept far much more clearly.

gfodor• 15 years ago

The author managed to pick the worst possible example of a site 'doing it wrong.' First, GMail practically invented the asynchronous UI, you'd think they know what they're doing. And, of course, they do. The reason it blocks when you send an e-mail is because that way you can be sure the damn thing was actually sent.

bostonvaulter2• 15 years ago

You should try the Google Labs "Background Send" to send in the background, it's really quite nice.

tlrobinson• 15 years ago

Have you ever tried searching/labeling/filtering large amounts of email in Gmail? I did last week, and it was pretty frustrating.

inopinatus• 15 years ago

Whoop, I get to reuse a comment I made on an earlier article, almost verbatim:

"Now that the client is the MVC execution environment with the client-server interaction used mostly for asynchronous data replication, plus some extra invokable server-side behaviours, we can congratulate ourselves on having more-or-less reinvented Lotus Notes."

lkozma• 15 years ago

This asynchronous sending of emails sounds nice but it reminds me of the times when I started using email some 15 years ago. I would sit at a Unix terminal, fire up Pine, write all my emails and hit send with no delay or blocking, go to sleep and hope that during the night some script actually succeeds in sending those emails.

hesselink2• 15 years ago

Nice article overall, but this stood out for me:

> Again, this is an exceptional event, so it's not worth investing too much developer time into.

I have to disagree here. Exceptional events are exceptionally important here, since so much progress is hidden from the user. It is absolutely critical to inform the user of what happened, so their expectations aren't broken, and to cleanly recover so the application is not in an incorrect state. I think this is the most important thing to invest developer time into in an application built in this way. Otherwise, you'll lose customer confidence do to unexpected behavior or even lost/corrupted data.

alex_c• 15 years ago

Is this the kind of thinking that led to Gawker's monstrosity of a redesign half a year ago?

gurraman2• 15 years ago

I prefer to put the worker queue on the server. It's not as snappy, but it's snappy enough. And queued up operations will not get lost if the browser is closed/crashes.

_gd3l• 15 years ago

I liked this article a lot, so please don't think I'm being negative. The only thing that I sort of disagreed with was "we should optimize for the most likely scenario"

I disagree. 1) optimization is fragility 2) the extremes will inform the average

The "most likely scenario" is a visitor with a fast-enough Internet connection that a few hundred ms more won't matter.

So we should build for the extremes? Well, that's a little extreme (see what I did there?). But if you point to stats like "5-9% hit the back button...", that is not the most likely scenario...it's, well, 5% to 9% of the scenarios...

There's a documentary called Objectified that examined this with physical products, check it out. I think when developing and/or designing for speed, the "most likely" person is the least of your worries. The people still rocking slow dial-up connections are the ones who will be impacted...design and develop with them in mind.

One example from Objectified was a toothbrush. When they targeted extremes and made a handle that musclebound roidheads, people with MS, and old people could easily use (i.e. the extremes of human mobility), the "average" consumer was more than taken aware of and the extremes were satisfied.

If you develop and design for the slow browsers and the wonky old Internet connections, or at least keep them in mind, the normal folks will be more than satisfied (ideally).

Sorry to be so picky it just caught my eye and I felt compelled to chime in whilst waiting for school to end...

borismus• 15 years ago

Great post however many things don't fit the pattern. For example, lacking precognition, your search app can't know what people will search for. There are many similar UI examples, where you can't do stuff until you get input from the user, leading to a fundamentally synchronous (from a user's perspective) transaction.

dpup• 15 years ago

Gmail optimistically updates the UI in many cases, for example when starring a message or marking read/unread. Not doing so for send was a very conscious decision due to the severity of the failure cases.

That said, work has been done to ameliorate the problems and reduce the chance of data loss. Check out the "background send" lab released earlier this year : http://gmailblog.blogspot.com/2011/04/new-in-labs-background...

towhans• 15 years ago

I totally disagree with updating the UI BEFORE the request gets back. It's wrong for so many reasons. They all boil down to the fact that server state is independent from the client state.

The speed argument also doesn't hold. If requests take too long to process then you have either problem with your API (doing something synchronously on server side which should be done asynchronously, granularity problems,...) or your server is freaking slow. At worst a request should take under 100ms of pure server time. Add latency and you have 300ms.

lovskogen• 15 years ago

Don't let the tech shine through.

No regular Joe knows a 'server state' and 'client state'.

dgeb4• 15 years ago

I think that sync'ing client and server state is a concept that most people do understand. For instance, the Dropbox UI clearly shows sync'ing between client and server. Mail apps show spinners to indicate messages being sent. Asynchronous UIs and their subtle cues have been around for quite a while.

giulivo• 15 years ago

a sync problem on the server can't be worked around on the client side. You would end up introducing complexity in an unstable, unaffordable and insecure client.

also, actions like filling a page with data from a db do require the client to wait for the server to complete.

phzbOx7• 15 years ago

It's always the eternal "Good for user" vs "Good for programrers". I.e. When creating a new language, one must make choice.. should it be easier to read/use for the coder? Or easier to code from the developer side.

And, if we look carefully in the past, it seems that it always start with the "Easy for coder first" -------> "Easy for user". For example, when the first examples of Ajax came out, it was really hacky and most programmers would have never believed what they'd see today.

So, I think that you are half right with the "introducing complexity in an unstable, unaffordable and insecure client." Maybe with the actual technology and framework, you are right. But I'm certain that in the following months/years, we'll go toward the road of a better UI.

And, I still believe that it's not as hard as people think to make UI update first and update later. 99.9% of the time, the server returns "ok" or something we already knew. In the last 0.01%, we have to choose if we really want to make it to 100%.. but in these rare case, a hard refresh is perfectly fine.

n8agrin• 15 years ago

Totally agree with the premise that user actions should provide responses instantly, I was building those kinds of responsive UIs 2 years ago. But, I have a problem believing that the future of web applications is based on serializing all ajax requests and duplicating model validation on the client. Come on, this is 2011, this technique isn't new. Let's work on things that will really change the state of the art.

donpark• 15 years ago

'Asynch UI' has its uses but, in case of email, I don't think benefits to users have much substance. Yes, perception is a critical design factor we must all deal with on daily basis but we shouldn't forget that 'magic show' entertains at best and offers no real value to users. 'Magic' by another name is hoodwinking and can easily induce confusion and anger when misapplied.

weixiyen• 15 years ago

There's something to be said about user confidence and a user's confidence level directly correlating to their productivity using your app.

I could not have thought of a worse example than removing a progress indicator from sending an email. Making an "async UI" work in a fluid way that provides confidence to the end user is much harder than simply changing the state immediately and hoping that 99% of the time, it works.

Error handing can be a pleasant experience if done correctly, and in this blog post it's just an afterthought.

Here's a better way to do it:

- I click "Send Mail"

- My UI changes as if it were sent, allowing me to do other things in the meantime.

- I receive a growl notification in some other part of the UI that tells me the email has been successfully sent.

- If 1 second has gone by and I did not receive a response from the server to confirm that the mail has been sent, I will see an indicator that tells me that the sending is in progress, where the growl indicator would have been.

- If it is an error, the indicator changes and allows me to click it to go back to the mail composition view.

The concept of providing perceived performance is not new, but the details are in the execution, and you will shoot your self in the foot if you don't cover all the little details that are required to make something like this work.

Otherwise, some company is going to implement some jarring async UI incorrectly and piss off a lot of users.

Yes, blocking a UI is bad, but notifying the user of progress and task completion is a very good thing.

wrs• 15 years ago

Ah, thick clients are coming back again, and now we've reached the point where people start trying to build asynchronous applications because they're frustrated with choppy UI.

Unfortunately, pretending the network isn't there doesn't make it so. The flakiness has to come out somewhere, sometime. Either you make the user wait now, or you explain later, after you've lied about what you did. It's a tricky tradeoff.

Let's fast-forward to the end of the movie: You'll end up with a zillion special cases that are impossible to test properly. You'll decide to restore sanity by replicating the data into a client-side store with low latency and high reliability, so you can go back to a synchronous UI that your developers can reason about. All the craziness will be in a background process that syncs the client and server stores, which will still have to cause weird behavior as reality demands it, but at least the logic is contained. (I just described an IMAP mail client, or--for a Normandy-invasion-scale example--some versions of Microsoft Outlook.)

Then a new thin client platform comes along where you can't do all that complicated client-side stuff. The cycle repeats.

rsanheim• 15 years ago

Exactly. Everything old is new again.

There are significant costs for real world apps to what the OP is suggesting, and you can't abstract them away in a framework or library, as much as you may wish it to be the case.

hello_moto3• 15 years ago

It's a typical cycle in our industry. Once the community reached to the point of repeat-rehash-cycle, we tend to push things too far.

Call it second system syndrome, call it ivory tower complexity or architecture astronauts.

Some of us used to think that the overly complex solution only exist in Enterprise environment yet it happened everywhere a developer exist.

smackfu• 15 years ago

Does anyone know why the Show links are actually faster for me on the async version than the static? Shouldn't a "show" be instant either way?

jablan• 15 years ago

Stating that this is the "future of web UI" implies that most of us will have to develop duplicate logic on client and server side, possibly with different languages (as the author actually does). While he mostly talks about the validation, it seems to me that just plain validation will not suffice - we would have to keep lots of business logic duplicated as well. And "duplicate" usually meaning "almost the same, but with bunch of edge cases not behaving exactly the same way".

Am I the only one who does not like such outlook?

jaylevitt6• 15 years ago

I think the idea is that you'll develop in a framework where the client- and server-side validation can call the same code.

nickand2• 15 years ago

I'm sorry I forgot what was broken..

corin_• 15 years ago

The highlight of this article for me is:

  Amazon: 100 ms of extra load time caused a 1% drop in sales (source: Greg Linden, Amazon).
  Google: 500 ms of extra load time caused 20% fewer searches (source: Marrissa Mayer, Google).
  Yahoo!: 400 ms of extra load time caused a 5-9% increase in the number of people who clicked "back" before the page even loaded (source: Nicole Sullivan, Yahoo!).

Answered my own question but will leave for anyone else interested: but does anyone have the sources for those facts?

edit: Original source for Amazon stat (possibly also Yahoo, or possibly it's just referenced) is a powerpoint by Greg, downloadable at http://7303294208304035815-a-1802744773732722657-s-sites.goo...

edit 2: The Google stat is from a speech at a 2006 "Web 2.0" conference, referenced by Greg at http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....

edit 3: Yahoo stat from Nicole's presentation here: http://www.slideshare.net/stubbornella/designing-fast-websit...

patio11• 15 years ago

I love the feeling of immediacy users get when using AJAXy applications over render-view-submit-rerender applications, and my users actually comment on this to me (not in as many words, but they say that it is "light", "fast", "easy to use", etc), but the development costs of going the extra mile to asynchronous strikes me as likely to be very high indeed. It already costs me about ~5x development time to do something client side versus server side, just because of how much time wiring up Javascript takes. (And praying it doesn't break, because Javascript is orders of magnitudes harder to test than Ruby is.) The costs for rewriting the entire app to exist simultaneously in the browser and the server, and to magically never fall out of sync even when users do something user-y, scares the heck out of me.

The whole toolchain for reasoning about stuff happening in the browser is still laging a few years behind what we have on the server, which is a related but larger problem. We have Firebug, which gets us truly revolutionary features like "output log messages... in a browser!" and "inspect the internal state of objects in memory... in a browser!" But many of the rest of the cutting edge developments from the 60s and 70s haven't quite made it to the browser yet, or they're not yet at the point where they can be used by mortals. (Selenium: I want to love you, and yet I can't actually use you for anything because you break my brain.)

retro212• 15 years ago

Did you try http://www.funcunit.com/ for JavaScript testing?

hello_moto3• 15 years ago

Is there a better JS unit test framework where I can run it from the console without having to open the browser?

A few CI tools don't work well with the "requires browser to run test" paradigm.

I understand that means there might be class of errors that the no-browser test would not be able to catch but it's still a huge win.

marknutter2• 15 years ago

And then some young-gun will come along and create Ruby on Rails for the client side and all these frustrations will be abstracted away. Something being hard to do doesn't mean it shouldn't be pursued.

hello_moto3• 15 years ago

It's kind of hard to agree with your statement albeit it has some merits.

Rails is a glue of a bunch of things. It's not like it doesn't exist in other environment.

Meanwhile, the state of JS testing is still far behind. Like really really far behind.

Once you get that sorted out, you still left with common set of libraries. Still a long way to go really.

Not to mention that the whole client-side thing is ripe for a change (depending on whom you talk to).

exclipy• 15 years ago

This is exactly the philosophy that Google Wave had, except they called it an "optimistic" UI - it always assumes that every action will succeed on the server side.

It solved all these problems mentioned and more - for example, it used the operational transform algorithm to merge your changes with those of other users on the same page and update the client state to reflect this asynchronously. It also could continue working without a network connection - it'd just keep queuing your requests, and when you plug in the network again, it'd just start working again, albeit possibly with a big backlog of changes to merge together.

These are the kinds of problems you might have to start thinking about if you want to go down this path. Remember that Google Wave died from its own complexity.

nickand2• 15 years ago

If I am loading a list I want to know when it is done.

flibble• 15 years ago

I couldn't agree more. For connected web based games this is a requirement. https://www.switchpoker.com/client makes use of asynch calls to give the appearance of an extremely responsive UI.

gizzlon• 15 years ago

I wonder if people have thought through the security problems and implications of moving state to the client side..?

Actually, that's a lie, I'm sure they have not ;)

jqueryin• 15 years ago

From reading through the various responses on this post, I believe one very feasible and worthwhile solution to asynchronous UIs is to maintain what has been referred to as a transaction log somewhere in the UI for the user to be able to see containing all requests and their subsequent status/response message when the proper event fires. This would assume that any actionable items would trigger immediate changes to your UI in favor of the "success" case. It would be up to you as to whether you'd like to revert that scenario in the scenario that a failure occurs in an event response.

This would remove the dreaded "blocked UI" scenario because everything appears to happen instantaneously, however there would be failsafes in place when something goes wrong (the infrequent scenario).

To me it seems more a matter of order reversal in how we handle AJAX calls (assuming you aren't using an async/evented system).

I can, however, think of downsides. Take, for instance, a scenario where you may have a nested tree of actionable items that may have prerequisites on the other's completion. You could chain the events, but you might end up with a queue unbeknownst to the end user. Worse, a failure might occur at the parent level which leads to failures for all subsequent calls. I myself am not sure what the good alternative to this might be in terms of non-blocking UIs.

jtmille3• 15 years ago

I really appreciated this post. Everything Alex mentioned in his article I learned through trial by fire doing mobile development. Performance was critical and UI responsiveness was a must. It was then that it dawned on me that all the same techniques could be applied to a web application just like Alex mentioned. Most web developers seem to get stuck in the framework rut. All the tools and techniques are there to build something fast and responsive.

If there is one thing I can truly appreciate about what he is trying to do with spine it's the client id generation and request queueing. This has got to be the core of what makes good "AUI". Every developer dealing with remote requests should have this in their back pocket. 101 stuff.

Asynchronous UIs - the future of web user interfaces

Related Stories