Listen kids, AJAX is not cool
If you writing a user interface, make sure it responds in 1/10th of a second. That’s a pretty simple rule, and if you break it, you will distract the user. This rule has pretty much become law, never mind lore. You find it in books such as “The Humane Interface” by Jef Raskin and many other user interface guides. If you write GUI software, you are well aware of it.
I cannot find this rule anywhere in Jacob Nielson’s “Designing Web Usability". It’s not a bad book, in fact it’s an excellent one. It’s just that web interfaces are a different usability problem, one of organising fairly static information. You don’t need stopwatches or video cameras to study users in this environment. Just five test subjects and perhaps the Apache logs. This is stuff anyone can do. You only have to state that all links have to be underlined blue to start out in this community. Until now, the low level neurology has been left to the writers of web browsers. The two communities have been separated.
Except now we have AJAX.
AJAX is JavaScript based and JavaScript is usually used to add convenience and to pretty up web pages. Because sites had to work without JavaScript, usage was limited to extending the HTML or saving on the odd page request. Then came GMail. Suddenly we have lot’s of web developers “enhancing” the browser experience with behind the scenes XML fetching back to the original site. I cannot think of a worse collision of technologies than low level user interfaces with requests over the internet. The delays and failures of internet traffic are especially painful in this environment and, from the AJAX demos I’ve seen, the developers aren’t helping.
A typical demo is form validation. The first field is usually one where the user can select a new user name. Of course that username could be taken, and so this initiates an AJAX request to the server. Meanwhile I have carried on typing and am a few fields in when a dialog pops up. You don’t need a GOMS analysis to know that this is going to be extremly annoying. I dismiss the dialog, it said something about a database I think, and retype the second half of my word. I go to submit the form and find the submit button is greyed out. I eventually work out that the username has been cleared and I retype it and quickly click submit. Oh joy.
OK, this is a badly designed example and it could be improved in several ways. For example, within 1/10th of a second, I could highlight the field in some way. Maybe I could grey out the text or highlight the border of the field with a pale yellow. When the response comes back I could highlight the border as red on failure and only then disable the submit button. The highlighted field had better not have scrolled off the screen and I had better have a helpful message next to it by then. If the user can type faster than my server can respond, likely if the user is habituated to a form, then they should be allowed to submit. Otherwise habituation is lost and the interface starts invading their short term memory.
Even when the process is improved, there is no guarantee that we have enhanced the user experience. Entering a form is a familiar operation. We can do it whilst answering the phone or explaining something to the kids. The extra time fetching a separate error page may be time that I am putting to other uses anyway. Perhaps I just needed a rest. An interface that jars me out of my familiar path is probably not helping me at all. I don’t know this of course, because I haven’t measured it. But if you design such an interface, you don’t know either. You need to measure it, and this kind of usability is a lot more work than watching people click on pages.
I read more web pages than I do books and I spend more time doing it than I watch TV. I don’t think I am alone in being habituated to the way the web behaves as pages. When you write AJAX applicatons you drive a horse and cart through one of the most successful metaphors of all time. GMail can get away with it, because it’s very close to a related metaphor, the mail application. Being the new way has a price.
AJAX does have some uses. If you are exploring a dataset, you don’t want to fetch the core data again on every attempt to expand just a portion of the information. I have seen an excellent demo by a colleague with a trading system. Using a rollover it is possible to see trading history for each market indicator. Because this is an intranet system, it is responsive enough, and because the information is embedded in other explanatory content, it makes sense to use a web interface. That demo was cool, but it was a pet project not a deployed application. These put AJAX on collision course with another issue in software development, automated tests.
We have it easy as web developers. We just shovel text around and text is easy to test. Unsurprisingly there are a lot of tools to test web content. Tesing GUIs is far harder, so hard that it isn’t usually attempted. Instead a thin presentation layer is written and the calls to it are intercepted. The presentation layer still has to be tested by hand and that will delay a rollout. GUI applications are usually shrinkwrapped items, so that’s no problem for them. A web server may get rolled out twice a day. That’s a big problem for us.
More advanced tools may help a little here. Selenium and WaTiR at last make JavaScript testing possible, but it’s not easy to set up for integrated testing and you still need a browser. I haven’t yet seen an AJAX demo tested with Selenium. If anyone tries it, I’d like to know.
AJAX has possibilities, but it’s not there yet. Not as a community and not with the tools. Web developers cannot become GUI developers overnight. We need time.
36 Comments »
The URI to TrackBack this entry is: http://www.lastcraft.com/blog/wp-trackback.php/19
RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
I agree that probably form AJAX style validation should be done when submit is pressed. That way I dont need to fill out that password field again. But then again this also means that I need to learn that pressing submit no longer means the page is reloaded (which used to be the indicator that something is going on).
We have used AJAX for othre applications for a year now. Mainly monitoring of other peoples activities. Here AJAX is great, since no workflow may be interrupted unintentionally. Actually in one application we wanted to interrupt the current workflow so we had the screen blink and we played a sound file on certain events that are relevant to the person who was logged in.
Comment by Lukas — 6/3/2005 @ 8:39 am
Ajax, like everything, can be done badly. Just like your example above: I would never consider using AJAX for form field validation, especially not as the user is typing. Maybe onsubmit.
Consider another example: The user types in his username, you have a button below the username that says something similair to “Check availability.” The user clicks the button after he has typed in his desired username and it launches an AJAX sequence. Now having said that I wouldn’t only rely on the “Check availability” button. Once the form has been submitted I would check to see if the username is available again.(Or not, depending on if the user has clicked the button).
Doing this I’ve removed the step of having the user have to submit the entire form just to check if his username is available. Saving him time. Also keeping the original functionality available for people who don’t have JS support.
Comment by Hansel — 6/3/2005 @ 9:26 am
It’s interesting. I submitted a comment, it wasn’t posted but I’m assuming that you need to “authorise” the posts. It’s interesting because I was never told that my post would not be displayed… That isn’t very usabile, is it?
Comment by Hansel — 6/3/2005 @ 9:31 am
lol, broken comments. How usable is that?
Comment by Hansel — 6/3/2005 @ 9:32 am
The big web father has spoken.
Comment by Seement — 6/3/2005 @ 9:59 am
AJAX: telling it like it is…
Marcus Baker, author of the excellent PHP unit testing toolkit Simple Test lays it on the line: Listen kids, AJAX is not cool;
Marcus is goes straight for the jugular, playing the “it’s the network stupid” card and puts it in far more succinct te…
Trackback by Ajax Blog — 6/3/2005 @ 10:49 am
I think that it’s worth noting that AJAX solutions need to be tested, but this also seems rather obvious. Everything needs to be tested. It would be nice to have more open-source tools to do the testing, though; I agree. My experience is, though, that AJAX is not just glitz; it can be a huge timesaver (in terms of GUI responsiveness). We are deploying a private messaging application and were able to exponentially increase the liveliness of our application through the use of AJAX. For example, loading message lists without reloading pages, dragging messages into folders causes asynchronous copies & simple changes to the document DOM. We don’t have to be reloading pages, which means we don’t need to re-load javascript libs, CSS, headers, re-build dynamic components that wouldn’t have changed (e.g. folder trees), etc. etc. It provides a revolutionary user experience and it’s fast (without using any caching). It’s actually frickin’ amazing, and we a have a full working (close-sourced, sorry) deployable product behind that statement.
Comment by Hans — 6/3/2005 @ 2:08 pm
May be you should crash this Javascript meetup: http://www.quirksmode.org/blog/archives/2005/06/11_june_london.html
Added some further ranting here: http://ajaxblog.com/archives/2005/06/03/ajax-telling-it-like-it-is
Comment by Harry Fuecks — 6/3/2005 @ 2:29 pm
I agree and disagree….I feel like the guy in the pub in ‘the fast show’.
All technology is bad when it frist comes out. If no one attemptewd to use it we wouldn’t know what was good and what was bad. I am still evaluating it. I have a few ideas and testing it out in a simple example just to grab some product info from a database. I want it to be seamless. Just type a keyword and you get a nice list to pick a product. This is purely for internal admin use. But my example is really small. I have no GUI as such apart from a simple input box and I just populate a css styled box which has overflow set to scroll.
I think the problem is as always a new idea/technology comes about and it gets abused…look at java applets for f sake. When they came out every one thought you had to throw it all over your website.
I hjave seen some good examples. www.panic.com. dragging an item into your basket is a good idea. But we are used to clicking add to basket. But the idea of sending that to your basket without submitting makes things slick. But then you get the problem of no notification that it has been added.
I think the key is to not over do it. I think the AJAX branding is bad for a start. My boss has started to nickname products ‘built with mop and bucket technology’ with all this use of SOAP, Flash and AJAX.
So I’m not sure if you’re saying AJAX is bad or just the implementations and testing are bad/awkward.
Comment by davew — 6/3/2005 @ 4:09 pm
A case against AJAX?
Author’s NoteWarning, this is a tech-post. If programming isn’t your thing, feel free to wonder around elsewhere.
There’s been an inordinate amount of buzz about AJAX in the last few months. Everybody’s looking to do something with it. There …
Trackback by Travis Swicegood — 6/3/2005 @ 4:13 pm
I agree and disagree. Any client/server app will have problems and cause end user issues when the server is overloaded or the network is slow. This isn’t a new problem and it isn’t made better or worse by AJAX, in my opinion. I think the issue here is the speed and ease that AJAX gives you to create cool/neat user interfaces without having to learn any of the pitfalls of these types of applications. This seems to be one of the major issues with a lot of new web technologies. The ease that these new technologies can be implemented makes them more prone to bad planning and poor implementation. I have been implementing AJAX in my applications where it fits, but have not yet relied on it as a requirement for the applications to function properly. There are always exceptions, such as gmail, but they even have a non-AJAX version, if that’s even the right term. I’m still under the mentality of creating web apps to work like “traditional” web apps and then adding the AJAX features where they can help and not break the standard functionality of the application.
I would hate to see this technology get pushed off the table because of poor application design and the ranting and raving of articles that point the blame at AJAX and not the developer.
Great blog! Hopefully people will start reading more AJAX blogs and start fixing some of the issues that are coming up.
Comment by Keith — 6/3/2005 @ 4:24 pm
There are far too many generalizations here to address, but my (general) response is that there’s nothing here that’s an argument against AJAX, but instead is pointing out generic interface flaws. To highlight this, extend your form-validation example – but instead have it set up so that the entire form is present in the page’s HTML, and only the username field is initially visible. Once I type in my preferred username, an AJAX call checks to see if the name is available; if it is, then it sets the the rest of the form to be visible, and if it’s not, I get a useful error and a chance to choose another name before seeing the rest of the form.
Comparing this to the other option – the same setup, but when I submit my preferred username, it does a full-fledged form submit and then loads an entire page with the result (either the rest of my form or an error and a second chance) – the advantage is reasonably obvious. AJAX prevents the browser from having to reload the entire page, including the framing elements (a page header and footer, most likely, plus everything else like the explanation of what the form is, any sidebars, any ads, etc etc etc), and instead focuses the server call/response to the exact information that’s relevant.
I think I get that you’re mostly pointing out the problems with how AJAX-based sites have been implemented to date, but don’t paint the entire interface technology with the same brush.
(And I can’t resist mentioning that this textbox is the least-usable textbox I’ve encountered on the web. There is no size of my browser window – IE 6.0 on WinXP – that prevents enough of the right side from bleeding off the screen edge so that it’s impossible for me to know what’s hiding there. And whatever Javascript you’re using to dynamically resize it doesn’t work; I currently have this page enlarged across BOTH of my 21″ monitors, for 2048 pixels of width, and the rightmost part of this textbox immediately jumps underneath the screen edge so that I can’t see anything there.)
Comment by Jason Levine — 6/3/2005 @ 6:18 pm
(I also have to add that it appears my comment fell into a moderation bucket, but there’s no UI feedback that that’s the case. Pretty confusing…)
Comment by Jason Levine — 6/3/2005 @ 6:19 pm
AJAX Not Cool
Some observations on AJAX:…
Trackback by Firefox — 6/3/2005 @ 6:20 pm
Hi.
Yes I know I have the least usable blog of all time
. I just inherited the WordPress defaults and have had precious little time to fix it. Now I know how bad the IE stuff is I’ll install a copy of Windows and try to fix it. No, really I wiil.
Thanks for being persistent.
yours, Marcus
Comment by Marcus — 6/3/2005 @ 11:28 pm
links for 2005-06-04
The Last Craft? Marcus’ blog on Agile Web Development - Listen kids, AJAX is not cool Why AJAX may…
Trackback by Jon\’s Thoughts On Everything — 6/4/2005 @ 7:21 am
I would hope people are listening, but I think that it’s hard to generalize about AJAX with regards to specific user interface concepts… at best, it’s a useful meme for initiating an important conversation between designers and developers.
I think the problems of client/server interaction and slow networks *are* significantly greater for AJAX applications because of the embedded UI context (think about how many times you’ve hit a 401 or 501 error, and just clicked the back button).
I posted some feedback here: http://maetl.coretxt.net.nz/?m=asynchronous-rest
Comment by maetl — 6/4/2005 @ 8:53 am
I remember reading something similar to this when Flash first reared its head. People claiming how it would make confusing sites with non-intuiative interfaces (etc etc) - and hey, to a degree it did! But not everyone gets it wrong - just like GMail aren’t the only ones to get using AJAX correct. But at the end of the day the technology is irrelevant, be it Flash or AJAX (which is a term I hate btw - it’s a domestic cleaning product over here!) - if someone is going to create a poorly implemented user interface then that is exactly what they’re going to do, no matter what technology drives it. AJAX per se isn’t to blame here, but I understand why some people may be using it just because “it’s cool” without implementing it correctly.
Comment by Richard Davey — 6/5/2005 @ 3:22 am
As with any tool, AJAX in the wrong hands will lead to horrific things… look at what crappy developers do with javascript and animated gifs, yikes! when used properly these tools are invaluable.
Currently I’m in a project of porting Java applet applications from JAVA to DHTML via AJAX. Without Ajax technology this wouldn’t be possible to mimic the rich UI of a java applet. In an enterprise environment when I have to load up possibly GIGS of data, it would make initial page loads unbearable but using DATA ON DEMAND I can give a great user experience.
Ajax = A++
Comment by Jim Plush — 6/6/2005 @ 7:15 pm
Will you STOP calling it fecking AJAX, it’s a buzz word. Remote scripting has been around for ages, and the only difference between submitting a hidden frame and using an xml string is that browsers now handle the returned xml object as that rather than some string.
That idea that because a few people do not implement something correctly makes it a bad technology is farcical. Does that mean cars are a bad invention because people crash them?
I’m sorry, I know you didn’t set out to annoy people with this blog, but you’ve done it.
Comment by Ric — 6/9/2005 @ 5:20 pm
Jeez, Ric, why the vicious hatred of the term AJAX? Who cares if it’s a buzzword? Does that change its usefulness at all? I’d wager that since JJG and 37 Signals threw the term out there, the technology has gotten *significantly* more refined, better implemented, and the people who will be hiring webdesigners and content architects have gotten that much more aware of something that makes those designers and architects more marketable. What’s bad about that, again?
Comment by Jason — 6/10/2005 @ 2:23 am
Cool or not, AJAX, or remote scripting, is fulfilling requirements that would be imppossible without it. The traditional html “request-for-page” model is extremely limiting and unnatural to anyone who used desktop
applications, especially forms-type applications. It is unbelievable that people can get ‘habituated’
with such clumsy UI that is only suitable for browsing static content. I wonder how people who are used
to calculating and charting in Excel feel about the ajax-less click-and-read web. We have wasted lots of
effort trying to overcome the web model’s limited to make web applications ‘interactive’. Looking ahead, I think ajax will approve to be more significant than applet. I look forward to seeing some books on it.
Comment by Kenny Yu — 6/11/2005 @ 6:31 am
I am not a js expert -much more an AJAX expert. However, I would like to point out that you may see great improvment in usability and speed by serving a “static", “server side cached", “expires-after-much-time” page, that will load pretty fast, then use AJAX techniques to re-render and add personalization, etc.
A similar examle can be found here (even though it does not use XMLHttpRequest): Overriding caching limitations with javascript
Comment by Panayotis — 6/11/2005 @ 11:21 am
i fix ajax bugs all day long… it’s not fun
Comment by psychobitch — 6/13/2005 @ 7:34 am
“The extra time fetching a separate error page may be time that I am putting to other uses anyway. Perhaps I just needed a rest.”
What the hell is this guy talking about? AJAX is a bad thing because it’s lightning fast compared to a traditional web app on the same connection? Duh…
Comment by AgJohnson — 6/13/2005 @ 2:56 pm
Thoughts on AJAX
I was recently asked about my thoughts on Ajax, and I thought my response would make for a good, though-provoking post. Here’s how I responded:
bq. “Ajax":http://en.wikipedia.org/wiki/AJAX strikes me as one of those fads that pops up from time to…
Trackback by Ben Ramsey — 6/13/2005 @ 3:30 pm
Although I agree AJAX can be a pain in the ass, it is very usefull. However, I wish webmasters would learn to use technology such as this properly. Webmasters historically have a way of mis-using perfectly good technology, and causing problems for other developers and the end-user. Just look at HTML Tables.
AJAX is a very usefull tool, and I use it on occasion to add simplicity to certain features.
Also, for the record, GMail was far from the first Google “project” to use AJAX. AJAX is used on almost every Google page, and has been used on AdSense since the beginning. Which is all pre-Gmail. But, GMail is the biggest AJAX user, so I guess it does count.
Comment by KB — 7/16/2005 @ 11:23 am
Actually - and as I posted within the previous few days on Slashdot, AJAX is a new moniker for an older term: remote scripting.
It was a hot topic in the ASP world several years ago and was just ahead of its time.
Now, it’s got a fancier term which gives it a bit more punch and everyone is more in tune with it because of the world of Google.
Comment by phil — 8/8/2005 @ 4:13 am
You guys are nerds. Here you are complaining that a web page might take an extra few seconds to load up. What - we know you are nerds and like to read but a web page doesnt have to be all text. The web is a place for entertainment and learning. Most people have fast connections these days and those who dont are used to waiting around for pages to load.
So, give up the crap that AJAX is bad and get back to designing pages with graph paper backgrounds.
-David
Comment by David — 8/9/2005 @ 9:38 pm
Sure, poorly written apps are not cool, and well written ones are. A webpage with AJAX can possibly have more functionality than webpages without. I challenge you to do something like this chatroom without XMLHttpRequest or IFRAMEs.
Comment by Treehouse Cityguide — 9/9/2005 @ 6:55 am
Here is my “AJAX” example. I think it is fast enough for the amount of info you get per action.
A seach engine for the Project Gutenberg database
http://goatstone.com/?page=pg_search
thanks - joe
Comment by joe — 9/11/2005 @ 5:33 am
There are just too many ways of integrating AJAX to call it crap. And all your arguments weight not enough to flush AJAX down the tube. It is the future of the web - dinamically loaded data.
Comment by Martin Saulis — 9/12/2005 @ 6:19 pm
As already said in the comments above AJAX can be good in the right hands…
Back in 2000 I was involved in a a project using AJAX technologies… Only 100kB was needed to start up the system while new objects was added while using it. XML was used for the data interaction between the client and server while VML was used for most of the graphics. The only problem we had the was that the technologies was only then supported by IE and that you needed a relative fast machine. 266Mhz with 256MB was good enough… (with todays standards that’s less than a PDA) While keeping the data transfer to a minimum and complex graph calculations on the client we were able to create a system that optimized the use of all resources involved… So it only takes a bit of brain to figure out how to do it…
Comment by Joakim Olsson — 9/14/2005 @ 4:06 am
Where did “testing GUI’s is hard” come from? There are many excellent tools for testing any GUI interface that can be displayed on a CRT (VT100 emulation to WinApp Client/Server). Maybe the author is limiting his world to just free Open Source tools? Try Mercury Interactive, Compuware, or Segue toolsets - and the first two have AJAX support already. Even the hosted testing tools offered by Keynote now offer AJAX and Flash support (and Gomez is going to get there soon) so easy automated testing is not an issue for anyone who has access to decent tools.
Comment by Ron Williams — 10/10/2005 @ 1:37 am
Didn’t they say the telephone was crap? Or automobiles? Didn’t they say nobody would ever need a PC at home? Well, for those of you guys that are defending dinosaur web-technology and web-behaviors: are you still writing your posts on a huge DEC mainframe using telnet or lynx?? Let me assure you, after AJAX, there will be other new stuff, and then you’ll hear yourselves saying “let’s stick to AJAX, people are used to AJAX” - just as they were used to not speak on the telephone…
Comment by Tschaga — 10/27/2005 @ 10:40 pm
AJAX: How to Handle Bookmarks and Back Buttons
http://onjava.com/lpt/a/6293
This article presents an open source JavaScript library that finally brings
bookmarking and back button support to
AJAXapplications. By the end of
this tutorial, developers will have a solution
to an AJAX problem that not even Google Maps or
Gmail possesses: robust, usable bookmarking and back
and forward behavior that works exactly like the rest of the Web.
“AJAX: How to Handle Bookmarks and Back Buttons” explains the significant
issues that AJAX applications currently face with bookmarks and the back
button; presents the Really Simple History library, an open source framework
that solves these problems; and provides several working examples.
Comment by Kris — 11/24/2005 @ 3:07 pm