The Tyranny of CSS And Ajax, A Timex Watch And A Barrel Full of Rocks
January 24th, 2008A beep; a pause. Another beep; another pause. Third beep; third pause. Eleven beeps in quick succession. Listening to the kid in the row in front of me reset his Timex following our flight one time-zone westward helped me understand why building web apps has been so so little fun recently.
Two buttons provide enough of an input mechanism to set a $10 drug-store watch. Hold down one button, wait for the LCD numerals to start flashing (or, fancy-schmancy, listen for a beep) and plug away at the other button until you’ve cycled forward to the right value. Hold down that first button down if you want a different column of numbers.
By any measure, that’s a crummy UI. Thing is, it’s good enough. It’s good enough for the bottom-of-the-line digital. Moving up-market the UI gets even worse: my REI bought analog watch uses a single rotating stem to set six hands on spread over 4 dials. That’s an arguably worse UI still. But again, it’s good enough.
Sometime in the recent past we traded in “good enough” web UIs for UIs measured against desktop applications. Google is widely credited with ushering in this era. They showed us that it was, indeed, possible to build beautifully interactive web applications using JavaScript to manipulate the DOM. While we were at it, we traded in the limitations of tables and simple HTML for the granularity and rigor of CSS.
Working with CSS and the DOM is aggravating. Plenty of reasons for that [1], most defendable is probably the inconsistencies between browsers. Naturally you can overcome most of these things by exerting effort. That’s effort spent working on something that is, in all likelihood, ancillary to the purpose of your application.
I suggest we take back “good enough” and justify it by applying Barrel of Rocks metaphor of market segmentation.
Sink uses a barrel to represent the total market for installed software. The barrel gets filled with stones whose size represents the size of the market-opportunity. Operating systems and office-applications are boulders; there’s only room for a few of each. Here, a glance, the barrel is full. But, of course, there’s lots of space between the boulders. This space is can be filled with rocks, and the space between rock with pebbles and so on.
With the barrel representing the total market for web applications everything becomes clear: Google, whose applications set the broad market standard for installed-application-like UIs, is a boulder. They want people to switch from installed software to their broad market web applications, so they need these fine interfaces and their market opportunity justifies the time/cost/complexity.
Are you building a boulder, a rock or a pebble? You’re not very likely to be directly competing with Google, nor is your application likely to be a installed-to-online switchover application, so good enough ought to be good enough.
Start simple and carefully add your application-like features later. Focus on features that offer substantive depth (e.g., keyboard shortcuts) over flashy eye-candy to promote power users of your app — see Kathy Sierra’s Engaging Users essay for inspiration.
[1] For a more technical slant on this, you might like Neil Mix’s Beyond Dom article.
February 4th, 2008 at 12:09 pm
I can certainly sympathize with you here. The modern web development landscape is complex and opaque due to its relative youth.
I think the metaphor you highlight of an “application” experience is useful. I generally think that sites need to have a _context_ and that sets the tone of the experience. Publication. Application. Widget. These establish context.
From there the most simplistic tools that still provide elegance are necessary. And elegance can demand a lot of complexity. :-)
April 1st, 2008 at 11:11 pm
I’ve been thinking a lot about this issue. At GovDelivery, our objective is to “do as much good as possible for our clients and the public they serve” with the resources we have available.
I like how you talk about features at the end of your analogy because for us, it’s not just about our market, it’s also about the features within our app and their relative importance. I’m sometimes embarrassed when a little used piece of functionality in our application is “good enough,” but I simply explain to our clients that we chose to invest in feature X (which they really wanted) over making feature Y (which hardly anyone uses) more useful. We’re lucky that our clients trust us and respect our judgment on these issues, but it’s still hard to just accept that certain parts of the app are always going to be “good enough” and move on.