Explaining Ajax

A presentation I gave at Web Directions South in Sydney, Australia in September 2006.

Maxine Sherrin: Hi, and welcome to the Web Directions podcast series. The following presentation, “Explaining Ajax” with Jeremy Keith, was recorded at Web Directions South in Sydney on September 28, 2006. For more materials from this conference series, please visit webdirections.org.

This podcast is licensed by Web Directions and Jeremy Keith, under a Creative Commons Attribution Share Alike 2.5 license. Please include this audio license notice with any copy or derivative work of the podcast that you distribute. And now, over to Jeremy.

Lisa Herrod: Hi, I am Lisa Herrod. I am a usability consultant here in Sydney with Access Testing, and I am very happy to be introducing Jeremy Keith this morning. He’ll be talking about “Explaining Ajax,” and how it can add value to your site. Interestingly, last night we had dinner, a group of us, at a Chinese restaurant, and I found it really interesting that Jeremy seems to have a budding passion for writing messages for Chinese cookies — which I thought was interesting, considering he’s into JavaScript. [laughs] Anyway, this is his first trip to the southern hemisphere, and the furthest east he’s been invited. So let’s all give him a great welcome.

[applause]

Jeremy Keith: Thank you. Thank you very much, Lisa, for those warm words of welcome. Before I start, I do want to say that this is kind of a dream come true for me to be here at all in Australia. It is just fantastic. It is the first time I have been here, and it really is a thrill and an honor for me to be here.

What I am going to be doing today and tomorrow is I’ll be talking about Ajax, and I am hoping to answer some questions. I am certainly going to be asking some questions. Tomorrow, the question that I want to ask is, “How do we build Ajax apps?” So it is going to be fairly techie and kind of hands-on. But today, I am going to ask, “Why would we even want to use Ajax?” And the really basic question: “What is Ajax?” That is what I am going to ask. Hopefully I’ll be able to answer the question. Also, I am hoping to get lots of questions from you guys; we’ll leave plenty of time for that. So let’s see how that goes.

So what is Ajax? That is the question I am going to attempt to answer. So let’s go straight to the mother lode. Let’s go to the godfather of Ajax. This is Jesse James Garrett, and he’s the guy who coined the term “Ajax” in an essay called “Ajax: A New Approach to Web Applications.” He works at Adaptive Path, in San Francisco. So let’s get a quote straight from that article on what Ajax is. He says, “It is really several technologies, each flourishing in its own right, coming together in powerful new ways.” Which is a good description, but it does not really tell us that much about what Ajax is.

So why is it so important that he wrote this essay, that he coined this term? Because he put a word on all of these technologies together and words are really powerful. It really matters when you can put one word to a fairly nebulous concept.

In fact, in linguistics, there is this idea of the Sapir-Whorf Hypothesis, which — it is not credited, but the idea that Edward Sapir and Benjamin Whorf came up with is that language drives our thinking: that in order to think about something, we need a word for it.

The example they quoted was the old adage about Inuit people having 50 words for snow, which has been much quoted ever since. Actually, that turned out to be a crock, because Inuit people do not have 50 words for snow, and the whole idea of the Sapir-Whorf Hypothesis does not really work. It has been used in literature, like in “1984”, by George Orwell, the idea of Newspeak: that language would control how people would think, and in the future the only definition of the word “free” would be “This dog is free of fleas.”

So the Sapir-Whorf Hypothesis is an interesting idea, probably isn’t actually true, probably isn’t anything to it, but there is certainly something to the idea that language drives how we think about things. Having a word, having a label that you can put on something, or a group of technologies, as Jesse James Garrett said, is really important.

It is also important to have a good word. He chose that word “Ajax” and it wasn’t the first time that the word “Ajax” has been chosen to label something. There is the household cleaner Ajax. In the Netherlands there is a football team called Ajax. The Dutch hate this term “Ajax” for anything, it gets very confusing for them.

And then, of course, there was the original Ajax in the “Iliad” by Homer. He was the ur-Ajax: a very powerful warrior, the son of Telamon, and he had a big spear and a mighty shield. But most important of all, he had a very cool name. That was his real power, was having a super-cool name.

And then today we have Ajax, which is generally thought of as being not just a word, but as being a buzzword. You know, maybe it is. Maybe it is a buzzword. Maybe that is not necessarily a bad thing. As a buzzword, it is very good. It has really taken off. That essay by Jesse James Garrett was written just over a year ago, and the explosion in the use of the term has been extraordinary. It really has entered into popular consciousness.

It is kind of hard to explain why that would be. Clearly, it is a cool word. I have my own theory about why it is such a popular word, and that is the fact that it has the “X” in it. “X” is always good.

And also, the fact that it has a mythological reference just makes it sound really cool as well. So if anybody’s looking to coin the next big buzzword, I have a couple of suggestions. You might want to go with “Excalibur,” right? You’ve got the whole Arthurian thing going on; you have got the letter “X”. “Excelsior,” that just sounds right.

The Egyptian, there you go, for Luxor — that could probably be an acronym for something; I am sure you could figure out some letters to go with it. Because clearly, we do need more words with the letter “X” in it in our day-to-day life. We just do not have enough words with “X” in it.

But back to our particular word, which is “Ajax.” Is it a buzzword? Well, it kind of is, but that is OK, because buzzwords can be a good thing. I think there are two kinds of buzzwords. There is a kind of buzzword where you take something that everybody knows what you are talking about and you just put a word on it, and it makes it easier to talk about these things, because everybody means the same thing when they say that word. That is a good buzzword.

Then you have got the bad kind of buzzword. You have got the kind of buzzword that means completely different things to completely different people. Five people are sitting in a room and they are all using the same term, but they all mean completely different things by it. There is a certain buzzword, that I am not going to say out loud, for fear that John and Maxine will get cease-and-desist letters from Tim O’Reilly, that I put into that second category, where it just means different things to different people. You ask ten different people what this other buzzword means, and they’ll come up with all sorts of technologies and things that are part of it, and everyone will have a different answer. It is a bit of a shame, because obviously there is a big backlash against this term that I am not going to mention.

The parts of the term, the bits, the technologies themselves, might be very good, but if people dismiss the overall term, they run the risk of throwing the baby out with the bathwater, where all of these technologies that should be judged on their own merit will get thrown out just because they are part of a fairly crappy buzzword.

So I think each one of these technologies should be judged on their own. It is especially important with Ajax, because of all the words that get conflated with the other big buzzword, Ajax is the one where people think it is basically a one-to-one relationship, that one equals the other, and that is not true. Ajax is its own thing, the 2.0 stuff is its own thing; let is judge each technology on its own merit. So when we are looking at Ajax, let us try and divorce it from the connotations, from the hype, from the marketing buzz around it, and let us look at it for its own merits.

So how will we do that? How will we judge Ajax as a buzzword or as a technology? Well, we are going to use this, which may look to you like a meaningless squiggle, but it is not. This is actually a diagram. It is the first time I have ever used a diagram in a presentation, and I am rather pleased with it. I have actually ripped this off; I did not come up with this diagram, this is a proper diagram from the Gartner Group. This is called “The Hype Cycle.” They have plotted how technologies develop, how they get hyped up, how they die off, and they have put this all into a graph. So they have graphed it like this, and then they have gone and labeled the various points on the graph, which we will go through.

What I love about the way they have labeled these points on the graph is that clearly, the people at the Gartner Group are frustrated science-fiction/fantasy geeks. So it begins with the “Technology Trigger” down there. And boom! Up we go to the “Peak of Inflated Expectations” which can be straight out of Tolkien. “Amon hype.”

After the “Peak of Inflated Expectations” we go all the way down to the “Trough of Disillusionment”. I love that; it is like the bog of eternal stench. Do not despair, because we can climb out of the “Trough of Disillusionment” and we get “The Slope of Enlightenment”, grasshopper. Finally, we hope to reach the “Plateau of Productivity”, which does not actually sound like a very exciting place to be, it must be said: it is like the “Dreary Plains of Toil”.

It is a useful graph because you can apply this to so many thing. It is easier to do with hindsight. Think about the bubble in 1999. We’ve got the technology trigger and boom; everybody is expecting great things from the web. Around 2000 or 2001, I think it is fair to say we were all down in the “Trough of Disillusionment”. We have been climbing out on “The Slope of Enlightenment”, and hopefully we are all now on “The Plateau of Productivity”.

It certainly applies to things like the bubble, but what about Ajax? Where does Ajax stand in this diagram? The interesting thing is that I have no idea. I do not know where Ajax is. You talk to one person and they say it is definitely “The Peek of Inflated Expectations”, but you talk to some people who have been doing this for a while and they say they are down in “The Trough of Disillusionment” with Ajax. I honestly do not know and I think we will only be able to tell with hindsight how Ajax fairs. We are aiming for that “Plateau of Productivity” where we can dismiss the hype, dismisses the inflated expectations, where we can climb out of the “Trough of Disillusionment” and we get to that productivity.

Back to Jesse James Garret; let’s see if we can get something more concrete out of him. When he originally coined the term Ajax he was very specific. He has since backtracked on this, but he was very specific about what the term meant. He said the term is short for “Asynchronous JavaScript and XML.” Let me state clearly now that the word is not an acronym. It was originally. When the essay came out, yes, it was an acronym and that is what it stood for, but it does not make for a very good acronym. He has since said, himself, “Look it is not an acronym. It is just this word used to describe things.”

As an acronym it is not very expressive. Going from the bottom, we have got XML. That would lead you to think you must use XML in order to use Ajax. That is simply not true. You do not have to. For instance, you can use HTML if you are sending data backwards and forwards on the web. There is no reason why you have to use XML. You can use HTML.

There is this other interesting technology called JSON. It does not have an “X” in it, but it is still pretty cool sounding because it has the mythological thing.

XML is not required. That is what I am trying to get to you. You can use any data format you like and it does not have to be XML. The “X” part of Ajax straightaway is not so good. I am going to skip over the “and” because I think everyone is pretty clear on what the word “and” means. Then we get the “J” for JavaScript.

This is also throwing people because a lot of people are focused on the JavaScript part. Whenever they see anything with JavaScript they say, “Oh, nice bit of Ajax you have got there.” That is annoying as well because JavaScript is part of Ajax, but it is not the sum of Ajax. The last thing we need is a new word to describe JavaScript, because we have been there before. We had this term DHTML back in the bad old days. That is a terrible buzzword. It sounds like another flavor of XHTML or something like that. It is supposed to stand for “Dynamic HTML.” It was basically a marketing buzzword that was very confusing and not very good.

More recently we started talking about DOM Scripting, because DHTML had become toxic as a word and we needed a new way of talking about JavaScript that was more standards based. So, we have this word DOM Scripting to describe an approach to using JavaScript on the web.

We do not need another word for JavaScript effects. We have got enough terms already and that is not what Ajax is, so do not let the “J” part throw you. JavaScript is a very important part of Ajax, but it is not the be all and end all of Ajax.

Asynchronous. The “A”at the start. This is where it starts to get interesting. Now we are finally starting to nail what it is that makes Ajax interesting and it is this word. It is the asynchronous aspect. What does asynchronous mean? Literally, it means “not at the same time,” which is not very helpful. I think to understand what asynchronous means we have to first look at what a synchronous request is like.

Up until now what we have had is essentially the synchronous web. You have a client-server situation like this: you request something from a server you wait and the server sends back a document. This is what we are all used to.

When you send a request like that you have to wait. You can’t interact any more with what is in your browser. You have to wait for a full page to come back and only then can you carry on doing whatever it was you were doing: looking for information, or completing some task. There is this barrier in your way. We have to stop every time you ask for something new from the server. It is synchronous interaction.

The asynchronous interaction begins the same way. It begins like that, but now every time you want to request something new from the server it happens asynchronously, which means you can carry on interacting with what is in your browser. That is big. That is what is really at the heart of Ajax.

That is why this is such a cool word and such a cool technology is that users can now interact with what is in their browser, while at the same time they are communicating with the server in the background. The server is able to send information and the server is able to receive information while people are interacting with the documents in their browser. The implications of that are really big and that is why Ajax has really exploded, both as a term and as a technology on the web.

What it results in is this feeling of speed. It is not that requests go any faster. Ajax requests travel at the same speed as any other http request on the web, but the illusion of speed is certainly there. You no longer wait for an entire page to download. You click on something, you fill in a form, you are doing something and you get back a much quicker response because you do not have to wait for the whole page to load. You are just talking about fragments of pages or bits of pages.

While you are waiting for that little bit to load, you can be reading some other part of the page or carrying out some other piece of interaction on the same page. You get this illusion of speed which is really important.

Whether it is faster or not is almost irrelevant. It is how it appears to the user and to the user you get this feeling of speed. That is the heart of Ajax. That is why it is exciting; because of this asynchronous interaction and this feeling of speed. If you use it wisely you get this real feeling of a nice, fluid experience.

I am trying to describe how this feels for the user. I want to put up some quotes. This is Derek Powazek, a great guy who has been making websites for years. He is pretty much responsible for me getting on the web and learning HTML because he had this site called Fray.com, which was just amazing. He described Ajax like this: “If the traditional web was letter writing, Ajax is instant messaging,” which I think is a great way of describing it.

Think about writing a letter and you have to take it to the postbox and then the postman has to send you back a response. You have this wait between sending the message and receiving a response, whereas in instant messaging you are typing and the other person is typing. You have this instant back and forth communication. The speed factor, this asynchronous factor is what really makes it good, so I love that description of Ajax.

Here is another one from Bruce Sterling, the science fiction author and technologist. He put it very simply when he said, “Ajax is like roller skates for the web,” which is, I think, a pretty cool definition because that is how it feels; that feeling of speed.

We have got all these great descriptions on how Ajax feels compared to the old web, but we still have not nailed a definition. I keep skirting around the issue. I have not actually nailed down: what is Ajax? I am going to try. I am going to go for a quote and I am going to try and pin down what Ajax is. Here is my definition. “Ajax is a way of communicating with the server without refreshing the whole page.”

It is not sexy. It is not pithy, but I think that is pretty accurate. It is a way of communicating with the server without refreshing the whole page: that is kind of what it boils down to. If that is the case and that is the definition of Ajax, and then what are the technologies that allow you to add Ajax to your site, according to my definition?

According to my definition, frames. Think about it. You load in one set but you keep the other frames. You are communicating with the server and you are not refreshing the whole page, so frames are a form of Ajax, maybe. The modern day version is, instead of using frames us an iframe. You can refresh the iframe without refreshing the whole page; so technically, according to my definition anyway, those would be considered Ajax technologies.

Flash has been doing this for years. I am not even talking about the Flex framework that is capable of very powerful server-client communication. Just think about regular Flash movies. It is always been a common technique to first load in a movie that is essentially a framework and then when people click on things or request things you load in more data from the server. You are loading in data from the server without refreshing the whole page, so by my definition Flash would be Ajax.

Really when we talk about Ajax and when we talk about communicating with the server without refreshing the whole page, usually what we are talking about is XMLHTTPRequest. From the length of that name you can see why everyone was so glad that Jesse James Garret coined this nice short term, Ajax, because it gets very tired very quick having to say XMLHTTPRequest all the time when you want to talk about communicating with the server without refreshing the whole page.

So yeah, maybe Ajax is a buzzword, a snappy little term, but it does make life easier that we do not have say this all the time. This is not a particularly good buzz word; although it must be pointed out it has an “X” in it, [laughter] which is good.

So this XMLHTTPRequest is usually the technology which is used for Ajax requests and it has an interesting history. So this very powerful technology that you can use in normal web pages to communicate with the server was invented by Microsoft, not the W3C, not some standards body, it was invented by Microsoft.

There was this Microsoft team working on building a web-mail client and they needed some way of fetching data from the server about emails, they needed someway of fetching that data without refreshing the whole page, so they said that to the IE team and the IE team said “We have come up with this solution called XMLHTTPRequest. Use that to communicate with the server.”

What is interesting is when that happened. When they did this, it was for IE 5. So we are talking about 1999-2000, I think. This has been around for six years. This is nothing new. So why is it now, all of a sudden, that we are starting to see this buzz and it is the big term and it is the hyped word?

Well, really, when the technology is tied to one browser, there is only so far it will go. But XMLHTTPRequest was clearly so useful that other browser makers implemented it. So, the Mozilla engine has it, Safari has it, Opera has it now. All the major browsers implement XMLHTTPRequest.

In fact, it has become really clearly a de facto standard. So much so, that now the W3C themselves are documenting it and are going to put it forward as a recommendation, one of the very few cases of a proprietary browser implementation being taken on board as a standard. And there is some great work, very fast work, happening at the W3C around XMLHTTPRequest and around web APIs being led by your very own Dean Jackson with his trusty sidekick Anna van Kesteren, and they are doing very good work there.

So it is become this ubiquitous thing, even though it started life as a proprietary technology, it is now moving into the standards based sphere, which kind of upset some programmers. The guys have been around for years and they have known about this object for years and they are like “What’s the big deal? Why is everyone all of a sudden talking about Ajax? I’ve been doing this for years, we just called it remote scripting,” and they do not get why it is a big deal.

Clearly they are missing something to take that attitude, because there is something new, there is something different. Things have changed. There is the browser support, the rate of broadband adoption. Things have changed. It is not like the old days. Something is different. Ajax is something more than old-fashioned remote scripting.

So you have this attitude which is not that helpful, but then you have got the other attitude which is equally unhelpful. You’ve got the suits. And they’re approaching it from the other way. And they’re saying, “Ajax is a whole new paradigm, baby. It is fantastic. It is going to revolutionize the web and we can throw away everything we have done before.”

And that is equally useless, that approach, because that is not the way to approach Ajax. It is a tool, a technology. It can be useful, but it is not this complete break with everything that has come before. It is an evolution, not a revolution. So I think the truth about Ajax lies somewhere between those two opinions. Yeah, it is just programming. Yeah, it is just a way of getting things done. It is not a whole new paradigm, but there is something new and something exciting about it.

Halfway between those opinions we have Ajax. Hopefully by now we have nailed down a bit firmer what Ajax is. So, with that it mind, I am going to try a bit of audience interaction here and we are going to play a little game show called “Am I Ajax or not?” And what I am going to do is show a screen shot and describe the interaction and I want you all to show as loudly as possible “yes” or “no” when I ask you, “Is this Ajax or not?” and we will see how well we can recognize just what Ajax is. Okay? Is everyone okay with that? Let’s go.

Google Maps. Kelly also had a screen shot of Google Maps. I should point out for full disclosure that we are actually breaking the Terms of Service of Google Maps by showing them in a presentation. [laughter] But here is Google Maps. We are looking at ourselves from above. It really revolutionizes the whole mapping thing when this came along and you could drag around. So you are able to drag the map around and as you do that the extra images that are required for those bits of maps around the edge are being pulled in from the server. We do not have a full page refresh, but that extra bit of information is coming as you drag around the map.

So, am I Ajax or not?

[shouting]

Jeremy:Mostly “Yes”, I think. A couple of dissenting voices, but mostly “Yes.” Well, I would consider it Ajax from the interaction and the way, like I said, that it is pulling images in from the server, but this does not use XMLHTTPRequest. This is actually using a hidden iframe to communicate with the server. That is why you are able to use Google Maps on your own site, because XMLHTTPRequest can only actually interact with pages on your own server.

Clearly from the way I have described Ajax as a way of communicating with the server without refreshing the whole page this would qualify, but it is not using XMLHTTPRequest which kind of throws you. So let us put that in the “Yes” camp. I think that was the overriding decisions by a couple of loud “No”. Let is say that is Ajax.

Bunny Hunt. Now this is a game that Cameron came up with. Bunnies pop out of the bushes and you shoot them, and you get a good score and you have various lives and it is all done with JavaScript. So there is this animation going on. Really cool stuff.

Bunny Hunt. Am I Ajax or not?

[shouting]

Jeremy: Mostly “Yes”s but a couple of “No”s, I think. Some very loud “No”s. No, this is not Ajax. There is no communication with the server going on here. This all loads into your browser and then you start killing bunnies.

There’s no communication with the server, despite the fact that I came across a blog post titled “Ajax Games” and it listed all these games on the web that were supposedly Ajax and this was one of the games list, but this does not use Ajax and this comes back to what I was saying about the “J” in Ajax, the JavaScript part.

People are starting to confuse any type of JavaScript for Ajax. This is clearly a very, very, very powerful use of JavaScript, but that does not necessarily make it Ajax, because that communication with the server is missing and that is the key point. So Bunny Hunt from Cameron Adams, I would not consider Ajax.

Speaking of Cameron Adams, this is Flickr.

[laughter, applause]

Jeremy: For the benefit of people the people listening to the podcast, I am cruel, I am cruel, yes. This is a picture on Flicker entitled “Topless Cameron Diaz.” As Kelly mentioned, I really love Flickr. It is very much part of my habitual daily routine going on there.

And Flickr makes it really easy to interact with your photos because there is so much that you can do to your photos in the page without having a full page refresh like all these options above the image to add notes, do all this stuff. You do all that without the whole page refreshing.

Right here I am changing the title of the page. So the title of the picture, I can go in and I can edit it with a form and I when I press Save or Cancel, I will not have a full page refresh. It will just do it right there in the page and that data will be sent back to the server and it will now have the new name of the picture stored on the server.

Am I Ajax or Not?

[shouting]

Jeremy: Yes, I would say Flickr is most definitely Ajax. In fact they have their own term for the kind of Ajax that they use called “Scrumjax.” Do not know how that is going to work as a buzzword, but it does have an “X” in it, so they’re doing well. And I apologize Cameron. Where is Cameron? It is rather cruel of me to be showing embarrassing pictures of my fellow speakers.

This, what I am demonstrating here, is lightweight JavaScript called Lightbox. What you do is you have all your thumbnails on the page and normally you click on a link and you get taken to that link. Well with Lightbox you are clicking on a link to an image and it displays that image above the current page, it fades out the background, so, a very nice way of viewing images.

Am I Ajax or Not? No. Well, here is the interesting thing. It is pulling back the source of the image. What it is doing is updating the source attribute of an image tag, so technically that image is sitting on a server and I am communicating with the server by updating the source tag, but Ajax? I do not know. That would be really pushing it.

There is a form of communication going on with the server because we are changing the source of an image, but really all the information that we need is stored on the current page and we are not requesting any new information from the server, so no, I wouldn’t consider this Ajax. I would consider it, again, a really good use of JavaScript, a really nice script, and, again, I have seen confusion over this and I have seen this referred to as Ajax, but no, it isn’t, it is just a very good JavaScript.

Amazon. I am focusing particularly on this part of the page. Where they have a list of products and whatever, and they ask me if I want to rate this. My option out of five stars; I can choose which one. I click on one of those stars and the whole page does not refresh. It just says “Ok, your preference has been stored; we’ve got it,” so that information has gone back to the server and it is storing my input without refreshing the whole page. So, am I Ajax or not? Yes, this is Ajax. I would call this the quintessential use of Ajax.

So, there is quite a big difference in the bits of Ajax we are seeing, I mean they are all over the place. How about this one: an RSS reader that is in the browser. On this side, they have got lists of weblogs and RSS feeds and an “unread” count. It works pretty much like a desktop RSS reader. I click on a link and then I get the full page view in there. Am I Ajax or not? Who said no? Why are you saying no?

Audience member: Well, for this version of the user list you can’t tell, I’d suggest that by downloading the hang-ons this is an iframe, sorry, a frame in the same way that the logon works, so it is not.

Jeremy: So, for those that did not hear the idea, he said that probably what’s happening here is that it is an iframe being updated. Actually, this is Ajax, this is pulling it in, but that is just a technology. You know whether it will be an iframe or whether it will be XMLHTTPRequest should really be pretty irrelevant because we already decided that Google Maps was Ajax and that uses an iframe.

Your overwhelming response there was yes, this is Ajax. So this is Ajax because you are pulling in the data from the server; we’ve got the basic list here and then we are pulling in full posts over there, and all this happens without refreshing the whole page. You just click around on this side and that updates what happens over here.

So, quite a large portion of the page is being updated in this case, but not the whole page. It is kind of an edge case for Ajax, about whether… “Does this actually gain anything from being an Ajax application? Is it any faster? Do you get that speed benefit because you are not updating the whole page?” I’d say you do a bit because this list can be quite long and you do not want that loading in the whole time. But you are quite right; this could just be done with frames, really. It would still be Ajax in a way, communicating with the server.

This is Meebo. This looks like somebody’s desktop - this is the inside of a browser and this is a chat client inside the browser chrome. I can log on with my AIM name and with my MSN account and I can start chatting with people - that is my buddy list coming up. Am I Ajax or not? Be a bit more confident about this, come on! Am I Ajax or not?

Audience: Yes!

Jeremy: Yeah, very much so. When people talk about Ajax, this is the kind of thing they are talking about, they are talking about creating desktop applications that just happen to be sitting in the web browser. This has gone so far in the direction of being so application-like it is really confusing. It is almost like “What? Wow, that is really hard to get my round. I am actually looking at something in the browser, you know, I can drag these windows round; I can talk with people through this chat client that is sitting in a browser, it is pretty crazy.”

So there is this huge range, looking at all these examples, there is a sliding scale really, because we decided Meebo is Ajax and we looked at that Amazon rating thing and we said that was Ajax too. There is quite a big difference between the two. On the one end, you have got the traditional web and you have got documents. On the other end of the scale, you have got web applications. So something like the Amazon rating system is a document that is been enhanced with Ajax, but it is still basically a document with a couple of nice little extras.

Whereas, Meebo is an application that just happens to be sitting on the web. It would be pretty hard to describe Meebo as a document, and yet this term, Ajax, is being applied for everything. It is being applied for everything on that scale, and that can get pretty confusing to have just one term describing so many different things.

I personally think that Ajax is good for things at the start of that scale. I think Ajax is good for enhancing existing pages when you recognize a certain pattern. I mean, something like Meebo is very impressive, but I wonder why they did not just make a desktop application or why did they not do it in something like Flex, which is all about making widgets and making interactive components.

I think when you get towards that end of the scale where things are really like applications that just happen to be sitting in the browser; maybe you should be using a different technology. I think maybe Flex; maybe some kind of widget on the desktop would be a better technology.

But, at the other end of the scale, at the beginning of that scale and towards the middle, we have our web pages, web sites that are enhanced enormously through the use of Ajax, and here is the pattern you should look out for when you are thinking of enhancing a page using Ajax.

You are on a page and you interact with that page by clicking on a link or filling in a form and you send a request to the server, OK, the page goes off and you get back an entirely new page that looks exactly the same, but only one small portion of that page is updated. That is the ideal opportunity to use Ajax because that is where that illusion of speed, the asynchronicity, would be really useful.

So think about situations like a logon form. I mean, it is so nice to have this on so many sites where you are told “choose a username.” You have been in that situation, you have got a big page, and it might be quite a heavy page. A very simple form: just choose your username. You choose your username and you hit submit and off it goes. You get back the same heavy page, all again, and it is exactly the same except there is a message on there saying “Sorry, that username has already been taken.” And if you have tried to open a Yahoo email account or a Hotmail account, you do this about a thousand times before you finally hit upon a username that nobody else has chosen.

Wouldn’t it be nicer if that all happened without the full page refresh? I choose a name and hit submit and I get the message on the page saying “Sorry, that one’s taken, try again”. I do not have to wait for the whole page to load. It would be the perfect time to use Ajax to enhance the experience.

Shopping carts. Ok, usually you are on a big page there, you are on Amazon and it says “Add this to my cart.” The whole page will come back and now your shopping cart has been updated to say “Something is in the cart”, that is all that is changed on the page. It would be ideal there to just update the shopping cart. I do not need to refresh the whole page; I just want to refresh part of the page. So there, again, that would be a really nice use of Ajax.

The ratings we saw on Amazon, I think that is the perfect use of Ajax: where you are updating one tiny, tiny bit of the page. That means I can add 20 product ratings fairly easily, oh yeah, four stars, three stars there, two stars, and because it is asynchronous, I am able to do that and in the background it is sending the information to the server. And I do not have to wait for the server to say “OK got it, thanks for that,” I can just carry on rating other products. If I tried to rate 20 products and each time it required a full page refresh, I would give up. Whereas, using a little bit of Ajax to just update that small part of the page, I am much more likely to do it, it is going to make my experience much nicer.

Adding a comment onto, say, a blog. You have got the blog post, you might have 50 comments and then there is a form at the bottom. You fill out the form, you press submit and you get exactly the same page back, but now your comment has been added. That might be a good time to think about using Ajax because, again, you are updating just part of the page, you do not need to update the whole page.

So this pattern you start to see over and over again. But you do not want to go too far, I mean, what about search results? You are on a page to search a site, there is a search form. You fill it in, you hit submit, it goes off to the server and comes back with the same page, but now there is a list of search results. Is that a good time to use Ajax? I am not so sure. For one, people are used to this interaction, getting a page of results they can interact with. Maybe they want that first page of page results as its own page. So maybe there, I do not know, I am not convinced that would be a good time to use Ajax.

But even if you did not use Ajax to get the search results themselves, what about the pagination? What about after page one? You know, where you move forward through page two of the search results, page three. There, you are just updating parts of the page; you do not want to get everything around the search results updated. I do not know, that is a lot of the page to be updating. That should trigger warning bells; when you are updating so much of the page you kind of have to ask “Well, why do not I just go back to it being a normal, full page refresh?” So for the smaller stuff, I think it works really well. For these edge cases, I think you’d have to take it on a case by case basis.

I want to talk about why you do not want to be so quick to use Ajax. Why you should not just throw it around willy-nilly, because Ajax introduces its own challenges; any new technology does.

Let me have a bit of a rant and rave about design challenges and technology. These are traffic lights that I came across, I was in Manchester a few months ago. I had heard about these, I was listening to BBC Radio Four interviewing the guy who came up with these and I could not believe how badly-designed they sounded and I thought I had to experience this for myself. They were worse than I imagined.

So you are all familiar with traditional traffic lights, I think all over the world they work much the same way. On the other side of the street is your signal that tells you whether you can walk or not and you wait for the red man to turn to a green man or the word “WALK” to change to “DON’T WALK” or whatever. And once you start walking, you still have your signal across the street. You can still see how safe you are, whether it is okay to be crossing the street.

These new traffic lights, first of all they have the signal at waist height on the same side of the street as you. So you have got three or four people standing there and you cannot even see the signal because it is at waist height, but when the red man changes to being a green man you start walking across the street. You do not know anymore whether that is a green man or red man, you have no access to that information.

It is just really badly designed, but the thing is, technologically, apparently it is a wonderful system. It has got all this great technology using infra-red, and motion sensors. They say, “No, no, no. You do not have to worry about it, because we can tell if you are crossing the road. We’ve got all these wonderful gizmos. It will never turn to a red signal as long as somebody is crossing the road.” But, for the user, the person crossing the road, they do not know that. They do not know about this great technology. And frankly, even if you know in your mind that it is OK, not having that signal, sort of makes it a really unnerving experience.

This is something else I have; I noticed when I was flying in here. When I am in an airplane I kind of like to be near the window, either the window seat, or somewhere I can look out the window. And it is not because I want to view the beautiful clouds and see the lovely scenery. It is that when I am coming into land, I want to be able to see how far I have to go till we hit the ground. Because I hate being in the middle of the plane, I can’t see the windows, and I do not have that information, that it is one second, that it is five seconds away, and I spend the whole time clenched up thinking, you know preparing for impact basically.

[laughter]

I like to have the visual information, so being able to see the runway is something that you should offer when it comes to doing Ajax. Think about the technological implications. I am going to quote this well know Sith Lord who once said, “Do not be too proud of this technological terror you have created.” The technology will only get you about so far, what it is really about, the problems, the challenges, with Ajax aren’t to do with technology. The technology is pretty matured at this stage. It is to do with the user experience. It is design challenges.

What is happening, I mean this is what I am talking about with the airplane you know, I want to be able to see what is going on, where am I, where is the runway. This has never been a problem before, because the browser has taken care of this for us. We have some logo up in the corner, okay, like the E, or the lighthouse in Netscape, or whatever. And when we click a link, we submit a form, immediately there is feedback that something is happening, that a new page is being requested, ‘cause the logo starts spinning. Something starts happening to say, “Okay, we are requesting a new page from the server.”

Now, if you use Ajax you are bypassing that information. It is now up to you to inform the user, “Something is happening, do not be scared, the runway is not too far away, this is what is happening.”

And there is various ways of doing this, and then the most common is to use some form of looping animation, much like the logo in a browser, or you have the progress bar that moves to indicate something is happening. These are sort of familiar from desktop applications. And again, I talked about Flash being a form of Ajax, Flash people have been confronted with this problem for years, where they were requesting something from the server, and they need to inform the user, something is happening; we are pulling information from the server, if you just hang on, and we will be okay.

So, if you are trying to decide you know, how do we even begin to indicate that something is happening, take a look at what the Flash people have been doing. They have been confronting this challenge for many, many years, and we can learn, we can learn a lot from them.

And just as important as, “what is happening” is indicating “what has happened” because it is pretty straight forward with a normal page request. You get a new page, that indicates that something has happened.

So, I am sure you might be familiar with this example, all the 37 signals projects have nice little uses of Ajax in there, and if I add an item to, “My Tada List” like this, it highlights the item, and then fades away the one that was highlighted.

So, just to indicate this bit of the page has been updated in case you missed it - this is the part to the page that just got updated. And that is kind of nice since it is fairly subtle, and it is a way of indicating something happened. And you are starting to see this crop up on other sites as well, and I think that is pretty good because what that establishes is a convention, and conventions can be very good at removing the fear from people. Once they’re used to some interaction, conventions are good. I am not going to get all Nielsen and say, “You know, all our links should be blue and underlined,” but conventions are good.

Kelly talked earlier about making the experience pleasurable, and all this 2.0 stuff is all cute, it is to do with taking away the fears, it is remove the fear from the technology, and conventions help in that regard. And there are quite a few conventions built around Ajax, there is the status indicators I mentioned, so progress bars, spinning wheels, you know hour glasses, stuff like that, we can borrow these conventions. The yellow fade I talked about with 37 signals. If a lot of sites start using it, it makes sense to jump on board and start using it as well, because people get used to that and it is working. It is kind of a Darwinian thing; the best solutions seem to survive.

So, taking conventions is good, but you do not want to go too far. You are starting to see people have been borrowing the drag-and-drop convention say, “Well, everyone is familiar with this from the desktop, so we are going to borrow that convention and apply it to Ajax,” and there is a real danger there. There’s a real danger because people borrow in a half-assed way. They think the only way of interacting with something is to drag it from one part of the screen to another part of the screen and they are saying, “This is just like the desktop.” No, it is not. On the desktop I can drag something and drop it, I can go to my file menu and I can do the same action, or I can use a keyboard shortcut. And if you borrow drag-and-drop, you need to borrow those other ways too; you can’t do this in a half-assed manner.

And frankly, I am not convinced that everyone is used to drag-and-drop. We are, you know we do it all the time, and we are dragging our files around, but I am talking about people out there using computers, my mother does not use drag-and—drop. So, we should not be so quick to assume that this is what people are used to. And, if you are going to borrow, you got to borrow wholesale; you can’t borrow half-heartedly.

Yahoo came across this when they did this big Ajax email client. They allowed you to drag mail messages by dragging the subject over to a mailbox, and because their users were able to do that, they expected to be able to do all the other things they could do on a desktop, like click on something, and then shift-click on something else, and select everything in between. Because they are being told it is the same convention, then they expect exactly the same convention, the same experience. So, I avoid the problem altogether and say, do not be so quick to borrow these conventions, which I’m not so convinced are popular and familiar to everyone. I mean fly-out menus, right? Do not even get me started on those.

Most importantly, I mean the drag-and-drop thing to the Yahoo people; they really did some research into this. This was a Yahoo site where they documented what it really means to drag-and-drop, and they came up with this table of interesting moments. If you ask you of me, “What’s it mean to drag-and-drop?” I say, “Well you click on something, you hold it down, and you pull it over to somewhere else.” And I would have stopped there; I would have thought that was drag-and-drop.

But, they documented all the points in between that you have to take care of, or you will confuse your users, you will upset somebody if you do not cover all of these interesting moments. So, it is not as easy as it looks to borrow these conventions. And Albert Einstein put it best I think when he said that you want to make solutions “as simple as possible, but no simpler.”

So, when you do use Ajax, avoid the complexity of things like drag-and-drop, but you still have to provide some form of complexity in terms of saying, “Here is your feedback. This is how long you have, you know to carry something out, and this is something that is happened, something that is updated.”

So there is a certain amount of complexity involved, but do not go too far down that road. Complexity itself is not something to aim for, because what we are dealing with here is a situation where we are beyond the browser. We can no longer rely on the browser to take care of issues that it is always taken care of up till now.

For instance the back button has become essentially, “undo” on the web, people use this more than any other part of the browser. They go, they Google something, they click on result, “Oh, that is not what I want, step-back, undo, I am using the back button to go backwards.”

Now with Ajax you are taking that out of the equation, there is no more history stack. So somebody clicks on the link, somebody fills in the form, the page updates, if you click the back button you will not go back to the previous state of that same page, you will go to the page you were on before.

Now, there has been a lot of people that have been doing some very clever research into this and trying to solve the back button problem, all sorts of clever JavaScript updating the URL, and all this kind of thing. I think it is better to avoid the problem.

If your users expect to be able to click the back button to undo something, you are probably using Ajax the wrong way, you are probably updating too much, you are changing too much of the page. Because something like the product rating on Amazon, I click the four stars, and it say, “Right, got it.” I would never expect that clicking the back button in that situation would take me back to the page before I clicked those four stars.

And also this idea of the back button as meaning “undo” has never really held true on the web. I mean, if I am on a page with a form and I fill in that form, and it is sent off to the server, and I get sent a page that says, “Thank you,” and I hit the back button and go back to the form, I have not undone the act of sending that information to the server. So, the back button a lot of the times feels like “undo,” but even not on Ajax applications, it does not really mean, “undo”. And I think that the trick is to avoid getting into situations where people expect to be able to use the back button to undo something. Avoid that situation. If you find that is what your users are doing, rethink what you are doing, rather than trying to solve the back button problem.

And related to that of, course, is bookmarking. People update the state of a page using Ajax, and they think, “OK, now I want to bookmark this changed state.” If people want to do that, you probably should not be using Ajax.

The search results in the pagination of something imaged earlier, you know maybe people would want to bookmark that first page of search results, so maybe Ajax.

Another thing that is really important to your users is discoverability. Here again, people think Ajax is a whole new paradigm, we have to try whole new solutions. We do not. We can just rely on what comes before. Links; people click on links to do something. Forms; people expect to fill in the form and have a response. Flickr does — bringing up the most popular slide so far to show you this — on Flickr what I want to add is a title there. I mouse over; that turns a slightly different shade: yellow. In its title attribute it says “Click to edit.” That is pretty hard to discover.

Again they get a bit clever there. Why not just use what you always work with? Just have a link saying “edit” or an icon. Icons work well. We do not need to invent new solutions for all these problems. That is just built-on what comes on before. We do not need to make a complete break with past here.

This is Joshua Davis, who did “Once Upon A Forest”. I keep saying that we can learn a lot from Flash people and this guy has really got his head screwed on right. And he’s been making great sites, great applications, great user experiences for a few years. It was six years ago: “What qualifies as good design?” I love what the response was. It is, “Being able to justify every pixel.” You do not do something for sake of it. You do something for a reason.

I went to Art College for a few years and it was the same thing, it was not enough to paint. You have to say why you are doing something. What is the reason for doing something? I ended up dropping out but the point is that you do not do something without thinking. You really think with Ajax. Why you are using Ajax? Why are you using an Ajax request instead of regular page request? Why? You have to be able to justify every design decision. When you can do that, I think you got a good work flow going.

Most of all, no matter how convinced you are, “this is great” and you created one of the best user experiences, nothing ever compars to actual user testing. Get behind some two-way mirror and watch people actually using your applications. It is a humbling experience that every designer has to go through.

We have all these guidelines about when to do use Ajax or when not to use Ajax, how to indicate status has changed, how to indicate something that happened but at the end of the day, you’ve got to test it.

There are challenges with user testing of Ajax because, with a regular application, you can test very early on in the process by using prototypes. Before a line of code is written, you can test very early on by using paper prototypes, right? Before a code line is written, you can just film people using paper prototypes. It is a bit hard to do that with Ajax. It introduces challenges when it comes to wire-framing or user testing but you must user test. You must, must, user test.

The biggest challenge of all, I think, when it comes to Ajax is the question of accessibility. I am talking about accessibility in the more specific sense of screen reader technology. Of course, you want to provide sites accessible to everyone in terms of technology.

The definition of Ajax in The Devil’s Dictionary — and I love this — is “Accessibility Just Ain’t eXciting” which is how a lot of people are viewing Ajax. That is kind of: “Throw the accessibility rule books out the window” and say, “We do not have to deal with accessibility because we are dealing with Ajax now. It is not a concern.” That is completely rubbish.

I am going to quote one of my fellow speakers; Thomas Vander Wal. He said in a blog post after he had a frustrating experience with a piece of Ajax technology that “It must be accessible, it must be usable. If not, it is a cool useless piece of rubbish for some or many people.” That is not what you want from your product.

What he is talking about is accessibility in term of devices; he wants to be able to access his mobile device. There isn’t a specific user agent that he should be using to access the information.

But of course, when we talk about accessibility, quite often we are talking about people with disabilities trying to access your information, and there are a lot of challenges in that area.

James Edwards has done a lot of research into this and has done test cases: how do screen readers respond? That is what we have to do because it is no good coming with theoretical papers about how screen readers might respond or what we should be doing; we have to test with real people, using real screen readers, on real applications.

He did some test suites and what he came up with was “Unless a way can be found to notify screen leaders of updated content, Ajax techniques can not be considered accessible.” He also said, “We haven’t explored all the options.” There may be possible solutions we can explore here. We have some smart people working on this like Derek Featherstone who will be talking about this sort of thing.

Basically the major problem is informing the screen reader that part of the page has updated. It has nothing to do with Ajax per say, if Ajax is to do with communicating the server, it’s the fact that the screen has been updated — you might have not done that from the server because regular DOM Scripting, regular JavaScript; same problem applies: how do you inform the screen reader?

So this is kind of depressing; the results. But at the same time that James was doing that, Joe Clark also did some testing and he did it with Basecamp or Backpack — one of the 37 signals of applications — and he was kind of hoping to find he could rip them a new one but actually, he found the Ajax application is useable by screen Readers… some of the time. They are not totally shut out. So, “Yay!” but… it is not easy for them either. That is kind of depressing. It’s like we are putting stumbling blocks in the way.

The wonderful thing about accessibility on the web is documents are accessible by default. If I write a document in HTML, it is accessible. I do not have to add accessibility features. It is just accessible. It is when we go in and we start adding other stuff that we have to take into account “How will this affect the inherent accessibility of a document?” Ajax, by the looks of it, puts stumbling blocks in the way. So we really need to put our heads together and start thinking about how to solve these problems. I think Derek is going to have a lot of interesting things to say about that.

I am going to finish with one last quote. I have been quoting people throughtout so why I just go for the full cliché? I am going to quote Tim Berners-Lee and use his most over-used and clichéd quote ever. But I think in the context of Ajax, it makes sense bring this up and I think we can be reminded of this which is, “The power of the web is in its universality. Access by everyone, regardless of disability, is an essential aspect.”

Ajax is not a whole new web. Ajax is not a new paradigm. Ajax is the same web with some nice tools with some added speed, with roller skates but we still want access for all and that should still be our priority.

I am probably going to put these slides on my site and I’ll link to them up there with some kind of Creative Commons license. I have used some Flickr pictures throughout this presentation and there are the links to them all. You have been very gracious and generous in listening to me. I want to thank you all very much.

[applause]

I think we have time for one question and we have got microphone runners. It’s got to be one question and it’s got to be really good. I do not want to hear your life story. Just shout out the question and I will repeat it. Who has got a question? Okay, a hand’s up back there. Better be good!

Audience member: I read an article recently talking about problems with pop-up ads re-appearing through Ajax and stuff like that: tracking mouse actions of the user…

Jeremy: Yes. That is absolutely right. The question was about… the person here read an article about the return of bad practices; fake pop-ups being done through Ajax—actually that would be kind of through JavaScript—but something like user tracking thorough Ajax and that is a very good point. There are some privacy implications. This actually refers to JSON technology that I talked about because JSON has an advantage over XMLHTTPRequest in that you can communicate with another server, not just your own server. What that means is that you can be viewing a site or multiple sites that can call home to the mother ship. Now, up to now, every time we have done something on the web, we have to actively click a link, fill out a form and it is only when we press “submit” or follow that link that information is sent to the server.

Now with Ajax, you can be asynchronously communicating based on other events like onkeychange, onkeyup, I can trigger an Ajax call. So, picture this situation: there is a form on a site. I start filling it out: “You asshole…” Then I think better of it and I press backspace. I fill out with a nice email. Then I send the email. But while I was filling that out other information, all that time, a request could be going back and storing that information. There are privacy implications of this.

We have already started see some very clever Ajax applications that do eye tracking, more or less, by using the mouse. Every time we are moving the mouse, there is a signal being sent back to the mother ship saying: “Okay, this is where they are moving. This is how people are using the site.”

That could be really useful. That could be a great research material. But there are definitely implications for our privacy. Maybe we will see the situation of what happened with pop-up ads. A lot of people decided to switch off JavaScript all together. It was not worth the advantages that JavaScript brought with it for these disadvantages; things like pop-up windows. And you actually have it built-in to the browsers to block pop-up windows at some stage.

There are design challenges because people are only now beginning to see these implications of Ajax. Some of these implications are great. They can really enhance people’s lives. There are other implications that are kind of scary. They are kind of scary about what people can track on the web.

I don’t think I have time for anymore. Okay. Thank you all very much again.

[applause]

Maxine: We hope you enjoyed “Explaining Ajax” with Jeremy Keith. For more materials from the Web Directions conference, please visit webdirections.org.