The Page is Dead, Part 1

Friday, November 7th, 2008

We are no longer bound by the page refresh model. With this change, new user interaction idioms have surfaced on the web.

– Bill Scott, Director of UI Engineering, Netflix

“The page is dead. Long live the page!”

Over 4 years ago, Karl and I were brainstorming a piece of software what would eventually come to be called “Morpheus” (more on this later). We had locked ourselves away for a week inside a small windowless room at Community Connect Inc. where we were both employed at the time, with only a whiteboard and some paper and our ideas. CCI was embarking on a gigantic structural overhaul of their back-end and front-end architecture at the time, which would affect millions of users across three different community sites. As the information architect and lead front-end developer, we were faced with the task of re-imagining every single interaction and functionality and somehow representing these changes visually. That is, we had to make a crapload of wireframes.

“What? You want wireframes for every single page?!? Are you kidding me?”

Any IA who has faced this knows it is a sisyphean task. “Oh, you forgot the state when a user is logged in but has no friends so they don’t have access to this widget on that section.”

This problem runs many layers deep. The Business Customer knows (very generally) what he wants the application to do; he just can’t paint the picture accurately enough but, like pornography, he knows it when he sees it. That’s where the Information Architect comes in (I use the term more as a role than a job description since in reality most IAs wear many hats). The IA is responsible for translating these nebulous “business requirements” into visual blueprints which are then consumed by a whole host of people:

• Visual Designers, whose job is to put the flesh and makeup on the bones
• Front-End Developers (FEDs), who translate the wireframes into structural, semantic HTML first, then, after the Visual Designers are done skinning, slice and dice the PSDs or Illustrator files, translating the design into working web pages with CSS
• Back-End Developers (or Developers or Engineers or Programmers), who use the wireframes to determine how the databases that serve the content get structured, and what functionality needs to be coded to extract every element of data in order to populate every page
• The Business folks (including Sales) who use the wireframes to present their product idea to their board or to investors to get funding, and to sell the idea to potential customers
• Usability (User Experience Experts, Interaction Designers) who use the wireframes to actually test the screens and interactions with actual users to see if they make sense

Faced with the prospect of modeling every single state of every single “page” in a community website that had a panoply of features ranging from chat, personal pages, notes, news articles, not to mention all of the administrative pages that needed wireframing, Karl and I were convinced we needed to approach this problem in a different way. We had to come to terms with the fact that the “page” was no longer what it used to be.

To be continued…

Tweet This Post