Like I said, AJAX is the new Flash. So here’s me messing around with loading my Bloglines roll via AJAX, using the xajax library.
Up next: caching the data, and integrating it into my profile here. I’m thinking about making a WordPress plugin, since there ain’t much of that floating around yet.
Comments OffNow 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. ;-)
1 comment »Getting there… just added the “last few comments” code, the tag cloud, comments, and other fun items.
I still need to add:
And I got around to hacking WordPress’s get_calendar(); implementation to add a summary. Yay! Tidy gives me the OK, and that means I can relax a bit.
I spent today working on the site’s new look. Why? Because daddy felt like sans-serifs, that’s why. I know the layout’s nothing original, but while I appreciate what Joseph Wain over at Niggle is doing with the layout, I’d prefer to know what to expect. As the content here kicks up a notch, I may revisit this–but right now I’m feeling the standard blog layout.
It’s XHTML 1.0 transitional and CSS 2.1 compliant. I love the hell out of web standards, and I spent about an hour running over the code which scrapes my Bloglines account, trying to figure out where the dropped <li> tag was in a forest of list elements. Still, it validates, with one minor flaw–no table summary for the calendar. WordPress runs that on its own, so I’m going to delve into its depths tomorrow and fix that oversight.
I don’t think I need to say it, but anyways–this site’s under construction and will rumble around a lot. It looks horrible in IE5.5 and lower, but renders perfectly in IE7b1, IE6, FF, and O8. Will test Mac browsers tomorrow. It’s bedtime.
Edit: Is it just me, or did the Textile plugin for Wordpress just start eating everything all of a sudden. I fed it the < character, then <, and each time it turned “<li>” into an actual <li> element. It’s on the curb now. Textile’s a nice shorthand (esp. for tables), but not if it can’t play nicely.
Comments Off