AJAX is the new Flash
Now AJAX, or as we called it back in the day “DHTML,” is the hot new thing these days. People are naming their babies after it, getting tattoos, and making other unwise decisions. When you have a hammer, everything looks like a nail.
Take (please), for example, the recent spate of “live searches” plugins available for blogging software. They replace the usual “type-type-click” style search widget with one that provides instant results the minute you start typing. “What’s wrong with this?” you ask. “It’s just like Spotlight, and I will gut you like a fish if you don’t like Spotlight!” Spotlight’s awesome–deep breath–but if you look closely you can see a slight difference between someone’s blog live search and Spotlight.
See it yet?
One’s a program designed to search through files on your computer, and the other’s a tiny box on someone’s blog. Spotlight’s interface is designed (fairly well, I think) to display results. The little typie widget up top is the only thing not dedicated to showing results. Now look at a blog–like mine. What’s the purpose of this page? Content. And it’s not the result of a user’s search, either–it’s a series of article, sorted by reverse date, etc. etc. etc.
Spotlight is cool, but the reason why it’s effective is because it has an interface designed to further along the user’s task: searching. A blog is a bit different, and so the front page of someone’s blog is a horrible place for a live search widget. Take a look at Google: they do have an experimental widget which has live search-esque qualities: Google Suggest. It uses the same main page interface as vanilla Google, but displays a list of previous searches, along with how many results those would produce. That’s well done, as it provides a certain amount of interactivity about potential searches the user is typing it, but doesn’t make the searching interface a spasmodic, twitching mass of content which only boils down into something coherent once the user stops typing.
Which is another point about live searching: how fast does a user type? How many miliseconds between keystrokes? This is something that’s so radically variable between users that setting it to some kind of global constant seems only fair: that way it’s half-broken for everyone. If I’m looking for a keyword, how fast I type it in depends on the word: if I’m typing in “procedure,” then my years of Object Pascal training kick in, and I belt it out in a few miliseconds. If I’m looking for something different–say, Nahwah–er–Nague–damn–Nagual–crap–Nahuatl, then the live search function gets to thrash around while I puzzle over how to spell a foreign word. In comparison, Google Suggest lets me see what keyword I’m looking for three letters in, completes the term for me, and with a swift kick to the enter key, I’m on my way to telling someone their tonacayotl is achichichic. Now that’s usable.
In short, choose the widget for what the widget will be used for, not based on how much fun you’ll have implementing it.
And on a side note, I’ll be replacing my Bloglines list on the sidebar with something a bit more dynamic later on. That’ll be fun to implement. ;-)
September 21st, 2005 at 4:47pm
[...] It’s exactly what I was talking about. Only really, really clunky. Really clunky. [...]