Imagine if you will that you are a very unlucky producer on opening night. Your company has worked for many months—no, years—on a new show, an ambitious production full of brilliant dialogue, beautiful designs, and innovative effects. Your adrenaline is pumping, and you’re fully prepared for an enthusiastic reception. But the stars are just not aligned for your launch tonight.

First, the crew decides to go on strike at the last minute, making outrageous demands that you can’t possibly meet at this hour, any more than you could find replacements at this hour. It’s showtime, and there’s no one running around backstage in black.

But the show must go on! It won’t be the same without those endlessly-rehearsed lighting and sound effects, but people are starting to show up. It’s too late for rain checks. That’s okay! You still have some great entertainment.

You must have really upset the theater gods, though, because the entire set, you learn, has collapsed—into the wardrobe. Don’t ask me how. So now you have none of the artwork or costumes that cost the designers so much grief—and you so much money.

But the show must go on!

Fortunately, you still have what you need the most: the actors. The show really cannot go on without them—but it does go on, and it’s fantastic. With no distractions, the audience is rapt from start to finish. Critics praise your production for its bold minimalism and palpable sense of urgency, which reminds us what we love about live drama in the first place.

Of course, you’re better prepared next time, and no one complains about those production “frills” when they’re back.

What is this about?

It’s about the web, and something that’s been variously called “progressive enhancement” and “graceful degradation.” Either term will do.

A browser is a venue.

The web “platform,” as we’ve known it for a while now, is a three-layer stack.

This is true for any web site that tries to honor the notion of “progressive enhancement,” if there are any left.

IN this analogy, CSS is like costume and set design.

• 
• 

And scripts are like the crew, who can provide special effects and set changes. The people in black who do things “behind the scenes,” or at least who do things that you usually aren’t supposed to see directly.

(the “script” is the “dialogue, lyrics, and stage directions of a musical or play,” according to the OSA vocab)

HTML is the … um, script. Unfortunately, this term is overloaded. So the obvious analogy—to the “scripts” that represent the essence of the show—is completely backwards here. Willshake is supposed to work without any scripts at all, so they cannot be the essence. But they can add value.

In willshake, scripts are like production value. The “production value” of a show is the value added by the technical production. It’s a bit of extra production—a production enhancement—that can be used where the venue permits.

But what exactly is “production”? I would define “production” as anything that cannot be done by the actors alone. So yeah, a show with no production value would be pretty disappointing to some.

The “web stack” comprises three main languages: HTML, CSS, and Javascript. HTML was the first of these; the others were developed as enhancements to it.

This is an additive model. You can take away the script (in theory) and still have something good. Likewise, you can take away the stylesheets and still have something intelligible, usable. If the web is really a broken wheel (as some would argue), perhaps it serves as a warning against additive systems. Regardless, the additive design is intentional.

The final component in this analogy is the venue.

platform (n.) 1540s, “plan of action, scheme, design,” from Middle French plateforme, platte fourme, literally “flat form,” from Old French plat “flat” (see plateau (n.)) + forme “form” (see form (n.)).

http://etymonline.com/index.php?term=platform

A platform is a way of reaching an audience—a larger audience than you might otherwise. In theatrical use, platforms function as a natural amplifier, enlarging the audience that can be served.

Shakespeare’s company performed on a platform stage. Even ad-hoc countryside venues were performed on elevated stages, erected temporarily for the duration of the company’s visit. That’s how most people see plays: in a purpose-built venue.

Using a platform is an eminently practical consideration, especially at a time when platforms have global reach. I don’t expect any of today’s platforms to have Shakespearean-longevity. But of the ones we have, I expect “the web” to last the longest.((footnote “Time,” the talk that I saw recently.)) Anyway, how long it lasts is really immaterial to the question of which platform right now has the greatest reach.

This reach, I should add, is not limited to its extent, but also to its quality and variety. The web platform, (when used humanely) has built-in (first-class) support for assistive technologies, such as those used for the visually or hearing impaired. ((Don Norman on how such things have general benefits.)) This would be akin to a theatre that provided, e.g. sign language translation as a service. This is part of the deal that you make with the platform (i.e. venue) provider: They provide an audience and a set of services (sometimes in the form of infrastructure and equipment) and you (working within their constraints) provide a reason to go there. a.k.a. “content”.

These constraints and services make up the technical side of theater productions (or “applications”), or, in the case of the web, “web sites.” The web platform is structured in such a way that, I will argue, maps pretty well to the main aspects of theatrical production. I’m assiming those concepts are more familiar to most people than the making of web sites. Even though most people reading this probably spend more time on the web than in a theater, the relative age of live drama versus the web means that most people have some exposure, even if indirect, to the kind of things that go on “behind the scenes.”

The design of the web is intimately died up with its mission to be a universally accessible platform. To this end, it tries to be as agnostic as possible about both the user and the “user agent,” that is, the person and the machine in volved. In both cases, it’s a question of capabilities—and assuming as little as possible about the person’s or the browser’s abilities to do any given thing.

So far, I’ve taken for granted that the web is as good as its extraordinary success might suggest. In this section, I will not take that for granted. On the contrary, I find at least one criticism of the web so distressingly compelling that it has made me question any further investment of my time in it.

Again, the web is all about accessibility. How can I say that the web is “all about” anything, when it’s become so many things to so many people? What I mean is that, whatever its shortcomings—and whatever its future—the lesson of the web’s success is a lesson about the power of connecting the most people with the most resources, which I’m putting under the heading of “accessibility.” Accessibility is the one part of the web’s original motivation that remains a core principle today. Whatever strengthens accessibility on the web, strengthens its long-term prospects; and whatever threatens accessibility, weakens it.

Yes, the web is a broken wheel. But if you’re going to use it, don’t try to pretend that it’s something it’s not. If you really don’t like it, by all means, create something else. And if you can make it better, great. But frankly, I think the vector for making the web better is its whole problem. It keeps bettering and bettering. And the better it gets, the worse it is. I mean, that’s not quite 100% true, and maybe the web can incrementally turn into something more like a computing platform. But the point is, it is what it is.

The zen of the web—or any technology—is being at peace with what it is, and mastering what it does well. If you’re trying to make something work, and it’s not working, and it feels very against the grain and you’re fighting the system, you probably need to back up and consider how you can abandon that approach.

And there’s something odd here. Part of this is about using something the way it was intended. Yet the whole point in “the story of the web” is that the parts of the web that have an intended use are the most ill-conceived. Nevertheless, they are the ones that give you the most leverage. When you are at harmony with those things, you can do a lot with little energy.

This document is about the web platform, so “prior art” means prior attempts at a hypermedia systems. I have not researched this subject specifically, but from what I’ve read, a few precedents come to mind.

The memex

The “memex” was a notional machine put forth by Vannevar Bush in 1945. The hypothetical system sounds a lot like the web that we have now, except that it was based on a kind of microfilm projector stored in a desk, and, more importantly, that the exploration of its cross-linked topics would leave “trails,” a kind of associative residue that later explorers could follow. Although in many ways today’s web makes the memex sound positively quixotic, there is yet no equivalent of these persistent trails—except as they are retained by spy agencies.

Doug Englebart’s NLS (oN-Line System)

Englebart had his “this is it” moment after reading Bush’s essay, and dedicated the rest of his life to the use of computers for augmenting human intellect. It sounds like the 1969 “Mother of all Demos” was really the high-water mark for Englebart’s impact on the future of interactive computing. His systems never made it out of his research labs, except as influences on other technologists, including several researchers at Xerox PARC. But that influence included a deeply-embedded belief in the formal structuring of documents and the addressability of their contents—two ideas that are essential to hypertext.

HyperCard

HyperCard was a Mac application—or you might say platform—for authoring interactive documents, called “cards.” Like the web, it enabled non-expert users to create complex interactive content. But although it did have hyperlinks, they were “local” to the set of cards containing them. So it was a “web,” but would never become “world wide” as such.

Some good discussion (as usual) on Hacker News about the relationship between complexity and success, vis-à-vis the web. I didn’t even bother to mention Xanadu among the prior art because it’s… well, the OP says it best: #+BEGIN_QUOTE Yet despite the fact that the forty year old Project Xanadu is a more compelling vision than were we are today it failed and Tim Berners-Lee’s World Wide Web succeeded. In practical terms, Project Xanadu was trying to solve too many complex problems in a v1 product. In contrast, Tim Berners-Lee focused on the most valuable problems to solve for end users which was sharing documents and media with anyone on the Internet and punted on a bunch of the hard problems that would require a more controlled and tightly coupled network as well as a ton of more code. Tim Berners-Lee solved less than half the problems Project Xanadu set out to solve but has changed the world immeasurably for billions of people by providing simple solutions to complex problems and running away from trying to create complex solutions to complex problems. #+END_QUOTE

Dare Obasanjo, “Duct Tape Programmers and the Culture of Complexity in Software Projects”, September 27, 2009.