stating the obvious archives | about

Stories and Tools
Apr 15, 2002 ::

The current World Wide Web consists almost entirely of pages that are either stories or tools. A few ambitious sites combine these two types of pages in varying ratios, with results that range from unsatisfying to disastrous. But the next stage of the web is going to come from the native form that evolves from, and incorporates elements of, these two existing structures. Even after this form emerges, however, the web will still be populated with plenty of stories and tools, of course, just as television retained the idiom of an anchor at a desk authoritatively reading us the news, even after the invention of the situation comedy and the game show.

If you take a look at the pages we have today, one thing becomes clear: Stories on the web just plain work. The obvious, and so far ultimate, display of this is The Fray, which sets out in its very mission to tell stories. It's the definitive example. But less obvious examples are abundant and instructive. Every news item proffered on whatever portal or provider you prefer is presenting a story. The content presented in web interfaces to Usenet and even Wikis are largely story-oriented. In a medium originally designed to present structured documents, the natural divisions and regular formatting of stories was destined to be a good fit, even if they technically fell outside the precise realm envisioned by the webís creator.

This brings us to the other kind of web page, the kind that just plain doesn't fit into how the web was envisioned: tools. Web pages that aren't stories are tools that you use to perform a task. You've probably seen these. Amazon is one. Your bank's online payment system is another. You probably use a web email tool like Hotmail. This siteís been using Blogger for a few years now. Hell, Yahoo, MSN, Netscape, and most other common start pages are more tools than story already. And none of them work right.

Thatís not surprising; they're not supposed to.

Think of Hotmail. It's designed to give you a place to write emails, read them, and move them into folders. These kinds of functions in a desktop operating system are automatic: you just drag and drop. But to enable that kind of simple action in a web page, programmers have to jump through hoops, trying to make a story act like a tool.

And notice who has to do that? Programmers. But HTML isn't a programming language. It's designed to be written by authors, not programmers. There are tags to describe the parts of a structured story. There's in fact a formal Document Type Description for hierarchically structured documents -- XHTML. Curiously absent, unfortunately, is a description for a Web Tool Document.

Look at Oddpost, as itís been making the rounds lately. It solves most of the problem. Itís beautiful, useful, powerful. And, much to the chagrin of Mac partisans and Unix enthusiasts, it only works on recent Microsoft browsers on Windows. Thatís not the bad part about Oddpost, though, thatís just smart use of limited development resources. Whatís truly bad is that Oddpostís HTML doesn't make any sense outside of a very limited context, and itís incredibly hard to debug or reuse or make useful on a PDA or a non-standard web platform.

It's this opening that Flash MX has stepped into. With a cry of anguish from standards and open-source advocates, and amidst shouts of glee from newly-empowered Flash developers, Macromedia recognized the enormous opportunity to make tools easy to build. And if it just so happens that most of the money in the web development business comes from helping businesses build tools, not from helping businesses tell stories, well thatís just plain old good luck for Macromedia. And it was an inevitable opportunity because the web was always, and only, designed to be stories. All else is kludge.

A Way Out?

What was needed was a formal DTD for describing elements of a web-based application. Common GUI widgets like a tree control, a select or combo list, a spinner control, some drop-down menu controls, toolbar buttons, scrollbars, and all the other usual trappings of a modern GUI application. And some basic logic for loops and form processing. This Application Markup Language would just be a specific XML implementation, with the unique part being that all of the controls would be rendered as GUI-native, state-aware real widgets. But these HTML applications would still have all the benefits of web applications, as benefits like CSS styling, device-neutral rendering, and simple data sourcing would be preserved.

Thus was born AppML. Itís beautiful, really. But nobodyís using it. And it requires server-side logic to execute. And it only exists in theory; I couldn't build Oddpost with it in any reasonable amount of time or under any reasonable budget.

Does that mean we have to give up? The choice is poor web-based apps or an extension of Microsoftís hegemony? (For the record, I don't think that ideaís nearly as evil as an extension of the tyranny of desktop applications and humongous computer form factors.) Well, no. I think thereís a third way.

A widely-distributed, standards-compliant, browser and platform-independent library of functions that would perform the basic user interface functions for a web-based tool, relying on the server side only for the logic and data sourcing. Well, whaddya know -- we've got one in DomAPI. It's still a work in progress, and it doesn't support nearly enough platforms yet. But DOMAPI is spectacular already. And it'll evolve, and it'll be good enough a year from now to be the basis of a large, stable array of applications, guaranteeing its future development and viability.

So what does all this mean? It means that we finally something that works for the two main uses of today's web. We can stop fretting and take these two essential pillars of the future web for granted. Stories we've got beat. Applications we've got a little distance to travel yet. But now... now, we're ready to figure out what the web will actually be used for.



Other pieces about client-side software: