Touring Mechanic

Last week’s main project was switching tab libraries.

The first client-side feature I ever added to Touring Machine was tabs. On the list/search page, each venue is shown as a business-card-sized block, with separate tabs for basic info, a map of the venue, and (if you’re logged in) an edit form:

Most Ruby on Rails apps use Prototype and Script.aculo.us as a client-side library, with good reason: They’re bundled with the main Rails distribution, and Rails provides template helpers that let you use them without having to write JavaScript code. They’re what Rails does best: an easy way to get something cool up and running quickly.

I’m stupid, though: I have to believe in the tools I’m using. I looked at Prototype and didn’t see clean design; I looked at Script.aculo.us and saw a bunch of hacks. Not only that, but neither one was documented, to speak of; mostly you had to go read the code to find out what you could do. Perhaps more importantly, neither one had tabs built in, and I couldn’t find a good implementation I could steal from elsewhere.

So I decided to implement my tabs using the Yahoo! User Interface library. It had extensive documentation! And when I read the documentation, I got a feel for a unifying design philosophy behind the individual classes and methods! And it had tabs built in! What’s more, it had built-in support for tabs that were loaded only when displayed. This was important: Given a page with ten search results, I didn’t want to load ten maps when the user might not care to see any of them.

Two of my reasons for choosing YUI have faded. First, I now think it would be better to present all search results on a single map, instead of individual maps on each card. Second, I was planning to use Yahoo! Maps (Google didn’t do geocoding), and I figured it’d be safe to use a library from Yahoo! that would probably interoperate nicely with their map service. Ironically, Yahoo! Maps and YUI turned out to be incompatible (albeit solubly).

I became dissatisfied with YUI for other reasons: Mostly, it’s big. It’s got every feature I wanted… plus some I didn’t. To a certain extent, you can pick and choose the sections you want to use (and make the user download), but it still feels like a big library, designed for big applications; I’m just doing little things! I still like YUI’s design and documentation, and would enjoy using it on a bigger project, but I started feeling like it wasn’t right for Touring Machine. (Also, this bug is annoying.)

I wasn’t ready for Prototype, though–based on my hazy memory of not liking the design. I looked at Dojo, which I remembered having good design feelings about… but then I read this post, which explains that you shouldn’t use the old widgets because they’re not being maintained, but the new widgets aren’t ready for release yet. Maybe best leave that one alone for now. And I looked at Ext, which started out as a YUI extension but is now available for YUI, Prototype, or jQuery. Pretty cool, and I got a rough implementation working… but Ext insists on creating its own DOM objects for the actual tabs, which means I couldn’t write markup that would double as JavaScript tabs and HTML links. More about that in a future post.

Somewhere in here I can across Control.Tabs. Ryan Johnson wrote a tiny library on top of Prototype that attaches tab behavior to existing markup. It’s convenient, it’s comprehensible, and it works… for what it does.

What it does is tab behavior. You click on one thing, another thing becomes visible. It doesn’t give you a tab “look”–so now I know more about how to implement that in CSS, with some cribbing from YUI (-moz-inline-stack?!). And it doesn’t do dynamic loading… so I had to do it myself. Using Prototype.

And you know what? It was pretty fun. I’ll write more about the details in that future post I mentioned, but for now I’ll just say that Prototype’s documentation has come a long way.

There are a couple of things I’m still missing. Control.Tabs operates on the principle that a tab is a link to an anchor within the current page–specifically, to the DIV that should be displayed for the given tab. But this breaks my old graceful degradation, where, with JavaScript turned off, the inactive tabs served as links to a new page that would show you the tab you wanted. There’s not enough bandwidth in a single A tag to communicate both the internal tab location and the external surrogate.

And, as it turns out, my users are still loading YUI–because the Yahoo Map API needs it. Maybe in the future I’ll make YUI load-on-demand. (Also, I’m still using YUI’s reset-fonts-grids package, which is pure CSS, lightweight, and really handy. I have no plans to stop using it.)

This entry was posted on Tuesday, April 24th, 2007 at 5:47 pm and is filed under javascript, yui, css, tabs, prototype, ext, dojo, accessibility, control.tabs. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.