Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies like images and cookies, native support for the XMLHttpRequest (XHR) object in modern browsers has made it easier than ever to make web apps more responsive and more like their desktop counterparts. This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology.
So what’s a well-intentioned web developer to do? Stop and think about the following before dropping that sudsy, lemon-scented bomb on unsuspecting users.
Content or Action?
Using XHR circumvents the browser’s history. As a result asynchronous scripting is most appropriate for actions and transient or conditional data—not navigating content. XHR doesn’t break the back button, misunderstanding user expectation does.
Search results, tags, comments, and data validation are all good examples of transient data. All are given to flux and make perfect candidates for manipulation by AJAX or similar technologies.
On the other hand, avoid replacing traditional navigation with XHR. Doing so breaks an inherent functionality responsible for the success of the web: Universal Resource Locators. Unless we reinvent the wheel and restore this functionality ourselves (hidden iframes and fragment identifiers anyone?), it is impossible to link directly to content included with XHR.
Both HiDefDVD.com and Microsoft’s recently launched Windows Live Shopping make this laughable mistake. By relying on XHR for navigation and providing no alternative they effectively cede any search relevance to the market leader Amazon who appropriately uses the traditional navigation model (remember at the time of this writing search engines don’t parse JavaScript).
To avoid repeating a similar mistake, try this litmus test: If refreshing a page immediately after that page has been updated by remote scripting results in an essentially identical page then you’re doing okay. If not, head back to the drawing board.
Communicating Change
While not directly tied to asynchronous scripting, page content is often replaced unceremoniously in an application that uses XHR. Without the intermediary blank page followed by a browser’s built-in progress indicators informing users that something is happening, the responsibility now falls on the developer to inform the user of pending changes.
Spinners, hourglasses and progress bars build upon users’ experience with desktop applications and indicate that an operation is pending completion. When inserting or replacing content, animation and movement go a long way towards capturing attention and alerting the user that the page has been updated.
These purely visual techniques fall short when the modified content has been scrolled off screen (imagine using an AJAX-ified mobile app) or with a screen reader. Potential solutions to this shortcoming are still being explored but parallels already exist on the desktop. When a background application requires attention in Mac OS X, it may chirp and bounce the dock icon to alert the user. Keyboard shortcuts can be used to navigate to the needy application. Using access keys and audio triggered by an XHR callback function it is possible to mirror this behavior.
Progressive Enhancement
In DOM Scripting, Jeremy Keith coined the term “Hijax.” He suggests that we plan and develop using the traditional “links to GET/forms to POST” model without relying on JavaScript. Then we hijack those links and forms with asynchronous scripting calls using the onclick and onsubmit event handlers, allowing us to bypass intermediate screens and refine existing interaction.
This type of development favors using AHAH or AXAH over JSON or XML-based flavors of AJAX. By including the same HTML generating file that we plan to request using XHR, we keep our business logic out of the JavaScript and on the server where it belongs.
There are a number of JavaScript libraries out there that encapsulate XHR. When choosing a library or framework for our applications we need to be asking ourselves hard questions. A framework might make our lives as developers easier but will it also facilitate making bad decisions? When taking the Hijax approach we may notice that while XHR allows you to POST data to the server, when using an HTML link we don’t actually make use of this feature. Why? There is no analogous to POSTing with a link in the traditional model, that behavior requires an HTML form. We need to keep in mind that a library that allows us to do so allows us to make a mistake that could disable our application when XHR is not supported or JavaScript is disabled.
Once these ideas about AJAX soak in we’ll be producing clean web apps that play nice with search engines, desktop and mobile browsers, and web-enabled dish-washers alike.
Like this article? Digg it!
[…] Responsible Asynchronous Scripting by Shaun Inman on Vitamin. […]
This article reminds me of a traditional high-school prank. You slash open a couple bottles of dish-soap (Dawn, Ajax, etc) and toss them into the city’s main fountain at night, creating a foamy mess for residents in the morning. We termed it ‘Dawning the Fountain.’
So, within your web developing careers, children, don’t ever Ajax the fountain, or you’ll end up with a soapy mess.
What about Robert Nyman’s AJAX script?
http://www.robertnyman.com/2006/02/08/ask-ajax-source-kit/
Important is:
- when do you need it? Do you need it? Does it improve the user experience? Can it improve performance?
- can it work cross-browser, is there a fallback thus progressive enhancement
Robert’s ASK seems extremely well done. But again, it reinvents the wheel and breaks the expectation of a universal resource locator.
An ASK url for content generated by Ajax requests and an ASK url for a JavaScript/Ajax-less request are different. If I were to post an ASK url with the #0:1:2 hash, that would work fine for those with JavaScript enabled but wouldn’t work for those with it disabled or missing support for XHR. The latter includes search engines which would only see the fallback url when crawling your site. We’re now creating another situation like www vs.no-www.
Nice post. No mention of possible security issues though. Surely this should be a consideration as well. For example, PHP’s ability to interact with a database is very powerful. So powerful that even now in version 5, users are still not aware of the security risks involved in even very basic PHP implementations. (XSS hacks for instance). It seems that everyone is so anxious for the next killer app that lessons learned are not being applied to new technologies.
Emphatic, you have the perfect sounding board for sharing those security issues. Care to post some links that explore these problems?
Responsible Asynchronous Scripting, with great power comes great responsibilit…
Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies lik…
“search engines don’t parse JavaScript”
Actually, GoogleBot does. I know this because I monitor traffic to certain scripts that can only be accessed via AJAX, and GoogleBot does index said pages, and properly I might add. The only way for that to happen is if it parses the JavaScript on my pages.
AJAX to a Point…
Its good to see that some people are thinking critically about web 2.0 technologies, namely AJAX. ThinkVitamin throws up a good read on the pitfalls presented by irresponsible use of AJAX…….
Great article, Shaun.
This litmus test is eloquently put:
To avoid repeating a similar mistake, try this litmus test: If refreshing a page immediately after that page has been updated by remote scripting results in an essentially identical page then you’re doing okay. If not, head back to the drawing board.
I can’t help but wondering that “Search Results” and “Tags” do not pass this litmus test. From a content perspective, aren’t they similar, if not identical, to navigation? They represent a filtering of content in the same way a navigational item does - a subset of the site’s content.
Shouldn’t search and tag results have a URL, e.g.
www.newsvine.com/movies
?
If this content is rolled into an Ajax scenario, isn’t it the same as rolling navigation? I have noticed many bloggers beginning to use a “Live AJAX Search” on their site. If not deprecated to filter these results in a URL, like Google Maps does, doesn’t it fail the litmus test?
I think that things are moving faster than developers are used to. I know for myself, PHP XML and finding a web host that had PHP5 was a problem a very short time ago. Now, it seems, that AJAX is leap-frogging PHP XML like it never existed.
It’s like going from A to C instead of going from A to B and then to C.
The period of time spent on B (PHP XML), almost non-existant. Do you get that feeling about it?
Secondly, what is your opinion on Web 2.0? Is it just a web app? or do you think it should be more like newsmediarelease.com with audio,video,rss,social bookmarking,folksonomy,wap 2.0 etc.
Or do you think these are just elements on their own that you can either include in the Web 2.0 package or not.
Just curious.
Dan
What you fail to realise is that the web2.0 is an evolution of the existing web.
The web needs to change to cater for user expectations. After all its now all about the user experience.
You say “asynchronous scripting is most appropriate for actions and transient or conditional data”, yes for web1.0 but NO for web2.0.
We should do away with the back button altogether as i know from experience that its been the bane of many an web application. Its down fall is in its simplicity, ie. it’s suppose to move back a step but what is the definition of a “step”. All browsers should remove the back and forward button and replace it with something else “not sure what but im working on it”.
Liquidboy, I agree that the web is about user experience (or, at least that should be the primary driver for developers & business owners), but removing the back button is, for me, unthinkable. At a psychological level, the back button is the equivalent of the ‘undo’ or the trail of crumbs through the forest. Depriving users of this lifeline would amplify what for many is already an experience with some degree of anxiety.
Still, I look forward to what you you will propose in its place…
Just a note, browser history can be implemented and has been in Google’s GWT. Dugg.
maybe not remove the back button, but ackowledge that it has changed its meaning with ajax
now its not “previous page” but more like an “undo” or “previous action”
How to build an AJAX web app:
1. Create semantic XHTML and server side code. Your app should be usable by now.
2. Add CSS to style as you wish.
3. Add any behaviour (including AJAX) in the form of external JavaScript.
Keep it clean and separated. And those AJAX searches are just silly.
[…] AJAX and its kin are empowering developers, but with great power comes great responsibility.read more | digg story […]
Ugh. Search results with AJAX is the one thing that consistently falls down in my expectations and drives me crazy.
It seems so flashy and nice at first. You’ve done a search, and the results come up in the same page lickity-split. Then you click the first link, discover it’s not the link you want and quickly click the back-button on your browser. Whoops… what happened to your search results?
How you can ever advocate this as an acceptible use for AJAX is beyond me?
> And those AJAX searches are just silly.
It depends. I my case (extranet application) I need a way to add products to cart by providing product code. Keeping in mind that there are several thousand products to look up a quick “AJAX search” is a real saviour.
With internet technology moving so fast, it seems some people feel the need to adopt and milk the buzz even faster. It’s getting to the point where we need to let the technology appear, get over hyped, get overused, get over analyzed, and then learn from other mistakes to implement it in a reasonable fashion.
Indeed, Ajax doesn’t have to break the back button. But nor do you need to fix it in all cases of using XHR. I think you hit it right on Shaun with thinking about user expectation. The URL is a very important detail of a browsing experience that people will end up wanting (like, to bookmark, duh).
I think Flickr does an excellent job of implementing Ajax in all the right places, and leaving it out of others.
Netvibes is another good example of actually not even needing any URL’s because it’s fairly intuitive that you’re always on the same page just making changes to your preferences etc.
It gets bad when, oh let’s say I want to link to your about page, but when I click on the ‘about’ link, I get a request that dumps content into div and then since I loved reading all about you, I want to forward this link to my friends…except that a new url wasn’t formed.
[…] On ThinkVitamin.com, there’s a new column that’s been written up by Shaun Inman, one of the brains behind Mint concerning “Responsible Asynchronous Scripting”. […]
GMail is another site that does not use AJAX responsibly. It frustrates regularly that I cannot go to the Inbox simply by using the back button, after viewing search results.
[…] Vitamin Features » Responsible Asynchronous Scripting High level overview of Ajax design issues. (tags: ajax accessibility programming usability webdesign) […]
So which current libraries do a good job at this? (life easier without encouraging bad decisions). You mention AHAH, AXAH, and JSON (is this one really a library?). Is that it?
Pardon the ignorance, but I’ve only had a chance to look a couple of the more popular ones so far (Dojo, YUI, GWT). I realize one answer is: “download them and try them out yourself”, but last week I stepped out for a cup of coffee and when I came back there were 67 new frameworks to check out :-) (sorry: that’s really an old image replacement joke). Anyway, without asking anyone to give a public endorsement (unless you want to), which ones do a good job of–if not directly supporting–a HIJAX-y/degradable approach to AJAX?
Tim, I don’t think the choice is necessarily finding the right library that does Ajax correctly (although I recommend YUI (for obvious reasons)). But rather it’s up to you as a developer and implementer of the Ajax itself and making tasteful uses of it. Even with the greatest of Ajax libraries you can make a site very poor and make use of Ajax in a very irresponsible way.
Shaun,
While I share your views here in general, they only have room during a traditional phase. We have to move on from the [broken] browser concepts of the 90’s. Browsers should be little more than content-renderers.
AJAX is [great] for web Applications. Sure it’s there’s a lot of poor implemetations out there right now. It’ll go away. It was no different with the various HTML releases. For over a decade we’ve been hacking the web to get browsers to what we want.
The biggest items on the list driving all this are probably
- [visible] page refreshes
- multiple form submissions
- ugly and limited controls/widgets
Those are probably both items that browsers ‘could have’ long since addressed, but they have not. The pendulum is simply swing back the other way right now. And mostly good things will come of it.
AJAX is [great] for web Applications.
Read that slowly. Applications that run in a web browser. The browser is merely the transport vehicle and rendering device.
Applications generally maintain their own state and browser back buttons, refresh buttons, etc have no business there.
The browser is in that case setting the wrong expectations. It is of course doing so right now as a courtesy to Web 1.0 applications. Implementing history state in an AJAX application is not that difficult.
Same goes for bookmarks. They may be great for earmarking a resource in the ‘library’ style web. But URI’s can be as much a hassle as they may be a blessing. Dead links anyone? Repost the form? What about ‘Please don’t click anywhere until the page reloads’ messages?
Now web Pages and as the web originally intended are a perhaps different ball of wax. A ‘public’ site / resource definitely should perhaps maintain compatibility with the URI way of handling things. At least during a transitional period.
Beyond that point it is simply wrong for browsers to assume anything about state in pages that may be JavaScript driven. Maybe they could do so as a default. But developers should be able to turn those buttons off if they manage their own state.
Just my 0.02 cents.
Tim, like Dustin says, all libraries do and all don’t allow for a degradable approach to AJAX. The reason I say that is because it’s up to the developer to implement it appropriately.
One of the key litmus tests to the page refresh vs XHR approaches is “Would I ever want to send somebody a link to this page?” Search results, IMO, is definitely one of these pages (I understand the irony that the search on my own site is AJAX-enabled).
[…] Responsible Asynchronous Scripting: ” On ThinkVitamin.com, there’s a new column that’s been written up by Shaun Inman, one of the brains behind Mint concerning ‘Responsible Asynchronous Scripting’. […]
It seems that most of the issues that we are wrestling with here are the same/similar to those that afflicted us in the late 90’s. Frames disables back the back button, caused bookmarking problems, SEO problems, and suffered from accessibility problems. We used frames for the same of the same reasons we now want to use Ajax, such as to selectively refresh areas of content. In the popularizing of the Web Standards movement web designers/developrs have very much embraced accessibility for its many benifits to users of all kinds. It’s interesting that Ajax is the big carrot that is tempting us to negate the lessons we have already learned. It should perhaps be no surprise as history does tend to repeat itself.
[…] Responsible Asynchronous Scripting — “This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology.” […]
Juergen if you want to create a web application, then the least you can do is make it “web friendly.” Please, please, plase make “views” of information shareable and storeable through URLs. You’re app is going to be less enjoyable to use if it requires you to “re-invent the browser” because you are ultimately only constraining your user’s use of the app if they cant open new tabs, bookmark, press back and pass on URLs.
Use AJAX scripting responsibly…
Good advice for web developers who want or need to use asynchronous scripting when building a web app….
[…] We’ve talked before about AJAX being inaccessible… “So what’s a well-intentioned web developer to do? Stop and think about the following before dropping that sudsy, lemon-scented bomb on unsuspecting users.”… It’s a step in the direction of making AJAX accessible. […]
Great article Shaun. I also wanted to write about it, but didn’t had the time for it. hidefdvd.com is good example of how AJAX can be used in a wrong way.
It is sad that a lot of peope develop applications or parts of websites with AJAX, just because of AJAX.
It’s all about how you use/implement it. So think before you do. It will consume much more time if you have to deal with accessbility and other problems afterwards.
Responsible AJAX…
AJAX is the big buzz word these days. It seems sites are implementing AJAX features faster than any technology I have ever seen. However, it seems what is lost is sites implementing AJAX responsibly. Shaun Inman has written a great……
Have you ran this site thru the HTML validator? FF has a nice TIDY ext lol.
ohboy: well, actually it’s just a whitespace in link’s href (line 64, col 29) : “mailto:?subject=Vitamin Article: ‘Responsible Asynchronous […]”
Really not a big deal.
[…] Conclusie: “with great power comes great responsibility“, ik had het niet beter kunnen zeggen. […]
I agree with the bulk of the comments here and feel that any new technical ability should be used responsibly. I also agree that most pages/applications should adhere to long-standing web standards and paradigms such as the ‘back’ button etc. There is content that needs to be available for all to see.
But… it is my view that there has always been a need for a slightly different paradigm more conducive to applications as opposed to web pages. I am talking about another way of navigating. Call it a ‘Application Mode’ or a new operational browser mode customized to accomodate applications that should behave like a desktop application. I know that I am not the only one who has wished for this. It is evident from the conversations here that there is a need for that kind of functionality. For those who want to preach about making all pages equal, I agree with you as far as content but open your ears and hear the need!
[…] DL: We are interested to hear your opinions about the recent article on responsible asynchronous scripting written by Shaun Inman. […]
An ASK url for content generated by Ajax requests and an ASK url for a JavaScript/Ajax-less request are different. If I were to post an ASK url with the #0:1:2 hash, that would work fine for those with JavaScript enabled but wouldn’t work for those with it disabled or missing support for XHR. The latter includes search engines which would only see the fallback url when crawling your site. We’re now creating another situation like www vs.no-www.
How about a mod_rewrite
[…] The Vitamin brings us this article on Responsible Asynchronous Scripting, and the obligation we as designers have towards our users over our own site’s dynamic functionality and appearance. Ajax and its kin are empowering developers, but with great power comes great responsibility. Once these ideas about AJAX soak in we’ll be producing clean web apps that play nice with search engines, desktop and mobile browsers, and web-enabled dish-washers alike. […]
[…] Jakob wrote: To edit a core record, I’d place an “Edit link” on the core record, that would either make all fields editable on the spot, or take the user to the “Edit core record” page where the fields are editable. I really like the idea of having the 3 event-based, specialized input forms to aid in editing, though (see below). Now I realize this doesn’t fulfil the expectations of AJAX everywhere and having a single page that does everything, but it means that we will get a prototype that’s quicker to build and more usable. Look at the 37signal sites, they all work like this, as do Harvest and Shopify. The best approach by far is to make things the regular way initially and then start improving usability by adding AJAX and Javascripting where it’s necessary and can be shown to have actual usability improvements. Jeremy Keith has written about this at http://adactio.com/journal/959 with slides from a presentation about this at http://domscripting.com/presentations/xtech2006/ (both a techie-focused, but his point still stands). There’s more reading at http://www.456bereastreet.com/archive/200606/use_ajax_scripting_responsibly/ and in turn at http://www.thinkvitamin.com/features/ajax/responsible-asynchronous-scripting which is linked. […]
[…] read more | digg story Explore posts in the same categories: coldcase […]
Hi everyone, great site. I’m pretty new to development and have basic skills in fireworks, dreamweaver etc. What I really want to do is some artwork like in this vitamin c site. That’s what I aspire to at least!
[…] Responsible Asynchronous Scripting […]
[…] DL: We are interested to hear your opinions about the recent article on responsible asynchronous scripting written by Shaun Inman. ” While not directly tied to asynchronous scripting, page content is often replaced unceremoniously in an application that uses XHR. Shaun Inman […]
[…] Responsible Asynchronous Scripting AJAX and its kin are empowering developers, but with great power comes great responsibility. Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. […]
[…] Shaun Inman’s article Responsible Asynchronous Scripting contains more good advice for web developers who want or need to use asynchronous scripting when building a web app. […]
What should be included?
[…] Last, but not least, Shaun Inman said this about ASK - AJAX Source Kit in his comment at Vitamin: […]
[…] AJAX and its kin are empowering developers, but with great power comes great responsibility.read more | digg story […]
Dave…
Interesting topic… I’m working in this industry myself and I don’t agree about this in 100%, but I added your page to my bookmarks and hope to see more interesting articles in the future…
kevibwqtm whknbdwsmw hdcdde hgizzvtii ppqpkmxmg aspdgbrgtk oxxcvemr gvrqdhck…
lqgrxuuk aemalyfa wlmejiyrm plzfzfbmw cwcfzwbrqc rbevfrefk njoubmitfu…
[…] Responsible Asynchronous Scripting […]
[…] Jeremy Keith, Bruce Lawson, Rob Cherney, and many other JavaScript developers have been advocating best practices that address this issue for some time. It seems 2006 was the year we sobered ourselves after binging on inaccessible scripting techniques. Many great articles were published bringing us back to our senses, preventing us from repeating our terrible development practices of the pre-standards 90’s. The resolution to the problem is to progressively enhance a web site that functions properly without JavaScript support. […]
[…] As new projects enter into planning, this decision comes up again and again. When should we use AJAX? When is it beneficial and when is it just extra overhead? Here are few articles discussing this. […]
[…] Responsible Asynchronous Scripting Develop using the traditional “links to GET/forms to POST†model without relying on JavaScript. By including the same HTML generating file that we plan to request using XHR, we keep our business logic out of the JavaScript and on the server where it b (tags: JavaScript AHAH AJAX JSON XHR) […]
[…] read more | digg story Posted by seethepost Filed in news […]
[…] read more | digg story […]
[…] great power comes great responsibility.read more | digg story Posted in Uncategorized RSS 2.0 | Trackback |Comment […]
[…] Vitamin Features » Responsible Asynchronous Scripting Doing so breaks an inherent functionality responsible for the success of the web: Universal Resource Locators. Unless we reinvent the wheel and restore this […]
[…] Responsible Asynchronous Scripting May 30, 06 Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies like images and cookies, native support for the XMLHttpRequest (XHR) object in modern browsers has made it easier than ever to make web apps more responsive and more like their desktop counterparts. This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology. […]
[…] Responsible asynchronous scripting - Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies like images and cookies, native support for the XMLHttpRequest (XHR) object in modern browsers has made it easier than ever to make web apps more responsive and more like their desktop counterparts. This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology. […]