Redub LLC

Depends on who you ask. I like to define a wireframe as equivalent to a keyframe in a storyboard. (The problem is that most websites are not linear, but that’s a topic for another post.) I’ve done thousands of wireframes in my career as an Information Architect/Interaction Designer (have we settled on an appropriate title yet? I guess not). I don’t live for wireframing, even though making them is one of my most marketable skills. I have developed a very pragmatic view of it, having seen how my wireframe “bibles” are clung to by business customers, salespeople and QA, and then unceremoniously forgotten after the first beta launch. The tricky thing about wireframes is that they can mean different things to different people, depending on what stage of the project you’re in.

So now I have developed a Zen-like detachment with wireframes: they are ephemeral. In fact, I make it a habit of suggesting to clients that we schedule into the project plan a wireframe bonfire, usually sometime after launch. Every time, I get a double take and a laugh of disbelief. Why a bonfire? To emphasize the reality of the end goal, the working application itself. Users don’t use wireframes. Also, I want to make the point that wireframes are dead and the application is alive, that decisions that may have looked great on paper may, in reality, not work when put in front of real users.

The Evolution of Wireframes

Wireframes need to evolve over the course of a project. For larger projects (3 to 9 months) I’ve found it useful to clarify both for myself and the business customer what to expect from wireframes at different stages.

Lo-Res

In the nascent stages of a project, when ideas are being thrown about by all stakeholders and everything is in flux, lo-res wireframes may appear on anything from whiteboards, scrawled on the backs of napkins or scrap paper. Think of them as thumbnail sketches.

Lo-Res wireframes should be

• Sketchy
• Loose
• Quick
• General
• Monochromatic

An example of a Lo-Res wireframe

Usually, I will gather these scraps of paper and translate them into digital roughs.

A digital Lo-Res wireframe

Note the “default” style for everything:

• Labels should be descriptive of the content. Avoid using real copy (except for logo)
• Content areas are grey blocks with the label in the top left corner
• Multimedia or graphics are indicated by a different grey box, with label centered in middle
• Buttons are indicated by rounded corner and centered label text

Not using copy is important at this stage because you don’t necessarily want the client focusing on details yet. It can be distracting from the larger goal, which is that you want to get agreement and sign-off on basic proportional representation of types of content and their general hierarchy. At this stage, you should be able to use this to answer the question: What are the primary, secondary, and tertiary content blocks on the page?

Medium Res

Once you have established what content needs to appear on the page and have a good sense of their general hierarchy, you can start to add more detail, in the form of more realistic headings, navigational copy, and basic indications of functionality.

A Medium-Res Wireframe

As you can see, there’s a little more resolution here, like you’re adjusting the focal length so that you can make out more clearly the major elements of the screen. But you’ll notice that not everything is in focus yet, namely the body copy, which I like to represent as grey bars to give an idea of type density without getting bogged down into specifics yet.

I’ve found that once you start introducing dummy copy and dummy data, the viewer’s expectations and reactions start to change, regardless of your frantic entreaties to disregard such characteristics. There is a point at which our attention begins to hone in and we start to notice certain elements, unconsciously or not, and it takes all of your discipline and awareness as creator of these documents to modulate the viewer’s expectations through the blurring and smudging of various elements (at one point I considered applying a “Pencil Sketch” filter in Photoshop to my wireframes). But at some point, you will have to address these things, such as color, highlighting, typography, dimensionality, and data, which will bring your wireframes to to a higher level of resolution and expectation.

Tomorrow: I’ll dig up some Hi-Res wireframes and talk about clickable prototypes, the ultimate in high-resolution wireframes. Stay tuned!

Category: wireframes | | Permalink | RSS 2.0

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?

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.

Category: the page is dead | | Permalink | RSS 2.0

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…

Category: the page is dead | | Permalink | RSS 2.0