Better Tools Please

February 6, 2009

I'm kind of behind in my blogging; I promised to finish what I started in my critique of jQuery, but I was busy/lazy and am now just straight up lazy (and on vacation in San Francisco). I will get to that post, but in the mean time I wanted to mention something that occurred to me after reading an amazing article about the new buttons in Gmail and how they were made. In it, Douglas Bowman explains how he and a team of Google engineers created some controls they call custom buttons, user interface elements that, "are designed to look very similar to basic HTML input buttons. But [...] can handle multiple interactions with one basic design."

Clearly, an amazing amount of thought and time went into these and they are impressive. But, after the intial “wow” wore off, I found myself wondering why it’s so hard to make what is, after all, a simple user interface component, and make it work properly in all browsers. I’m a web developer, so the amount of work this took didn’t really surprise me, but I think it should have. It’s the old (and possibly apocryhal) boiling frog story: as the web is used to do more and more, the complexity of interfaces it must provide increase. But the tools we have to use have remained almost unchanged. We didn’t notice as things got more difficult, because it happened slowly, but one day it takes a team of really smart people a hundred hours to build a button, and you wonder: “how the hell did we end up here?”

The HTML 4 spec was published in 1997, ECMA-262 (i.e. JavaScript) was adopted the same year. The CSS 2 spec was published one year later. In other words, these things were standardized over a decade ago. And they are really showing their age. What’s worse, they still aren’t implemented properly by the browsers that a majority of people use.

The ability to build high level tools out of low level tools is one of the cornerstones of progress. Yes, all abstractions are leaky abstractions, but even leaky abstractions are useful. There’s a reason most people don’t program in assembly languages anymore. Nevertheless, there are a dozen different ways of writing the html markup for a three column layout, and people are still relying on class names to provide the semantic meaning of components that exist on 99% of web pages. <div class="footer"> is dumb. And we’ve had the same rudimentary form elements for a decade. Why isn’t there something better?

I can easily say the same thing for CSS. It’s impressive, but complicated and often unintuitive. Even in browsers that have decent CSS compliance, it can take an hours to get simple layouts working right.

Javascript is probably the frontrunner here: jQuery, Prototype, et. al. at least provide some level of abstraction, but they are ad-hoc solutions to a problem that ought to be fixed in the language itself.

The worst part is that there is really no solution to this problem on the horizon. The W3C fiddles with HTML 5 and XHTML 2 while Rome burns. By the time browser manufacturers make a hash of implementing it and phasing out HTML 4, we’ll all be flying around in hovercars or using personal jet packs. CSS 3 is faring a little better, but it’s an incremental move and I don’t see how it’s going to help us build better abstractions. Javascript, ditto.

Paradoxically, the more ubiquitous the web becomes, the slower progress moves. The kind of quantum leaps in progress we saw in the early years of the web are gone: there’s just too much at stake. Hell, Microsoft still refuses to decommission IE 6, a truly inadequate browser. The only conceivable way out of this mess may be in sidestepping the browser entirely, leaving it as a mere frame around something that does all the real work. The obvious candidates are Flash or Silverlight. Sure people said the same thing about Java, which has been something of a failure on the web, and got it’s second lease on life on the desktop and serving HTML rather than superseding it. But that was the late 90s: expectations for what the web could do were low and things weren’t as bad as they are today.

The idea of an all-Flash or all-Silverlight world makes me sad. I’ve always been a supporter of web standards, and Flash and Silverlight seem antithetical to the kind of open, accessible, democratic web we know and love. But you know what? Those same web standards are inadequate, and their sub par implementations by a generation of browsers has left me wondering if maybe the whole system is just too broken to be fixed.

Basically, I feel all kinds of mixed about this. Ask me after I’ve spent all day trying to get a button to work right, though, and I may have a a different response.

Tagged with: , , , .

Leave a comment:

Comments are closed for this entry. There are 2 comments for this post:

name:
Russell Heimlich
date:
Feb 6, 2009 10:16 a.m.
comment:
The GMail buttons are amazing. Going from good to great is all in the details and the attention to such a little detail like a button just shows you the amount of work it takes to truly make a great product. I have mixed feelings about new tools. Sure it would be great from a development perspective but what about those users that are already struggling with the paradigms of the web. People that don't know you can hit enter in a search box and that's the same thing as hitting the submit button. Or the dreaded multi select list which is practically useless because holding down a key while clicking is mind boggling for a mainstream audience. If I could get consistent cross browser CSS/JS support then I can spend more of my time building useful interactions instead of pegging down to the lowest common denominator.
name:
James Stevenson
date:
Feb 10, 2009 12:00 a.m.
comment:
I don't have any complaint about the custom button. Like I said, it's impressive. My issue is more with the process it took to create it and the process of web development in general. The effort it took to create those buttons really made it clear that HTML/CSS/JavaScript are actually fairly primitive, unreliable tools for web application building. Part of this is the poor history of standards support by browser makers and part of it is the standards themselves.