The Problem With Pages

Some days I ask myself "what happened to computer science" Okay, a lot of things, but I'm going to pick on one.

The web was partly successful by using a simple overarching paradigm, of the "page." Not dissimilar from some other simple systems; Hypercard put everything on cards, and I recall that being both overly-strict and pretty convenient to making thing simple.

So the web used pages. Great. Simple. But in the meantime, it's made everyone lazy. Even now that we have wildly interactive capabilities, all webapps are still made as pages. It takes an inordinate amount of my time to explain that this next view of the system is automatically updated, or that the new element slides in or, anything interactive.

States no longer really exist... it's all pages.

It even extends to efficiency of code, where basically no one considered the entire system, and what components are shared between pages. No, you give a developer a wireframe, functional spec or comp, it addresses the page, he builds the page. All the while the guy next to him builds a nearly-identical page, and they never share any components or even talk about it.

Lately, I am noticing this more and more, and realizing how deeply rooted this is as a problem. I have to write overly-long specification documents, to depict every single state, and then argue about how "No Favorites" is not a page with a redirect, but a state of the "Favorites" page, dynamically loaded. Because, it's not even for a website always. This is a mobile app. And the same happens for a desktop application. Or even trying to get someone to send email; I keep getting developers who want to load a page to send email, when it's just a simple service call.

If it's not "a page," the feature might not get built at all.

This week, it's bugging me as extends to 100% of the simple prototyping tools I have tried to use. There is no real support for accordions, popups, sliding things... or generally changing a page. Not just the cheats, like using PPT or Keynote, but several dedicated prototype tools. They remind me again of Hypercard development tools, or the web in 1995. Except that still had alertboxes, didn't it?

From tools to feature creation to building final code, everyone expects a page, which has nothing to do with other pages, and when anything changes, we replace it with another page. Forget separating software from markup from style, it seems now there often cannot be software without a presentation page to attach it to.

This is stupid, because it's how anything good really works, and certainly not how EVERYTHING works. Everyone designing and building like this is drawing in Fireworks, or Keynote, and coding in Eclipse, or WordPad. Which is to say, something fairly modeless, with controls of all sorts hanging around, that can be switched to willy-nilly. How it can be that everyone wants to take the best ideas from their favorite digital experiences (e.g. we must gamify everything), but miss the core philosophy of their day-to-day work tools, I will never understand.

A lot of my work is terrible or boring when it launches because I cannot break everyone out of this mindset, so build long, complex specifications to build large, overly-complex and bulky products because, when you get right down to it, interactivity baffles implementation teams.

A lot of digital products are buggy, and it takes forever to fix them because the test process involves looking at pages. If they seem okay, they must be. What happened to debug panels, or even error codes?

What next? Do we need a manifesto? A conference series? An ad campaign?

"The first step is admitting you have a problem with pages."