I held an Ajax-seminar for the Swedish software consulting firm Teleca last wednesday, and it went quite well. I thought I should share some of the things I talked about.
The seminar slides and other resources are available, but they are in Swedish so far. I’ll give you an English summary here.
Web 2.0 is not new
Â»Web 2.0Â«, in my opinion means using the web for other things than web pages, i.e web applications, and as such is nothing new. What makes web 2.0 interesting to talk about now is that Ajax (and more on what Ajax means soon) makes it possible to write web applications that are not (as) crippled by technical limitations.
What is Ajax
As web 2.0, Â»AjaxÂ« has many definitions, here are my three suggestions:
- DHTML + XMLHttpRequest
- Web applications that load data in the background and changes the view without page reloads
The first is the obvious: the definition of the acronym. However, it can be argued that Ajax is not an acronym anymore, especially since XML is not a must, and what used to be called DHTML before is now an integral part of Ajax. Therefore Ajax could be said to be about DHTML and the XMLHttpRequest object.
Being more general, and capturing the mindset, I prefer the last definition. Loading of data (as opposed to loading views) is a new concept in web application development, and to be able to load data in the background, without the user initiating the transfer, hasn’t really been possible before. Finally, to be able to change the view without doing the round-trip to the server to have the view re-rendered is a huge step forward.
Really, this is quite basic stuff. Flash has been able to do this for quite some time, and desktop applications, and technologies like Java WebStart have done this for ages. The problem is that they aren’t used to build distributed systems. Finally, HTML-based web applications can do what they were supposed to do, without the technical limitations.
Benefits for the developer, and for the user
For the developer there are things to gain from using Ajax instead of programming web applications the traditional way.
- The state can be kept in the client, where it belongs
- No GUI-code on the server side
- Less programming languages in the same context
- Complex GUI-components are simpler to handle
The one major problem in current web application development is sessions and keeping the state across complex wizards or similar multi-page views. The problem arises because HTTP is stateless, so we have to glue statefullness on top of it. In an Ajax-application, the state can be kept in the client, where it belongs. The server side can become fully stateless, which simplifies its development.
When you have the state in the client application, you can use complex GUI-components (trees, calendars, whatnot) without having to update the whole view each time the user clicks on it.
Those are some of the benefits for the developer, but there are also benefits for the users:
- Web applications that work more as desktop applications
- Client side validation
- Preloading of data
Web applications don’t behave as desktop applications, but usually look as if they would. This confuses and annoys users. Usually the users are blamed for errors, when, in fact, the application developers are just lazy, stupid or limited by technology (no, there is no excuse for blaming the user, the user is never wrong).
Client side validation has been possible for a while, and some sites employ it, but not everyone. It saves time for the user to know that he or she accidentaly typed his or her e-mail address wrong before a form is submitted. Spare your users the annoyance of having to submit a form multiple times until they get the format of a date right, tell them straight away that you don’t understand the date they entered (the mindset here is important, its you/the application that don’t understand, it’s not the user who have done wrong). Of course you have to validate the data again on the server side, but that’s another discussion.
You can load data whenever you want, so if you have a view with a paged list that shows 10 or 20 items a time, you can load the data for the next page before the user has pressed next. This saves time for the user, and your application will be more responsive. Don’t let the user wait unless you have to.
Where Ajax is a good idea
- Components that are not part of the main function of the view:
- Status area
- add a comment
- (rich) tooltips
- microlinks (a link that doesn’t take you to a new page, but pops up the content in a box adjacent to the link)
- Login that don’t forward you to another page, just updates the current view
- Form validation
- Active search
- Navigate large datasets with incremental loading
- Navigating maps
See 12 perfect cases for Ajax for more inspiration.
Form validation deserves extra focus. Its such a simple thing to do, validate a form field when the user is finished typing in it, tell her that you don’t understand, or that the data is what you wanted.
But that’s not all: syntactic validation is one thing, you can check if a users desired username meets your standard, but what if it’s already taken? last.fm’s signup page has an elegant solution to this problem: type your desired user name and it checks it for you in the background. Ajax gives you the power to do both syntactic validation and semantic validation of you forms before they are submitted. Don’t have the user type their e-mail address and password before they know if they can have the username they want or not.