Synchronous vs. Asynchronous Interaction - Visualized
I have been speaking out against the use of synchronous interaction principles on this site, and other places. It is has mostly been trough to use of words, but I really wanted to illustrate it instead.
The difference between asynchronous and synchronous interaction is that when it is synchronous you have to do each step at the time. You cannot do two things - or what is called multitasking.
Take uploading a file. To do this, you have to:
- Select the files you want to upload
- Click the upload button
- Wait for the files to be uploaded
- Work with them
You cannot chose to upload another set of files while the first ones are being uploaded, nor can you start to work with them (like adding tags) before the upload process has completed. The interaction is synchronous.
With asynchronous interaction you can do other things while the system uploads the file.
Or take a kitchen, which is asynchronous by design. While you are e.g. baking bread, cooking spaghetti and frying some meat - you are also making the salad. The result of this multitasking behavior is that you can prepare a nice dinner in about 30 minutes. If you had to do the same in a synchronous fashion it would take hours, and most of the food would have gotten cold before everything was finished.
Humans are asynchronous by nature
Working in a synchronous fashion is not something we as humans are accustomed to. But, when we are using a computer, and especially the web, almost everything happens this way.
Desktop applications has been able to do multitasking for many years (remember the days when the OS couldn't multitask. Everything took ages). But, it was not really until the "discovery" of AJAX that we have had the ability to multitask on websites/web applications.
The problem is just that most applications do not take advantage of multitasking. 98% of all applications (even most AJAX applications) works as if it was never invented - they have synchronous interaction. The result is that computers feel unnatural to work with and it really hurts our productivity too.
But, let me show you how a asynchronous interaction can improve a web application.
Flickr X
Here is a concept for Flickr - using asynchronous interaction.
See a high-res version here.
The special thing about this application is that I do not have to wait for anything to complete. I can keep working, and in this example I am doing 3 things simultaneously.
1: Uploading files
Instead of having to wait for all the files to finish uploading, each file is uploaded and updated independently. Here I am uploading 6 files, and as each of them finishes (or even while they are being uploaded) I can work with them - like adding tags, rotating, adding notes etc. If I like, I can choose to upload more - the new files will simply be added to the queue. I can even cancel uploading a specific file without having to stop the entire upload process.
2: Rotating
While uploading I noticed that three of my images needed to be rotated. In this example I have already chosen to rotate two of them, and I am currently rotating the image on my screen. Again, I do not have to wait for the image to finish rotating (which can take some time with high-res images). I can move on to rotate other images or do other things.
3: Adding tags
While my images are being uploaded and others are rotated I have started to add tags to the image I see on the screen. Again, this is possible because of the asynchronous nature of this. I could also add notes.
I can even work with on images that has not been uploaded yet (although with questionable usefulness).
Use it!
This is just a simple example, but asynchronous interaction can make most applications better. The are many advantages. The primary one is a productivity boost. Multitasking applications are much faster to operate. It also helps support people workflows, as you are not limiting them to a linier path through your application.
The way to make asynchronous interaction is to separate system operations from the people. Every time the system does something, allow people to carry on with their work - to do other things. Every time you feel the need to add a progress indicator, allow people to continue working instead.
Comments
Thomas Baekdal - Jul. 19, 2006
Christopher: Yes, those are valid points.
I do, however, wish to clarify something in regards to your 4th point. The multitasking I am talking about is not human multitasking, but system multitasking.
You are quite right that we (humans) usually fail when we try to multitask - or at least become very unproductive. Kathy Sierra of Creating Passionate Users have written to good articles on the subject - Your brain on multitasking and Multitasking makes us stupid?.
I have long been advocating against human multitasking, as it makes us unfocused, stressed and generally not capable of making great products.
When I write about asynchronous interaction here, I advocate for the use of system multitasking. Instead of waiting for the system to complete an operation, or do any kind of human multitasking for that matter, we should put the burden of our work on the system - allowing the interaction to progress free of obstructions.
Jesper Rønn-Jensen (justaddwater.dk) - Jul. 25, 2006
Thomas,
very nice article. Your points are (as usual) good, solid and easy to understand.
In my opinion, the discussion about multitasking is irrellevant: This is not about multitasking. This is about not waiting for the system.
As I see it, the productivity gains come from reducing human waiting time. This is very important, because it's not only about the time wasted waiting. Human brain also adds frustration which lead to even worse things than just waiting.
By the way, Christopher's example (renaming while saving a file) could easily be solved be the techniques you describe. (start using another unique system key for the filename, and you're half way).
I remember Jef Raskin's book The Humane interface and also Bruce Tognazzini talking about how many things that system designers take for granted are actually introduced for the sake of the system, not for the sake of the user. The eyeopener for me was when Tog mentioned that a system could easily work without a save button. (he's been saying that since before the Palm Pilot, which has no save function).
Thomas Baekdal - Jul. 26, 2006
Jesper, I cannot say I disagree with you, because I don't, but I do not agree with you either.
It might be that "multitasking" is not best way to describe this, but I think there is much more to it than just "not waiting for the system"
I mean, many products are strikingly fast to from a technology point of view, but are still very complex to use. Of cause, a responsive system will make for a better user-experience, but not necessarily a better usability.
I think that we need to also look at two other things, besides the speed of the system:
1: Automation. How can we replace a manual task, by something that just happens? How can we remove the need to use mental energy on non-essential tasks.
2: Computer as a secretary. How can we put the burden of work on the computer, so that we only need to decide and give directions.
This is an important point for me, because the computer is not really helping us the way it should. If we look at the workload involved in, say, writing a letter. The computer has made this faster, more flexible, and powerful - but, it also involves more work. We need to look at productive when planning the interaction. How can we solve people problems in a non-obtrusive flow?
Jan-Gerd - Aug. 9, 2006
On flickr, you can at least edit tags, description, notes and title= at the same time. That's a start. I think many users may be confused by completly asynchronous Sites, simply because they are used to a "synchronous Web" (It's a series of tubes!). If they could add a tag to a picture that is not yet uploaded, they would think something went wrong - and close the site alltogether.
Thomas Madsen-Mygdal - Aug. 14, 2006
Great article.
We've been playing with some of these concepts with 23, http://23hq.com for some time.
Started out as hack - "edit-as-you-go" was the term - but has since become the core philosophy of uploading.
The function seems to deeply change the upload concept - people are in fact sitting waiting trying to keep up to speed with describing, annotating, tagging, etc. in time for the next photo is ready.
Even tagging/annotating 30-40 files becomes a "natural" process in sync with the computers flow of uploading there's the human flow of annotating.
Simply more people annotate/describe their photos because of the natural upload process.
We'll be adding more possibilities to "do stuff" with the photos - and see how far people can grasp the concept. We're currently divided between doing individual actions on photos compared to doing global actions on photos (of which some might not even have been uploaded yet). My intuition says me that's pushing the mental model of people a bit too much...
Anonymous - May. 4, 2007
hi
Anonymous - Nov. 7, 2007
Hi, how u doing?
Sanju Bala - Aug. 28, 2008
I think , asynchronous provides us multitasking but human is not so fast to do the many things at a time, he is only able to make two or three things that's it so no need of thousands of task done immediately, he can wait. So synchronous is better than asynchronous. At least it provides efficiency and satisfaction of nice completion of task.
Published: Jul. 9, 2006 in Usability
FaceBook
Twitter
LinkedIn
YouTube
Flickr
Christopher Fahey - Jul. 18, 2006
Good article. Several thoughts/points:
1) If you're designing a web site, occasionally pretend you're designing a desktop application (or even a video game). That will get you out of the synchronous/page metaphor and immediately expand your horizons.
2) For intensive CPU actions, it's sometimes advantageous to lock up the system from other interactions.
3) Similarly there are also sometimes logical reasons to prevent asynchronicity -- for example renaming a file at the same time you are saving it or moving it could lead to lost data.
4) It has been shown that multitasking does not necessarily correspond to productivity boosts, and I think I've seen studies showing the opposite is often intensely true (personally, I've seen this to be true in my own work habits as well). Sometimes simply waiting for an application to finish a process and then continuing on to the next task is ultimately more efficient than if the user were to spend that "down time" going on to a different task and losing the continuity of the original chain of tasks.