Jeremy Keith Interview

Jeremy Keith Interview

Got something to say?

Share your comments on this topic with other web professionals

In: Interviews

By Carolyn Wood

Published on February 26, 2007

Digital Web: Your new book is titled Bulletproof Ajax. For those readers who haven’t been following the hoopla, what is a simple definition of AJAX, and where have you seen AJAX used appropriately?

Jeremy Keith: The simplest definition of AJAX that I can think of is, “updating part of a web page with information from a web server, without refreshing the whole page.” It’s not a very sexy definition, but I think it’s fairly accurate.

Mind you, by that definition, frames would be a kind of AJAX, which is a bit of a stretch. Usually when people discuss AJAX, they’re talking about the XMLHttpRequest object. The word AJAX not only sounds cooler than XMLHttpRequest, it’s also a lot easier to say ten times fast.

As for good examples of AJAX, I personally like the little things: checking whether or not a username is available, rating a product on a scale of one to five — stuff like that. Most people think of AJAX as something for big applications like GMail and Google Maps. Those are great web apps, but AJAX is just as useful for enhancing more modest web sites.

DW: Who did you have in mind when you wrote Bulletproof Ajax? Is it best if the reader has some background in JavaScript?

JK: Bulletproof Ajax is aimed squarely at front-end developers and designers—the kind of people who are already well-versed in web standards such as CSS and markup. A rudimentary knowledge of JavaScript would be useful. If you’ve read my first book, DOM Scripting, then you’ve probably got enough JavaScript to get started with this book. I’ve included a quick JavaScript refresher to get everyone up to speed.

DW: Does the book contain how-tos, and, if so, what will the reader learn to actually do?

JK: The book has plenty of how-tos, but it’s not a cookbook of code. By that I mean that it’s not a book to be dipped into. It has more of a narrative feel, getting progressively more involved as it goes along. The how-tos are there to illustrate concepts that are introduced in each chapter; they aren’t there to be cut and pasted out of context.

So while there is no shortage of code samples, they exist purely to drive home the ideas. Give someone a fish and they’ll think you’re a bit of weirdo; teach someone how to fish and they’ll wonder what fishing has got to do with web design.

DW: What do you hope the reader will understand after finishing the book?

JK: I hope that the reader will understand all the implications of AJAX. Adding AJAX to a web site introduces some unique design challenges. At the same time, I hope that the reader will appreciate that the code required to get AJAX up and running isn’t that difficult. I think a lot of people assume that AJAX is something very complicated that should only be attempted by really smart boffins, or rocket surgerists, as Derek Featherstone might put it.

DW: Will this book be useful for someone who already has a good understanding of JavaScript?

JK: I think so, yes. JavaScript is just one part of AJAX. The underlying markup is equally—if not more—important. The JavaScript code in the book might be a bit simplistic for someone who’s already a whiz at JavaScript, but the concepts should still be illuminating.

DW: What are some of the mistakes you see when people use AJAX?

JK: By far the most common mistake is when AJAX is used as a requirement rather than an enhancement. I think AJAX is a wonderful technology, but no technology should be used as a barrier to content. With a little bit of forethought, you can have your cake and eat it. It’s entirely possible to add AJAX in such a way that AJAX-capable browsers get a lovely smooth experience, and non-AJAX browsers still get access to your content.

There are other common AJAX mistakes, like not providing the visitor with instant feedback and re-assurance, but these pale in comparison to the larger issue of making sure that AJAX isn’t a barrier to entry.

DW: Are there any risks in using AJAX if you don’t really know what you are doing, as there are sometimes with, say, PHP?

JK: I think there are risks with using any technology. What varies is the amount of damage that can be done if you don’t know what you’re doing. The worst you can do if you don’t understand CSS is make something ugly or boring looking. With JavaScript in general, and AJAX in particular, the risks are greater. If you don’t know what you’re doing, you could break the fundamental models of interaction on the web by making hyperlinks or forms that just don’t work.

You need to know what you’re doing if you’re going to use AJAX. In some ways, that’s an elitist attitude. But then, is it elitist to insist that you need to pass a test in order to drive a car?

DW: Are there times when AJAX shouldn’t be used, and Flash, perhaps, should be used instead? Do you talk at all about when not to use AJAX?

JK: I certainly don’t think that AJAX is the right solution for every problem. The danger is that when all you have is a hammer, everything looks like a nail. That’s a danger with any technology, but it’s particularly a problem with AJAX because of its cool cachet: Sometimes people dive in and start using it without really considering whether or not it’s really necessary.

AJAX is used for a wide range of web sites, from document-based pages right up to fully-blown web applications. In my opinion, AJAX gets trickier and more unwieldy to use towards the application end of that scale. In those situations, you’re probably better off using technologies such as Flash and Flex to build web apps with a great deal of complexity. Partly, this makes the developer’s life easier, but also, because the Flash player is more closely tied to the operating system, there are potentially more accessibility benefits.

DW: Do you cover AJAX’s accessibility issues at all?

JK: Oh, yes. There’s an entire chapter in Bulletproof Ajax dedicated to screen readers and AJAX. It’s mostly me pointing to the great work being done by people like James Edwards, Gez Lemon, and Derek Featherstone.

To be honest, that chapter makes for some grim reading. but that’s because the current situation with screen readers and AJAX is pretty grim. In my opinion, it’s the biggest stumbling block in AJAX’s path, and the number one reason why you should think long and hard before deciding to use AJAX.

DW: Those of us who follow your blog know that you’re always ready for a new adventure� whether it’s travel, learning a new skill, or looking at something in a whole new way. What’s on your list to investigate next?

JK: Well, there’s plenty of travel on the horizon. I love public speaking. It’s a lot easier for me than writing, which I actually find very tough. So I really like going to conferences and events around the globe, spreading the good word about DOM Scripting, AJAX, microformats, or whatever else I’m currently passionate about.

I use these excursions as an excuse to not learn a new skill. I was just in Vancouver for Web Directions North and at the post-conference gathering in Whistler, I added snowboarding to the list of things I can’t do. That list includes things like skiing, swimming, driving, and regular expressions. I’m sure the list will grow even longer by the end of the year. I fully expect to not learn Ruby on Rails sometime.

Got something to say?

Share your comments  with other professionals (7 comments)

Related Topics: XHTML, Scripting, DOM, CSS

Jeremy Keith is a web developer living and working in Brighton, England. He enjoys playing the bouzouki and writing about himself in the third person.

Carolyn Wood of pixelingo is a web designer, copywriter, content strategist, and the Editor in Chief of Digital Web Magazine. Her long list of loves includes the web, design, storytelling, and making lists. If you meet her, ask her to tell you the story about the midwife and the bank robber.