Friday, December 2nd, 2005

6 Places You Must Use Ajax

Category: Editorial

Alex Bosworth has written up his thoughts on areas that you must use Ajax, and areas in which you shouldn’t.

Places you must use Ajax

  • Form driven interaction.

    Forms are slow. Very slow. Editing a tag on a del.icio.us bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.

  • Deep hierarchical tree navigation.

    First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use Javascript to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it’s way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.

  • Rapid user-to-user communication.

    In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn’t have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail ‘refresh inbox, refresh inbox’ symptom, doesn’t really push Ajax far enough yet in terms of notifying new mail instantly.

  • Voting, Yes/No boxes, Ratings submissions.

    It’s really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive – if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote. (I have 2008 movie ratings on Netflix versus 210 ratings on IMDb.com).

  • Filtering and involved data manipulation.

    Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.

  • Commonly entered text hints/autocompletion.

    Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It’s very useful in del.icio.us and GMail, for quickly adding tags/email addresses.

Where you shouldn’t use it

  • Simple forms.

    Even though forms are the single biggest beneficiary of Ajaxification, a simple comment form, or submit order form, or other one-off rarely used form does not benefit from Ajax driven submission. Generally, if a form is not used much, or it’s critical to work properly, Ajax is not that helpful.

  • Search.

    LiveSearch on blogs is more annoying than useful. There’s a reason that Google Suggest is staying in beta and not going on the front page of Google. Searching on Start.com Live.com doesn’t allow use of the back button to see a previous search, or previous pages. Maybe it’s possible that no one has gotten this right yet, but getting this right is hard enough that it’s generally not a good idea, or more trouble that it’s worth.

  • Basic navigation.

    In general, driving basic site/application navigation using Ajax is an awful idea. Why would anyone want to spend time writing code to emulate the browser behavior when they could spend time making their application better? For basic navigating between documents, Javascript doesn’t help.

  • Replacing a large amount of text.

    Ajax saves a complete refresh of the page, so small pieces of the page can be more dynamically updated. But if nearly everything on a page is changing, why not just request a new page from the server?

  • Display manipulation.

    Even though it seems that Ajax is purely a UI technology, it’s not. It’s actually a data synchronization, manipulation and transfer technology. For maintainable and clean web applications, it’s a good idea not to have Ajax/Javascript manipulate the interface directly at all. Javascript can stay separate and simply manipulate the XHTML/HTML DOM, with CSS rules dictating how the UI displays that data. See this post for a simple example of using CSS instead of Javascript to control display.

  • Useless widgets.

    Sliders, drag and drops, bouncies, mouse gestures, whatever. Mostly these widgets can be replaced with more intuitive controls, or eliminated altogether in favor of simplicity. In picking colors, maybe a slider widget is useful to pick the exact shade. But in picking a price point in a store, a slider to pick the price to the cent is just overkill.

Many good points, not all agreeable

I am sure that we will all agree with some of the points, and disagree with others. You also can’t paint a brush this thick. There are some live searches that are great. We have worked on a few domain specific live searches that really helped the users in usability testing.

Simple forms are also one of the places where Ajax should definitely be used! With Ajax you can have real time error checking (including domain specific validation, not just “is it a number”). It is also something that is easy to degrade.

Posted by Dion Almaer at 9:01 am
34 Comments

++++-
4 rating from 51 votes

34 Comments »

Comments feed

I’m basically going on what I’ve experienced personally. To me live-search features have never felt that useful. Maybe I haven’t seen the right one :/

Real time error checking is indeed cool, I should add that to the wiki.

Simple forms that are not used that often? I still think they don’t really need Ajaxification.

Comment by Alex Bosworth — December 2, 2005

Live-search isn’t the only kind of Ajax search, though.

On my blog, I implemented a different sort of Ajax-based search — one that lets you submit the form and get results without leaving the page.

It’s not anything life-changing, but I like it more than the default Movable Type search that I had before (or the awful Google Suggest rip-off that followed soon thereafter).

Also, “places you *must* use Ajax” sounds a bit overstated.

Comment by Joe Grossberg — December 2, 2005

Really, I think drag and drop is very useful for and far beyond the old way as far as re-ordering a list of items, so to call it a useless widget is a little much

Comment by b — December 2, 2005

I think drag and drop can be very useful (see Basecamp’s reordering of to-do items), but it has be carefully done to not be a usability mess.

Comment by Rob Sanheim — December 2, 2005

What I believe Alex is trying to get across stems from a very strict definition of AJAX … that is AJAX is for asynch communications using javascript and xml.

The rub though is, as others have pointed out in the past there’s no D or V in “AJAX”. No DHTML. No VML. No SVG. Really no graphical user interface concept described in the terms underlying the AJAX acronym. Tighly defined AJAX is just the way to get data to and from the client — not how it gets displayed.

Accordingly from what I see there are currently four quantum states of the term “AJAX” today (all of which are exemplified in ajaxian.com’s coverage).

These are:

ajax communication libraries — just the communicaiton routines, with little more.

html/dhtml/vector/js components pre-wired to ajax communication libraries — GUI widgets that are scripted to do background communication with ajax techniques.

gui frameworks — full integrated libraries of interactive gui components that share common methods for data acquisition persistence and communication. These are sometimes server-centric and at other times client centric as in TIBCO General Interface AJAX Framework offering.

libraries supported by visual development tools — ajax authoring today is mostly happening in the real that HTML did at first — that is the textual code editor. Visual tools for certain frameworks are emerging. Here at TIBCO we even build the AJAX tooling using AJAX (in the 3rd quantum state definition of the term) to create the Rich Internet Application IDE we call TIBCO General Interface.

The thing is that while ajax strictly defined may be just the communications aspect, it’s really AJAX + DHTML and Vector rendering capabilities in the browser that provide the possibility to deliver web based applications that can give desktop installed applications a run for their money.

So is AJAX just some of the ingredients in a no-plugins, no-applets, no-active-x, approach to Rich Internet Applications?, or is AJAX a class of Rich Internet Applications unto itself. Or is it all of the above.

Far as I can tell from a semantic survey of the web (or just ajaxian.com alone), the term has 4 quantum states of being. Anwser: All of the above.

–Kevin Hakman, TIBCO Software Inc.

Comment by Kevin Hakman — December 2, 2005

Any examples?

Comment by Rob — December 2, 2005

Kevin, all true. I don’t know exactly why many equate “Asynchronous Javascript + XML” with “XMLHttpRequest, you rock!”. And more to the point, Ajax was really introduced more than just those technologies anyway.

Saying that, Alex’s points here are mostly quite valid – he’s advising caution on various points, not ruling them out. e.g. Drag-And-Drop is okay for re-ordering lists, but overkill for selecting a boolean value!

Comment by Michael Mahemoff — December 3, 2005

IMHO I disagree with the rule about replacing large text. The reasoning that Alex suggested was, [paraphrased]”if you are going to replace a lot of text, why not just request a whole new page”. I think that in certain cases this is tantamount to giving up instead of pushing a limit here where ajax can be useful, particularly in searches that may take a few seconds due to backend processing.I think ajax is useful here because you can present a loading-progress GIF while the search is taking place, instead of making the user wait with a blank screen or wonder what is going on during the search. I understand many search apps are so fast that there is no downtime, and in that case I’d say, why not just use AJAX instead of why not just request a new page. Alex’s statement seems to infer that making the ajax request is harder than submitting the form, which is just not necessarily true at all if you setup your variables correctly in html.

again just IMHO,
tope

Comment by Tope — December 3, 2005

“Basic navigation.”

Exactly. I’m amazed whenever I read someone saying how they want to simulate several pages using Ajax. Let’s say you had a 10 page site about widgets. What possible advantage could there be in using Ajax to load the content of each page as opposed to just going to an actual page.

Comment by Keith — December 3, 2005

I have seen some very good examples of useull ajax-searches. One is the index search over at http://docs.gotmono.net/ . Compare finding something in this documentation rather than finding something in a documentation with a navigation interface like this: http://msdn2.microsoft.com/en-us/library/default.aspx .

It’s true that it is very nice to be able to go back to a previous search, but I think there’s a place for both a normal search->submit->get a result and a search->get instant index kind of search.

Comment by zith — December 3, 2005

I am such a n00b…

Comment by Issac — December 3, 2005

Also, you left out, in no case should it break the browser’s back button or “open in new window” in the context menu.

Comment by Jason — December 3, 2005

Will Ajax not matter anymore, especially once the average internet connection is fast enough?

Comment by Jamal — December 3, 2005

Yea, one cool thing I have seen is using ajax and flash, for example http://www.audiri.com uses it to integrate its mp3 player into the site, it remembers your play list and you can add to it dynamically

Comment by John Becker — December 3, 2005

Forgive my newbishness, but wouldn’t the more rapid user to user communication and you comment on Google involve the server sending info to the client as it updated…can you do that? I thought you could just send a response after a request from the client?

Once again, sorry if its a newbie question

Comment by Manny Fleurmond — December 3, 2005

You just copied Alex’s entire article, and added a paragraph at the bottom saying that you agree with part and disagree with part?!? What chutzpah.

Comment by Ryan — December 3, 2005

Copying my articles is no problem, I license them all under creative commons share alike + attribution.

Comment by Alex Bosworth — December 3, 2005

Good article. Thanks, Alex. There’s a new book out there called “AJAX in Action” by Dave Crane. I recommend ANYONE interested in Ajax get this book and read it from front to back (several times ;))

Cheers,
dep

Comment by dep — December 3, 2005

Nice list. I appreciate the thought and agree with most of it.

One thing I just would like to add is that both hardware and bandwidth are a commodity, and are becoming cheaper every day. Unless you’re working with a dial-up connection or an embedded system, these shouldn’t be a concern.

What SHOULD be a concern, however, is user experience with the UI. There are cases when the user EXPECTS the page to reload (like search). User Interaction Time is also an issue – the data may get to the user quickly, but if it takes too long for the user to figure out what to do on the screen (i.e – tree navigation), then the war is lost. More often then not, I find the straightforward Submit Page->reload scenarios are easier for many to understand. (This, I admit, is probably due to users being trained by the technological limitations of the past.)

As better toolkits come available to let developers choose their connection type seamlessly, Web UI development will only get better.

Again, thanks for the writeup.

Comment by Tom Melendez — December 3, 2005

“Ajax saves a complete refresh of the page, so small pieces of the page can be more dynamically updated. But if nearly everything on a page is changing, why not just request a new page from the server?”

Because you can use javascript to produce transitions and other visual cues that create relationships between various bits of information. Flash is popular because of it’s capability to do transitions on a web page. Now JS+AJAX content replacement gives you the same capability.

Comment by Dave — December 3, 2005

Nice list. There’s another item for the “don’t” side though – anything you want indexed by search engines.

It’s related to the point about replacing large amounts of text. If content is only being loaded based on the actions of the user, the bots that search engines send out to index content will never see it, never index it and consequently never add that page to search results.

Comment by Tim — December 3, 2005

Another place is the tab widget. When you load the first tab, don’t load the other invisible tabs until it becomes active (gets clicked).

Comment by Son Nguyen — December 3, 2005

i partially disagree. i think that it is very cool when i see an ajax comment form in a blog. it makes it easier to preview.

Comment by miscblogger — December 3, 2005

I agree with most of that, particularly the bit about voting. Works very well on Digg, too, where you are currently featured. :)

Comment by splintax — December 3, 2005

“Simple forms that are not used that often? I still think they don’t really need Ajaxification.”

What does how often something gets used have to do with wether or not you should use ajax? Why exactly would a simple form benefit less from ajax?

A project I’m working on has a list of randomly selected comments/reviews at the end of the the sidebar on each of the 3 product pages. At the end of the list of comments is a tiny form allowing you to submit a comment to the moderator queue (the most seamless way to eliminate spam).

It’s hardly ever going to get used, and there’s only two fields (name, with anonymous entered as the default, and comment). Clearly a simple and rarely used form, yet it benefits in a big way from ajax. Submitting the comment is faster, the scroll position of the page doesn’t change, there’s no back button to take them back to exactly the same page minus the confirmation text, and generally it just allows them to type something in, hit enter, and instantly get back to whatever they were doing before.

Just because something is simple and rarely used doesn’t mean it’s not worth the effort of an ajax form.

Comment by Abhi Beckert — December 4, 2005

Main reason to use AJAX it save time whithout refresh page. Well user not see status inicator of loading page. BUT if you use more AJAX requestred on ONE page it’s more nerviosy for user, becose it’s sometimes very slowly too, but user can’s see indicator and it very bad. Maybe something wrong? Maybe no data? What’s happand whis page – think user.

Comment by Eugene — December 4, 2005

Savvica has recently launched a completely free, on-demand learning management system (LMS) that uses AJAX throughout just as recommended here. Check it out:

http://www.nuvvo.com/

We came to the same conclusions about the use of AJAX. I’d love to hear everyone’s reaction – the only area I think we really need to AJAXify right now is the scheduling features.

Comment by John Green — December 4, 2005

Those examples of where to use Ajax are very nice, but please remember not to rely on Ajax, else users of links, w3m, browsers for the blind and so forth won’t be able to use your services. I think that del.icio.us is a good example of how to do it: having a JavaScript-supporting browsing adds some nice features, but it’s still usable in emacs-w3m

Comment by Robert Uhl — December 8, 2005

Don’t forget to check out the wiki page for Ajax Places – http://swik.net/Ajax/Places+To+Use+Ajax – it’s a collaborative list anyone can edit, a few new ideas for where Ajax should be used have been added so far.

Comment by Alex Bosworth — December 13, 2005

化妆�
翻译公�
�州礼�
�州礼�网
�州礼�公�
上海礼�
上海礼�网
上海礼�公�

Comment by 爸爸 — December 17, 2005

[…] Ajaxian » 6 Places You Must Use Ajax […]

Pingback by the lone sysadmin » Blog Archive » links for 2006-03-31 — March 31, 2006

I dont even find the need for AJAX even though I like it. Maybe my imagination doesnt stretch too far, but I prefer making one form that submits to itself and displays data after manipulation rather than calling a server side script through AJAX now and again. Its more on the use and internal data transfer speed. Not a bad architecture, AJAX. Google uses it in great fashion. I like that!

Live preview (as I type) underneath this comment is a waste, if it is using AJAX because I, as a web developer, can figure out how this posting is going to look like.

Comment by Chirag Shukla — May 5, 2006

You just copied Alex’s entire article, and added a paragraph at the bottom saying that you agree with part and disagree with part?!? What chutzpah.

Comment by Master — March 26, 2007

It seems everyone’s comments are just as informative as the blog itself. ^5!

Comment by FavHost — August 10, 2007

Leave a comment

You must be logged in to post a comment.