A few days ago, my pal Eric Rumsey retweeted an article on designing “for the fold.” “The fold” refers to a print metaphor for the content that appears on the top half of the front page of a newspaper when it is folded. It’s that content that everyone sees, whether or not they open the paper. In web design, the fold refers to the content that is visible on the screen on the homepage before the user scrolls.

There is only one problem with the fold metaphor in web design: it doesn’t exist.

There is no page

When designers first started working on the web, they brought their metaphors from working with print to the screen. Thus, we’ve thought about web pages as “pages” for the past 15 years, imbuing them with many of the properties of their paper analogues, most notably a fixed size. We’ve designed first for screens that were 640 pixels wide, and then 800 pixels wide, then 1024 pixels. Then we embraced grids and settled on 960 pixels. The whole time we imagined our users seeing our page on a screen the size of our canvas. We started paying attention to heights, so that the most important content made it into the top 480, 600, or 768 pixels. Thus, the fold.

And then came the iPhone.

What’s the screen size again?

Suddenly, we realized that our users might see our websites on different screen sizes. But because we had this fixed canvas mentality, we simply added a second screen width, 320 pixels, to our fixed “desktop” width.

The problem is that there never was a fixed canvas to begin with.

Users have always visited our sites with different resolution screens. This is how we settled on our design widths, after all. Once enough folks came to our sites with an 800 x 600 resolution screen, we switched our layout. We knew that a handful of users had screens smaller than our designs, and that a handful had larger screens. But we chose to focus on the majority of screens that visited us, and design for those.

But once again, we were assuming that our users visited our sites in browser windows that filled the width of the screen. We were designing for screen sizes, not browser windows. Essentially, we ignored the fluid nature of the web in favor of a rigid, familiar metaphor that gave us the illusion of control.

Screen size variety expands

Well, after the iPhone came the iPad (768 pixels x 1024 pixels), Android phones (varied sizes), the Kindle, the Nook, the Kindle Fire, the iPhone 4’s retina screen, and now the iPad 3 with its crazy high-resolution retina display. Next month will bring another slew of devices with different screen sizes and resolutions. We’ll have to add a dozen, or two dozen screen sizes to our list of “fixed” canvases to design for if we still with the page metaphor.

I think it’s time we drop it. There is a better way.

You Can’t Control the Viewport

For years we’ve pretended that screen size equals browser window size, and it took the proliferation of mobile devices to make us realize our mistake. With the advent of Mobile Safari on the iPhone, Apple popularized a term for the browser window width: the viewport. Now we can stop pretending we’re designing for screens and accept the fact that we’re dealing with viewports. Only our old metaphors aren’t going to help us anymore. Because we can’t control the viewport.

So what do we do?

The Fluid Web

Last year at An Event Apart Boston, Jeremy Keith said something that’s really stuck with me: “the web has always been fluid, we just chose to ignore its fluidity.” We believed deeply in our print metaphor, and although we’re starting to see the limitations of the metaphor, the web itself hasn’t fundamentally changed.

In fact, if I were to choose my greatest professional influence, I might waffle between Jeffery Zeldman’s seminal Deigning with Web Standards or Ethan Marcotte’s terrific Responsive Web Design article, but in the end I think I’d say John Allsopp’s 2000 article “The Dao of Web Design” has done more than anything else to shape me as a web professional. Allsopp turns the prevalent thinking of the day (and today) on its head:

Perhaps the inability to “control” a page is a limitation, a bug of the web. … Let’s look at this through the other end of the microscope. The fact we can control a paper page is really a limitation of that medium. … The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility.

The current best practice in making pages that are, in Allsopp’s words, “adaptable” is Responsive Web Design. Ethan Marcotte coined the phrase to describe this technique of designing adaptive pages with three technologies: fluid grids, flexible images, and CSS3 media queries. Designing sites to be responsive (like this one) can save organizations a lot of overhead and maintenance, since you’re not maintaining content for two different sites (a mobile site and a “desktop” site), and you’re also not losing the battle to do device detection to direct users on different devices to the appropriate site1. It’s all one site, and it works on any device2.

The Fold is a Content Problem, Not a Design Problem

In general, we worry about the fold because we want to make sure that the most important information is seen by all of our users. This is a huge issue for libraries, especially those that build link farms on their homepages. We have a lot of resources, and we want to make sure everyone knows about them. But our users see a pileup of list items on a website and they run for the clean, simple embrace of Google. You see, we have a content problem in libraries. We try to show too much of it.

I redesigned our library website last August. A few months before I went live, I started talking about cutting about 70% of our content. Everyone freaked out. “We need those pages!” they said. “They get used a lot!” they insisted (despite analytics evidence to the contrary). “I teach using those!” I stopped mentioning cutting content.

But I still cut over 70% of the content on our website. And so far, no one has noticed3. UPDATE June 2018: 6 years later and still no one has noticed.

The pages still live on the server, where I monitor their use (almost none). I removed all of the links to them from our website. I was going to wait until it had been a full year to tell everyone that I killed their precious content, but I figure an academic year is plenty. Next week I’ll delete them from the server forever and no one, especially users, will care one bit.

The point? You most certainly have too much content4. And if you find yourself shuffling links around so that your important ones can live “above the fold,” you need to think more about your content than your design. I’ll write more about that soon,

For now, here are some rules for dealing with content below the fold:

  1. Get rid of it. If you don’t think it’s that important that users don’t need to see it, it probably isn’t important.
  2. Go to rule 1.

Your users will thank you for it5.

  1. Shameless plug: I’m leading a workshop on Responsive Design at ALA Annual (for LITA) this year, Sunday June 24 from 10:30 until noon. You should come. I promise you’ll have fun.  ↩
  2. If you marry responsive web design with progressive enhancement and think of layout as an “enhancement” (as Marcotte has been suggesting lately) you’ll find that your site will work on pretty much any device that can render HTML. Even an Apple Newton, for instance.  ↩
  3. Ok, one person has mentioned a missing page to me. But he wasn’t one of the freak out folks, and when I told him it was gone because no one usd it, he said “Oh, that makes sense.”  ↩
  4. It’s such a cliche that library websites are so cluttered that Aaron Schmidt was surprised when he did a content audit that revealed a pretty modest amount of content on a library website. ↩
  5. Some librarians will hate you, but as Tina Fey said, “as occupational hazards go, that’s much better than getting your arm caught in the thresher.” ↩