Spoolcast: Jeremy Keith with Jared Spool Podcast Transcript Brian Jeremy Keith interviewed by Jared Spool. Recorded June 6, 2008. Christiansen: [music] Brian: Welcome, I am Brian Christiansen, producer of UIE podcasts. In this week's episode Jared speaks with Jeremy Keith, a web developer from Brighton, England. Jeremy is the technical lead at Clearleft, a leading design consultancy in the UK. Jeremy is the author of the popular books, "DOM Scripting" and "Bulletproof AJAX". Jeremy will be presenting his talk, "Bulletproof AJAX", designing interactive and usable AJAX solutions at our User Interface 13 Conference which will take place this October 13th thru 16th, 2008 in historic Cambridge, Massachusetts. You won't want to miss it. And now, here is Jared. [music] Jared Spool: Hello, everyone. Welcome to another spoolcast. I am very pleased today to have Jeremy Keith on the line. He is coming all the way from Brighton. Is that correct, Jeremy? Is that where you are? Jeremy Keith: That's right, Brighton, on the south coast of England. Jared: That's right. He works for Clearleft. He is going to be speaking at the User Interface Conference in October, and he is going to be talking at that point on the topic of AJAX. He is going to give a presentation called "Bulletproof AJAX", designing interactive and usable AJAX solutions. At Clearleft he refers to himself as the 'agent of the new'. He is a premier developer in the area of AJAX and designing for those types of systems. I am very happy to be talking to him today. Good day here, Jeremy. It is morning here. I am assuming it is afternoon there, assuming the sun is working properly. Jeremy: Good afternoon/morning. Jared: I thought we would talk today about what has changed in using AJAX since it first came about. Looking up things in Wikipedia there is an interesting history to AJAX. It sort of came about way back in Internet Explorer 5, right? I think that was like 1998. Jeremy: Well, it depends on how you define AJAX, you see. You start to get into semantics straightaway because if you are talking about XML HTTP request, that strange Java Script object that makes AJAX possible, then, yes, it was around since 1998-1999, whenever. It was in Internet Explorer 5, which is quite old these days. Obviously, AJAX technology didn't really take off until many years later. Even now that it has taken off and it is very prevalent, it doesn't always necessarily use this XML HTTP request object. There are other ways of doing AJAX and achieving the same effects without using that technology. To try and pinpoint where AJAX was born is kind of tricky. All you can really say is when the word was coined which would have been that article on the adaptive path website by Jesse James Garrett. Jared: Right. Jesse coined this thing. At the time he coined it to just loosely mean asynchronous Java Script and XML, but it doesn't actually mean Java Script or XML anymore. Jeremy: Right. Even Jesse himself sort of backtracked on the bacronym version of it having it actually stand for words because it is problematic, the 'X' especially, making it sound like you need it to have XMLs, very misleading. And now he himself says, "No. It is just a word. It is just a handy little label", which I think is a good way to look at it. Although I am finding now that the word is almost getting too broad in that people see any kind of nice interactive effect, any kind of Java Script on a website, and they'll say, "Oh, that's a nice piece of AJAX" even if there isn't actually any communication with the server going on. How I tend to define AJAX is that there is some form of communication with the server without refreshing the whole page. Jared: AJAX was important because what it allowed us to do is get data or put data or interact with the server without having to have the long delay of a page refresh. And allowing us to do a lot of interactive activity that felt more like the client server applications that we had in the '80s and the '90s. Things where you can get an inventory update or you can get a quick piece of information. Or you can take a movie rating and make sure it gets stored the minute the user clicks on the stars instead of them also having to press some sort of update or submit button. Jeremy: Yes, although that in itself, the ability to communicate with the server without refreshing the whole page, that was still possible even before AJAX came along, before AJAX got popularized. Again, it is comes down to how you define AJAX. When you think about Flash, for instance, Flash Movie, Flash can communicate with the server and load in another movie and another movie and another movie all without refreshing the actual page the Flash Movie is sitting in. Or to really push it to the extreme, remember frame sets? You have a frame set, and there will be different frames. You can click on the link in one frame, and it will update the content in another frame. Technically, you are not changing the whole page, right? You are not changing the URL. You are updating part of the page. You are communicating with the server. A lot of those actions, communication with the server and without this full page refresh, were previously possible before AJAX. It is just AJAX allows you to do it at a granular level. Like you said, it is something like a movie rating, something very discreet like that. I think that's where its real power comes from. It's these really small bits of interaction with the server rather than the big monolithic applications that I know a lot of people think about when they think about AJAX. They think about the big apps, like the Gmail and Google Maps. They are very impressive, but I don't think they actually get across the real power of AJAX. To me, the real power of AJAX is the small stuff. Jared: Right. Right. And the small stuff is interesting, too, because would you say that it also has an effect in that it allows the server loading to reduce a lot of the burden because you are moving these smaller chunks of data around instead of these larger pieces all the time? Jeremy: In some ways, yes but in other ways, it could be an increase on the server load. But, in my opinion that is not a problem; one, because we've got Moore's Law. Things are getting faster and better all the time. So if your server is running kind of slow, you just get a faster server. Throw a bit more money at it and in 18 months anyway it will be free or something like that. However more is always looking up. But I remember, for instance, I was talking about--I was giving you a workshop on AJAX and showing all this cool things you could do and... Because one person there was saying they actually had implemented AJAX on some kind of system where you had a table of results and you could order the results and you could sort of tunnel into them and rearrange them, all done using AJAX. So it would--you could filter, essentially; a filter by price, filter by location. Jared: Mm-hmm. Jeremy: And what they found was that people were using this a lot and they were clicking all over the place in this thing and there were lots of requests at a server all the time to get new data base results and update this content. So his answer was that he pulls the application. He pulled that bit of technology because he said it was too much of a hit on the server. Now my attitude--that would be completely different. Because to me that's exactly the kind of complaint you want. Which is--our users are finding this stuff so useful that they're using it a lot and we're having lots of bandwidth issues. Jared: Right. Jeremy: You know, I usually find complaining about your bandwidth issues is actually a pretty good complaint to have. Jared: [laughs] Jeremy: And the place to fix it is, you know, like say on the server side you throw more money at it or you get a faster, better server, or a cheaper host. I don't know; something like that. And you know, the complaint like that too many people are using my site is a very good complaint to have, I find. Jared: Right, right, right. It's what we would call a high-class problem. [laughter] Jeremy: Exactly. Jared: Yeah. You only get it when things are working well. Jeremy: Exactly. Jared: So, yeah. So, now couldn't you solve that bandwidth...? It's been a long time since I've done a lot of coding. But couldn't you solve that issue by doing more logic on the client's side? You know, storing that--big portions of that table locally so that you weren't hitting? I mean, there's optimizations you could do, right? Jeremy: Yes, yes, you could and certainly that's the temptation these days as browsers get better and more powerful. There's this temptation of offload this work that was traditionally done on the server, you know your application logic; to offload that onto the client into the browser. But I think that should be resisted because the server is one place. OK and generally you have control over that environment. You get to decide what the programming language is that you're using. And you get to decide what kind of data base you're using, generally, right? You have control over the server and it's just one server. It's not like you've got 10 different languages. Whereas the client--the browser--is a really unpredictable environment because it isn't the browser, it isn't just one browser. You don't know what kind of browsers are coming to this new site. Now, things are getting better. The landscape out for the browsers is starting to converge. And there's a good baseline of features that most browsers have these days. But still, it's an incredibly hostile development environment. Because there's so many different kinds of browsers, so many different kinds of operating systems needed for combinations. It's actually quite hard at the best of times to just make a website that works the same or works very similarly from browser to browser. And once you start offloading very important business logic into the browser, then that's a point of potential breakage that you could be avoiding, you know. If your server goes down you have control over that. You can get in there and fix it hopefully, at least it's one point of damage. But the browser is just such an unpredictable landscape. It really is quite a hostile environment. So there is this temptation to move things over to the client's sides to ease the load on the server. But I think it should be avoided. I think you actually want to keep your business logic on a server. And essentially you want a client to be a dummy client. You want it to be like this distant client that's really just reading and writing to the server. But all the fancy algorithms you're doing are happening on the server. Now, you can still make it appear as though the browser is being really smart. That's a nice thing. Someone using the browser can't tell whether it's the browser doing all the work or the server doing all the work. Jared: Right. Jeremy: As long as the experience is good. As long as the applications you know, is not being well-designed and feels good to use, that's what's important. Whether the actual processing happens as far as the user is concerned doesn't matter. So I think keep your processing logic on the server but make sure that the experience of using the browser feels rich. In a way you're kind of faking it, right? You're making it feel like the browser is this really rich application but actually all the application aspects of it are still on the server. Jared: OK, that makes sense. That makes sense. Jeremy: Yeah, I call that the deceptively rich client. Because you've got like the rich client and then the thin client, and this is the deceptively rich client; where it appears to be very smart and very clever. But actually it's faking it. All the clever stuff is happening on the server, right where you want it to happen. Jared: So, in terms of what's changed since the first you know, uses of these asynchronous prosthesis came about, what are you seeing these days that is different that we should be paying attention to? Jeremy: Well, as with any new technology and then it--there's this whole hype cycle, right, that technologies go through. People get very excited about it at start. And I think we made that--about the time that Jesse James got coined the, our--coined the term AJAX--it was right about the time that people were getting excited about the kind of stuff you could do. There were AJAX sites before there was the word AJAX. Jared: Right. Jeremy: And that Google Suggest was already out by the time that Jesse coined his phrase. Jared: Right. Google Maps was, was.. Jeremy: Yeah, yeah. And so he coined the phrase and it provided people with a really nice handle to talk about this stuff. And they certainly talked about it. It exploded in discuss, right? If you look at you know, how things got tagged on del.icio.us with AJAX from that point onwards. And just the amount of talk on mailing lists and in books, and everywhere--it go AJAX, AJA... And as with any new technology there's a tendency to overdo it, right? I mean, we went through this with Flash as well. And these days Flash has got a whole slew of best practices. And people are pretty sensible about how they use Flash these days. They use it well. And they use it to its strengths. But initially there was always that temptation to just go crazy with it, right? And got to be able to skip and choose screens and all that kind of stuff. And JavaScript went through the same thing initially as well. As soon as we had any kind of interactivity in the browser and as soon as there was the ability to mess with the browser window, people really did it, right? You know, psssh, flip the browser window around, popped up new windows, you know made all sorts of annoying things because they could. And so of course initially with AJAX people started doing things just because they could. And I have seen some implantations that just have me slapping my forehead thinking, "Why would you do that?" I've been to a website where I arrive on the first page and I navigate around the website. And the URL isn't changing at all because every single request is an AJAX request, for no good reason, right? Just because they could, they're loading everything in with AJAX and throwing away all the benefits you get from having links and bookmarks and good old-fashion sort of--and requests. So, there was definitely that danger to start that things would just get out of control. But then things started to ease off. And this is true of any technology after the lull. And you know things just sort of bed down into best practices. And I think that's happening. I hope that's happening. In that you're starting to see patterns, now, patterns of AJAX use. And they are generally pretty good patterns. There some bad patterns as well. But generally you're seeing them used where it makes sense. And again, like I said, for me it's the little things. So, to give an example, when you're signing up for some new service you have to choose a user name, and a lot of sites now provide the ability to check to see if that user name is already taken. Now, that's something that you have to call back to a server to check, right? You can't have a copy of the data base in the browser and check all possible user names. So, it does need to make a request to the server. Thanks to AJAX it can make that request without the full page refresh. So you get this nice discreet little bit of interaction where you're typing a potential user name into a form field and either automatically or by you clicking a link, it can check whether that user name is available; really small, really simple and a very common pattern. So, I'm starting to see these small bits of interaction show up in a lot places. And kind of become conventions, as well, which is a good sign. When things start to get sort of embedded into the flow as a standard sort of interactions-- that's always a good sign because conventions are generally very good things. But I have also seen just ridiculous uses of AJAX and really over-the-top uses of AJAX. Which do really remind me of what people did with Flash. When Flash first came about, they just went crazy with Flash. So, it's the same as any technology. There's sort of initial abuse and then things kind of settle down to best practices and patterns. Jared: And, so in terms of if we're thinking about developing with AJAX, are there examples that you send your clients off to, to sort of go say, "Hey, you should go look at this and see what they're doing?" Jeremy: It's generally the small stuff, as I said. So, only on that sort of micro level, only when it's sort or you know, "Oh, you know that bit of bit of action? We should do it like these guys do it over here;" right? You're like, "Or, you know when you need to rate something, give it one to five stars, we should do it like that website over there does it." Or, like I said, when you want to check a user name, we should use AJAX. It's very rare that it will actually be a core to the infrastructure of the site or core to the architecture of the site because that hasn't changed. I mean, AJAX is a great technology. AJAX can do a lot. But I don't see it as necessarily a game-changer to the fundamental sort of art and science of making a website. And I think a real trick with AJAX is to try and get the benefits of it. Try and get the benefits of those requests to the server without the full-page request, without throwing away all the benefits of good old-fashion websites. As in the benefit of having a permanent link to something, the benefit of have the ability to bookmark a page. So, you try and balance the two, I think is the key thing. You think, well, when does it make sense to do something asynchronously? And when does it make sense to have a permanent addressable URL for resource? And it's a fine line sometimes trying to decide whether something deserves to be AJAXed up or whether it actually makes more sense to keep it as a full-page refresh kind of interaction. As I said, for me generally the smaller stuff is when I go, "Oh, yeah, no-brainer. It should be AJAX." And as it gets more and more complex and bigger, I tend to back away and think actually this should just be a form submission or this should be a link followed by a new page. I have seen the opposite examples where, like I say, everything is done with AJAX and it gets kind of out of control and very monolific. And essentially you're only ever looking at one URL and everything's linked through AJAX. And it kind of makes sense for some kinds of applications, but not many. Well kind of this point you have to say is, this kind of obsession with the desktop or reproducing the desktop because that's--it's almost used just like a benchmark or something being good is, "Oh, it's a desktop-like experience." This application is so powerful, it's just like using you know a desktop version. I think, is that really such a great thing? Jared: Right. Jeremy: Because the web and websites have a lot of advantages, you know this kind of restful, addressable nature of web pages. And the humble hyperlink; the ability to link off to stuff is hugely beneficial in something that desktops generally don't have. So, there's been this whole obsession sort of around AJAX of certainly replicating desktop interactions, right? So a drag-and- drop and sort of effects that you see on desktop applications, you seem them in AJAX applications. And I kind of think that a lot of time that people are copying it without really stopping to think and ask themselves why. Or, is this really the best way to do it? Yes, it might be a familiar way because people might be familiar with that interaction from a desktop client. But do you really want to be mixing those two worlds when to my mind the online world, the web world is in most ways more powerful than the desktop, not the other way around. Jared: Right, but I think the thinking is, is that if I make it look like the desktop I reduce my training load because it's going to be something that's already familiar to the user. And what they don't realize is that because it's just fundamentally different than the way the desktop interacts, there's still this learning that users have to go through because they have to understand the sort of subtle differences that occur between-- you know, what would work on the desktop in a certain way and what actually works in a web world. And I think one of the great examples of that is the way sites have implemented webmail. There's been a big attempt to--by like Yahoo-- to make their webmail experience feel a lot like an Outlook experience. Jeremy: Correct. And they basically have to do that because initially they had some desktop-like functionality. And they tested this. It was a web-based email client with a lot of desktop-life functionality. But because they were imitating some of the desktop functionality users expected to be able to do all of the desktop functionality. So, for instance they had the ability to drag a message from you know, a list into another pane and--because you could that in the desktop client. Now, users also knew that in the desktop client they could click on one message and shift-click onto a different message further down and that should select all the messages in between, right? That's standard desktop interaction. Well, that's not the way things work in the browser, so Yahoo realized they have to actually include that. So they have to kind of fake that sort of interaction as well. And that's the fundamental problem I think with entertaining the desktop is if you're going to do it, you have to do it all or not at all. Because in a sort of half-hearted matter, it can just lead to more trouble than it's worth. Jared: Right. And once you do shift-click to do a range you then have to do option-click or alt-click.. Jeremy: Exactly. Jared: ... to be able to--or control-click, depending on your keyboard--to be able to do individual ones. And then you have to able to have double-clicked to do something different. And all of a sudden you've got this whole range of functionality that you have to support in every browser, in every way. And.. Jeremy: Yeah. And I mean desktops--or operating systems have had years and years of getting this right, right? Going back to Xerox PARC and you know, proper research into human computer interaction. And now people making websites are suddenly kind of making up the same kind of rules themselves without that background. And another example is something like drag-and-drop right on the desktop. You think it's pretty straight forward. You're like, "Oh, yeah, I pick up a file and I drag it over there and I drop it." So when people come to the I-drag-and-drop-to website, that's their thinking, "Oh, it's you drag something and you drop it; the end." And actually, it's way more complicated than that. And again, going back to Yahoo, they sort of graphed all of this to show interesting moments. All the possible points when you're beginning to drag something, when you let go of a dragable object but very close to the initial point where you started dragging it. When you drop near a droppable area; when you're moving over an area you're not allowed to drop at all. There's this huge grid of possibilities. And if you're going to replicate drag-and-drop from the desktop, you have to replicate all those possibilities. It's not enough to kind of do it in a half- hearted manner. Make it kind of like the desktop, but not really. And then, like you said there's all the keyboard support. There's all these kind of things that often get left out. Jared: Right. Jeremy: So, things end up feeling very strange, actually, instead of things feeling reassuring because they're supposed to feel just like a desktop. So, the aim is to make them reassuring for the user. What actually happens is they feel kind of weird because they feel like the desktop but not quite. It's almost like--are you familiar with the idea of the uncanny valley? Jared: No. Jeremy: OK, I'm going off on a tangent now.. Jared: [laughs] Jeremy: ... but this idea of what freaks people out--OK, when it comes to human-like, or humanoid-like things--is that if things look obviously not human, that's fine. We don't get too freaked out by them. If things look very similar to human but not quite, that's really freaky. So, there's this graft that's been plottered of this and there's this huge dip as things get close to being almost human-- that's called the uncanny valley. And so the best example of the one that gets called a lot is if you've ever saw Polar Express with Tom Hanks? Jared: Right. Jeremy: Where it's incredibly life-like but not quite life. It's just very close; it's a semi-lacquer of life. Jared: Right. Jeremy: And the end result instead of being reassuring is that it's kind of freaky. It's the same way as why people get freaked out by clowns or dolls, things like that. So I think there's a kind of uncanny valley happening in web applications that behave almost like the desktop, but not quite. And instead of being reassuring and familiar to people, they're actually just weird and uncanny. Jared: So, I think... I mean, yeah, that's absolutely true. And I think that you're absolutely right that when things are almost there, but not quite there, we have issues. And I think that a lot of things that some designers don't realize is that the behaviors that we're talking about, the shift-click to get a range or the control-click to get--to individually click multiple items--that's offered for free on the desktop by the operating system. So, the developer doesn't have to write any real extra code to take advantage of it. At most, maybe they just have to set a bit to turn that function on or off in a given table. Whereas if you're trying to duplicate a lot of these behaviors on the web, all of the sudden you don't have a toolkit, you don't have a library that does that for you in many instances. So now you have to implement that yourself. Or you have to go find such a library or such a toolkit and make sure it does it 100% and not 95% or 80% like you're saying. Jeremy: That's absolutely right. Certainly in the case of the combination of HTML, CSS and JavaScript because what they do out of the box isn't that kind of interaction. That isn't what they were designed for initially. And yes, there are toolkits online that's out there that essentially replicates those kind of functionalities and that is really useful. But I sometimes ask myself if you're building a web app that's so involved that it is actually desktop-like but you've left the idea of sort of website behind. The idea of web documents, you kind of moved on and you building something, "No, no, this is a web app that behaves just like a desktop app." Then I will question why you would even use the combination of HTML, CSS and JavaScript. Because at that stage where you're building this application, there are actually technologies, web technologies intended specifically for making applications, And Flash--and Flex in particular will be sort of the obvious one. And now there's even more around. We've got Silver Lite, we've got AIR and all these other competitors. Jared: Right. Jeremy: But the effeminate idea is the same that they are designed to provide those find of functionalities, right, the desktop-like functionality that people are apparently looking for. So, when it gets to those really complex apps where you're trying to replicate all this desktop functionality and you're trying to do it in HTML, CSS and JavaScript, I would probably take a step back and say maybe you should be using a different technology. Because for me the benefit of doing things in HTML, CSS and JavaScript is the fact that it's so durable and versatile that you can usually strip away some of those layers. That you've built it right and then you can visit with an old browser that doesn't support CSS and it wouldn't be a deal-breaker. Or you could switch off JavaScript and you'd still be able to accomplish you task. Because it's generally at the HTML level, right? You click on links and you fill in forms and all the hard work, like I said, is happening on the server. But once you get into that area of building something that's really an application and it requires that stack, then I think, well if you're going to make requirements then make life easier on yourself and maybe require something that's intended for making applications, which will be something like Flex or Air or Silver Lite, whatever. I don't have any personal experience building those kind of things or using those technologies because those aren't generally the kind of things I'm building. I'm still making websites, I think. Although those websites have a lot of interactive elements and they're getting more application-like, they're not nearly at that level of trying to replicate desktop functionality. You're trying to do the whole keyboard and clicking and option-clicking thing. And that's still a world away from the kind of stuff I'm doing and I suspect the kind of stuff of the most people are doing. I think, you know we look at these sort of flagship products that rare very powerful--the Google Maps, and the Meebo and all these incredibly rich interfaces. But they are still the exception, I think. Jared: I think you're absolutely right that we really need to think in terms of, is this technology the right technology we're implementing? Or maybe you know the question is you know, are we just stuck in this old mind-set of thinking like a desktop and do we want to just rethink the problem? Jeremy: Yeah. Unfortunately the problem generally when you say, "Oh, the idea is that you need to decide what's the technology to use." The truth is that we actually follow in their shadow a lot of the times. So if I'm used to using HTML, CSS and JavaScript, when a new product comes along my first impulse is to use HTML, CSS and JavaScript because it's what I'm used to. Whereas somebody used Flash forever and gets a new project, his first impulse is say, "OK, how can I do this in Flash?" What we really should be doing is, you know to start a project you analyze what's needed and then they guess a dispassionate decision based on the requirements of the project. The truth is that rarely happens. That generally if we go with an urge, we go with what we're used to. And so I am seeing a lot of people do stuff with AJAX with that combination of HTML, CSS and JavaScript and where perhaps other technologies would have been better. And if you take a step back, you would have seen that, and vise-versa of course, if something's built in Flash or in Silverlight or one of those other technologies where I've asked myself why wasn't that just a web page? Jared: Well that makes sense. So basically what we've said here is that we have this tool available to us, this ability to do things asynchronously. And if we sit down and think about what is the experience we want to give the user, we can leverage that tool to really do some amazing stuff. But just like any other tool, we can use it to do a lot of damage to the experience, too. And so we really need to sit down and give careful thought, careful consideration to how we're going to use the tool. And what we're going to use it for. Jeremy: Absolutely. I think that's absolutely key to remember that it is just a tool. It can be a very powerful tool. But at the end of the day, it's a tool like any other tool in your toolbox. And it certainly shouldn't be driving your process. The technology you use shouldn't be the driver behind the decisions you make. I think that's absolutely key. Jared: So maybe I shouldn't have had that whole box of now with AJAX printed up that I was going to stick on all of our websites so that.. Jeremy: Well, you'd probably get 200 percent more business. Jared: Yeah, it'll just be 183 percent better than it used to be. So you're doing a whole-day seminar. Did we just cover everything you're going to cover in the seminar? Or is there actually more stuff that you're going to get into in the six hours of this discussion at the User Interface Conference? Jeremy: Well, I'm going to get down to the nitty-gritty, actually. And I don't want to scare anybody off, but I am going to show code. Jared: [groans] Jeremy: No, really. Because there is this idea, and certainly people who make frameworks and libraries kind of put out the idea that: Oh, this is very complex stuff. And you don't actually want to know what's going on. Just trust us, and we'll do all the work for you. AJAX and sort of the narrow definition of AJAX, the XML HTTP request kind anyway, it isn't actually that hard. It isn't that complicated. And I'm pretty sure that I can go in there and in one day show people all they need to know to do at least the basic AJAX request on the World Wide Web. It isn't that difficult. So there will be code. And I think that's empowering. And then you can make the decision of course afterwards to never even use that code, and to use some library or framework and whatever you're comfortable with. But I think it really helps to know how things are working under the hood. Jared: Right. And that way when you're talking to the development team who's going to do the serious stuff, you can have a conversation with them where they don't look at you funny and say: You know we can't do that easily. Or you might even be able to say: Well actually, I saw a little piece of code that did this. Is that something you could use? Jeremy: Exactly. It's kind of getting the vocabulary, getting the understanding, getting your head around how things work. It's not that complicated. I mean it'll be a fairly full-on day. It will cover quite a lot of stuff. But I think people assume that this stuff is more complicated that it is. At least in regards to the technological side of things, it's not that complex. Now when it comes to making it work well, it's tricky. But that's not really the technology. When it comes to making it work in a usable, nice way that doesn't scare people, that can be trickier. But that isn't really down to any code. That's down to good practices with how you build your website anyway. So I think the challenges of AJAX aren't with the technology, in my opinion. The challenges with AJAX are with the design challenges. How do you make this work nicely? How do you make it work in a way that pleases users rather than scaring them? Those are where the real challenges lie. Jared: So in the workshop you're going to go through a whole bunch of examples, and show people what their options are, and what are some good uses, and what are some things to avoid? Jeremy: Yes. I mean I'll start by trying to clarify exactly what AJAX is, zero in on the XML HTTP request subject, and cover the code. Which like I say, doesn't actually take that long. It's not that complex. And then show the different options available. For instance, when you're getting data from the server, you can get that in a number of different formats. That is one of the reasons why I said that the initial acronym AJAX was misleading, because it made it sound like X (the X in AJAX for XML) was required. And that's not true. You can use XML to exchange data. But there are other options. There's this thing called JSONT. And you could just have plain old HTML coming back. So I'm going to run through those different options and show people: These are the options available to you. These are the advantages. These are the disadvantages. And let people make up their own mind about which they want to use for their own needs. I think that won't take too long to go through. And I'll show examples, the same example, but using the three different data formats. And then we get onto the sort of what I think is the important stuff, which is the design challenges, which is making it work nicely. Because the fundamental thing about AJAX that we've been talking about is this whole idea of it bypassing the built-in functionality of the browser. We talked about the URL doesn't change when you're using AJAX requests. And that can be very helpful in some ways. But it can be a real pain in other ways, right? When you lose the ability to bookmark. You lose possibly the functionality of the back button, all these kinds of challenges come up. And just generally, the design challenges in giving feedback, because normally you don't have to think about these challenges. If you build a web page, and you've got a link on that web page, when the user clicks that link, they get immediate feedback. They don't get it from your web page. They get it from the web browser, because the little "e" in Explorer will start spinning, or whatever the web browser is, it will have some kind of instantaneous feedback to say something's happening. And with AJAX, you bypass that. So you need to provide that kind of feedback. That's just one of the design challenges that people need to think about. And that's what I want to do at the workshop. I will show some solutions. But I think more than showing specific solutions, it's really important to show that the problems exist or to point out that this is where the challenges lie. And then people can think about their own solutions, think about the best way to solve that problem for their own specific situation. So essentially just making people think about the issues that come up with AJAX. Jared: OK. Well, Jeremy, I want to thank you very much. We've been talking here with Jeremy Keith who is one of the key people at Clearleft, a design firm in the south coast of England that is on top of the newest technologies. Jeremy also is teaching a seminar called "Bulletproof AJAX: Designing Interactive and Usable Solutions." He is an author of the best-selling books, "Bulletproof AJAX" and "DOM Scripting: Web Design With Java Script and the Document Object Model." He is also very famous for once killing a man in Reno just to watch him die. And we're very happy we had this chance to talk with Jeremy. And until next time, take care of yourself. We'll see you soon. Brian: Don't forget, if you'd like to hear more from Jeremy Keith, be sure to sign up for our User Interface Conference this October 2008 in Cambridge, Massachusetts. Learn more at UIconf.com, that's U-I-C-O- N-F.com. That's all for this week. Thanks for listening. Goodbye.