Archive for the ‘information architecture’ Category

The Page is Dead, Part 2

Sunday, November 9th, 2008

(This is a continuation of Part 1 of “The Page is Dead”.)

What is a “page”?

We haven’t had to think about this question for the past three hundred years or so because it’s so obvious to everyone what a page is. We’ve just been staring at them so long we take them for granted.

It’s a sheet of paper.
OK, it’s a sheet of paper that has words and pictures on it.
A book or a magazine has a bunch of them bound together.

Simple, right?

Jack Kerouacs manuscript for On The Road, as a scroll

Wrong. Take a look at Jack Kerouac’s manuscript for On The Road (at left). Is this just one long page?

Well, if you want to get technical, you might say, then, that a page is an arbitrary unit of displayed information. The “page” is, in actuality, a convenience that has been established for you, the reader. Really, it’s a design artifact of the codex, which made its debut in the first century at a time when the scroll was the dominant format for knowledge. Actually, long scrolls were made up of “pages”, ie, individual sheets of paper or whatever material that was used, stitched together, but to my knowledge, there was no definite way of referring to specific pages by number until the bound book came along and replaced the scroll.

Guess what, dear readers? The scroll is back.

That’s right. You’ve probably scrolled (unconsciously) a few times already just to read this. First you fired up your browser and requested a document from the World Wide Web. The problem is your viewport (that is, the viewable area for content in your browser’s window) is somewhere between 800 by 600 pixels and, if you’re lucky, anywhere in the range of 2000 by 1000 pixels. Even so, your monitor is most likely 72 pixels per inch and this means your resolution is low, seeing as a standard printed page is somewhere between 150 and 600 dots per inch (assuming 1 pixel ~= 1 dot). Fewer dots/pixels per inch means fewer words at a legible size per screen. This is why we scroll. We scroll because most documents are longer than can fit in one viewport unit.

When we talk about a “web page” are we simply referring to all of the rendered content in one HTML document? I assume that’s what advertisers refer to when they talk about “pageviews” — how many people have requested the HTML document that has my ad embedded somewhere in it? Again, I question the use of the term “page” here, as others have questioned the relevance of such a measure as the pageview itself. Businesses that lash themselves to arbitrary metrics without doing some honest thinking about what they’re really trying to do and practice “maximizing pageviews” to increase ad inventory deserve to fail in the coming years. Some have even called this practice of pagination evil. In any case, the page is dead, and so is the pageview.

Who killed the static page?

The other truth about “pages” is that new browser technologies are changing the very nature and the characteristics of HTML documents. Actually, the new browser technologies (I’m thinking of Javascript and AJAX in particular) are not new at all; they’re just beginning to be used well on major sites now, which means that the paradigm is shifting from static pages to dynamically drawn, internally refreshing pages. When you request a web “page” from a site like, say, Facebook, you are not just receiving an HTML document, you are downloading a complex set of Javascript code that allow individual components on the page to get and send data back to databases without reloading the entire “page”. (When you change your status message on FB, it updates without refreshing the entire page, which means you just robbed somebody of a “pageview”.) This destroys the old idea of the page as a static document, the basic assumption of on which the Google economy is based.

We now have to move towards thinking of “pages” as “screens” or even something like “views” — not “view” as in “page view” but “view” as in “a view” of something, as in a representation of data. (See Model-View-Controller.) The more sites move towards behaving like actual applications and are focused more on interaction versus mere presentation of content, the more urgent it is that we develop a better vocabulary for talking about what it is we are building.

Post to Twitter Tweet This Post

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…

Post to Twitter Tweet This Post

    Recent Work

    Follow Redub