Finally understanding the attraction of AJAX

September 3, 2010

I'll admit it; I'm slow sometimes. For a very long time now I haven't really gotten why people keep sprinkling AJAX over their web pages (partly because I assiduously use NoScript and so mostly don't see it). Oh, I understood that you needed it to create actual applications on the web and that it could be convenient for making vaguely friendly things, but I didn't really understand it in the context of relatively ordinary web apps like DWiki.

But my recent thinking about my comment form design mistake has finally fixed that. Here is my recent insight in a nutshell:

AJAX lets you do things without page changes and refreshes, so you can preserve the user's context on the page and make them less confused.

In a conventional non-AJAX web interface, any significant action forces a (full) page reload. This creates a visible page refresh except in extremely ideal circumstances and in general means that the user has to find their place again and reorient themselves. This is sort of tolerable if what the user is working on fits entirely inside their browser window; it's fairly horrible if it doesn't and they have to actively scroll around to find where they were before. This is the core problem I have with a revision to my comment form design; I'm pretty sure that people would get lost among everything else going on.

(The ideal circumstances are that you're using fragment identifiers in the URL, the browser accurately repositions things back at the fragment identifier, and the entire system loads the new page so fast that there is no visible flicker.)

In an AJAX web interface the user can perform actions without this lurching jump. For example, when they click on 'add comments', they don't get yanked to a new page; instead, a comment form unfolds right then and there in front of them. This is less confusing in two ways. First, it is happening right in front of you, clearly visible. Second, it is the only thing that is happening; you don't have to pick out the significant change from all of the other flickering and movement and so on that's going on as the page reloads.

This creates a more fluid, less disorienting interface, one that is easier and faster to work with because you spend more time doing what you're interested in and less time finding your place again every so often. In a sense, the result is much closer to a direct manipulation interface than a standard, non-AJAX web page can manage.

I don't think that there's any way to pull this off without AJAX; you really need some way to do a partial page content update without anything else flickering or moving. That's just not something that browsers offer (you don't even get it on plain user-initiated page refresh).

(I suspect that this is old hat for people in the field, but all of it only clicked for me when I started really thinking over the problem of people getting lost in my comment form under various circumstances, cf TemplateLimitations.)

PS: looking backwards, this makes me slightly more sympathetic to old HTML frames. Although they were almost never used this way, you can argue that they were a crude first attempt at the sort of limited page update you'd need to pull this off.


Comments on this page:

From 87.194.56.231 at 2010-09-03 06:41:42:

Having the form on the page and hiding / revealing it (with Javascript) would be friendlier than loading the form snippet via AJAX. That way noscript visitors would still get to use it.

David B.

By cks at 2010-09-03 08:57:39:

I think I am abusing the term 'AJAX' a certain amount; I mostly mean all of the ways of changing page contents on the fly, some of which are probably not true AJAX.

I'm not convinced that using JavaScript to hide and reveal forms and so on is the right interface for no-JS people. The kind of things that you want to do with AJAX don't necessarily degrade gracefully, so you may be better off with two completely separate interfaces.

(My impression is that JavaScript provides plenty of ways to hijack a normal form and link based web interface in order to completely replace it with an AJAX one on the fly.)

From 87.194.56.231 at 2010-09-03 15:57:28:

You definitely are abusing the term AJAX, although worse things happen at sea and we get what you mean anyway.

I think there should be a comment form on the same page as the entry. I also think comments should be shown by default on an entry page (not necessarily on the front page or archive pages) because comments are often interesting.

For those visitors with Javascript enabled the form will be hidden, to be revealed (perhaps re-positioned) when the visitor indicates she wants to add a comment. The hide/reveal can be done by adding/removing a CSS class style to the form block - relatively unobtrusive.

Thanks for interesting blog, David B.

From 87.194.56.231 at 2010-09-03 16:06:34:

Regarding sympathy for frames, I think they were valuable when used to provide a table of contents for a topic. And for that use I think URL fragments and CSS's position directive work fine - no need for frames. See Apple's on-line developer documentation for an example of frames-style navigation without frames, e.g. http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/BPSystemStartup.html

David B.

Written on 03 September 2010.
« Why Python's global is necessary
The laziness of a programmer, illustrated »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 3 01:11:31 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.