Four Common Web Print Problems

Unstyled content. A page prints out with zero formatting: big, chunky Times New Roman letters spit out of the printer. The font is the least vexing problem. The bigger issue is that a raw, unstyled web page printout often includes a lot of stuff that users don’t need: navigation elements, social networking links, archive links, and blogroll items that are useless to someone reading on paper. With all this unstyled, useless text preceding and following an article, a three-page blog post can become a sixteen page, tree-killing mess.

For example, here’s what Paul Krugman’s NYTimes.com blog looks when viewed online in late-2009:

If I want to print his entire blog — not just a single entry — how do I do it? Hmmm… I can’t.

So if I hit print on my browser (without hitting the small, designated “print” icon), I get this mess:

It’s 26 pages of unstyled content, a third of which is messy sidebar and navigation stuff I don’t need, an ugly waste of ink and paper.

Some web pages need two or three pages to print unstyled navigation and header junk before getting to the actual content on a page. The navigation links are worthless to someone reading this on the plane, let alone the five pages of sidebar clutter, ads, and footer content.

Endless comments. I notice a popular, useful article in my feed reader, go to the page, and print it out. When I go to the printer, I see a 60-page stack of paper waiting for me? Why? Because I got a two-page article, followed by 58 pages of user comments.

For example, this popular post on Copyblogger, is five pages long.

Or so you’d think. Print it out and it runs 57 pages:

Most of us would prefer to just get the original article, not all the chatter that followed it. A user could preview the printout in his browser, and tell it to only print the pages before the comments, but this work-around is inconvenient, and something most won’t think to do until they waste half a ream of paper.

One page only. This common printing problem with web sites occurs most commonly for Firefox users. When you print a five-page story, the first page prints, and then anything that would have appeared after that page just vanishes. So instead of getting the whole story, you get the first page worth of content, then maybe a page with the footer on it. If you’ve printed out several articles from a site, then go to your printer to grab the articles, it’s maddening to discover all you have is the first page of each.

Here’s an example from the blog of author Dan Baum:

This article is nearly 2000 words long. If I print it in Safari, I get every page of it, plus all the comments, nine pages total.:

But if I print it in Firefox, I get the first page, and the rest vanishes. Poof!

Few users would know to try another browser to make the page print correctly. Since Firefox users make up at least one in four people on the Internet, this kind of problem is unacceptable.

Prints too skinny. A final problem is when a web page or blog prints with the correct style, but in doing so, is formatted too small for the printed page, leaving close to half the page blank. The result, often, is small, hard-to-read text and more pages than would be necessary. Usually the culprit here is a design with lots of sidebar clutter that squeeze all of the content into a skinny middle column that runs long when the page is printed.

The Solutions

First, a general rule: every page should print well

Many sites feature a print icon that triggers some kind of printable version of a web page. And users often look for that icon, so you should offer it. That said, every page should print well, with our without someone hitting a print icon. In other words, you shouldn’t need to go to a “printer-friendly version” of a page to get a reliable printout. If someone hits print on their browser, the output should printer well. Many blogging tools and content management systems offer options for printer-friendly pages and “print templates.” These are great, but they aren’t the only places that you should focus on printer-friendly design.

A print style sheet

The first and most fundamental thing anyone should do to make site content more print-friendly is to set up a proper print style sheet. There are plenty of tutorials and guides to print style sheets (see below), but here are the three key fundamentals:

1. Set up a separate print style sheet., i.e. “print.css” that overrides the default screen styling when a page is sent to the printer. Your main CSS file should be set to media=”all”. What your print style sheet will do is override elements from your primary stylesheet when pages go to print. All you need is this:

<link rel=“style sheet.” href=“print.css” type=“text/css” media=“print” />

Be sure to put it AFTER the main CSS link in your header, not the other way around.

2. Take stuff away. So what’s IN this print style sheet.? Basically, the idea is that the print style sheet. should remove unnecessary elements that aren’t useful for print readers, and format the content to better fit a 8.5” by 11” page.

Removing elements is easy if you’ve done clean, accessible markup. Identify DIV’s that you won’t need on a print edition of your page and use the DISPLAY property to render them invisible. For example:

#sidebar, #navigation, #toolbar {display:none}

Another trick is to apply a “noprint” class to specific elements in your markup that are clearly for screen use only, and adjust the display element. For example, lets say you have a video in a blog post. Obviously the video won’t be of any use in the printed version of this post, so you can apply the “noprint” class to that embed code.

<object class=”noprint” width=”425″ height=”344″><param name=”movie” value=”http://www.youtube.com/v/-Sgj78QG9Bg&hl=en_US&fs=1&”></param><param name=”allowFullScreen” value=”true”></param><param name=”allowscriptaccess” value=”always”></param><embed src=”http://www.youtube.com/v/-Sgj78QG9Bg&hl=en_US&fs=1&” type=”application/x-shockwave-flash” allowscriptaccess=”always” allowfullscreen=”true” width=”425″ height=”344″></embed></object>

And then add “noprint” as an element not to display:

#sidebar, #navigation, #toolbar, .noprint {display:none}

3. Let the content fill the page. So now you’ve stripped away the elements a printed page reader doesn’t need or want to see, let’s reformat the content to play nice with their printer.

Let’s say your page content is wrapped in a #content DIV. On the live site, you might have it defined to a certain width, something like this:

#content {display:block; width:620px; padding:1em;}

What you’d want to do is take away the styling that locks the content into a certain width or shape. Unleash that text — that means lose widths, margins, padding, and flow it all as inline text. The browser will take it from there and print it to fit the page. So with the above #content div, you’d change it to something like this:

#content {display:inline; width:100%; padding: 0}

For more on using and applying print style sheets, check out the following:

• Print style sheet. – the definitive guide (Web Credible)
• CSS Design: Going to Print (A List Apart)
• Creating a Basic Print Style sheet. (Exploding Boy)
• A Useful Print Style sheet. (Kilian Valkhof)
• Little CSS print style sheet. tip (37 Signals)

Fix the one-page printing glitch.

One reason this can happen is that a designer uses tables or iframes to create their layouts, which can lead to printing problems. But as most designers have moved on to modern, more accessible design, this is less common. Still, if you’re trapped in 1999 web design techniques of laying out web pages with tables and frames and graphic “shims,” this may be the problem. Knock it off, read a good book on modern web design, and this problem will often disappear.

Still, as noted above, some CSS-driven web pages get cut off when the print (most often in Firefox) because a containing DIV can’t “break” across pages. It’s complicated but the problem is rooted in nested “block” DIV’s. Newer browsers seem to be handling this problem better, but this issue still affects a segment of visitors, so don’t ignore it. What happens is that the browser gets confused when it renders the page for multiple pages and instead of breaking the text over a number of pages, prints it as if the text would continue to flow from the bottom of a single page, which means that it doesn’t print at all. It wants to print to an 8.5” x 12-foot sheet of paper, but since it can’t, it just prints the first eleven inches of content.

The fix for this is surprisingly simple. If your containing DIV is truncating when printing make sure that its CSS declares it to be “display:inline.” If you need a DIV around it to define a block element, fine, but the immediate “container” should be rendered as “inline” for the print CSS.

Check out Ben Nadel’s excellent article for a more detailed explanation of this problem and how to fix it.

Default to printing without comments, but consider offering a “print with comments” option

Some readers might like to read all the comments that accompany and article, but most won’t specially if there are dozens of pages of comments. So as a matter of rules, stick to printing without comments as a default. Some sites offer two options: a link to “print with comments” and one to “print without comments.” You can offer that option as a choice for users. But again, make the default print style simple, useful, and readable for users on the move.

Follow those three fundamental solutions and you’ll eliminate 90% of the problems users might encounter printing your web pages.

A few final tips:

Set up a mini-logo or mini-masthead. Many sites use a miniaturized version of their logo or banner for the print edition to anchor the page. You can set it up with a “.print-only” class that shows up in print-styled version of the article, but not the screen-viewed pages. Or some CMS plug-ins allow you to select and provide a print-version logo. Either way, consider an economically-sized version of your logo for the printed to maintain your brand, but in a quiet, printer-friendly manner. This printed page from Salon is a good example:

Make text a readable size. Since you’re printing to a page, feel free to bump up your base font to a more readable size. Often, what works on-screen appears a bit small for many readers on the page. For the print.css, you can define your base font in points, not pixels, and go for something larger, like 12pt.

Set text to black. Web designers often set base fonts to a dark gray rather than a pure black. Don’t ask me why. We just do. That’s fine, but when gray goes to print on many printers, it tends to look fuzzy and often hard to read. When you set up a print style sheet, reset those colors to a pure black, and your printed pages will be cleaner and more reader-friendly.

Don’t use ads… but if you must, be discrete. I understand some publishers feel the pressure to generate revenue, even in print pages, but if you do so, try not to create huge, messy printout that users don’t want. The New York Times has a good example of small, unobtrusive advertising in their printouts:

Finally: remember, users are printing content, not sites. Most readers just want your content, not all the extra sidebar stuff, background graphics, navigation links, and promotional elements. They just want your essential content to go seamlessly from the screen to their printer in a easy-to-read format.

With that in mind, take the time to set up your web sites right so that when users hit “print,” they get what they want.

If you want to check out stuff in depth, here’s "a feed apart," a collection of real-time tweeting going on at the conference and my own rough notes (day one | day two) from the individual sessions. But for a quick skim, here are twelve of the most interesting take-aways from the conference:

Photo: FLICKR / John Morrison

Zeldman doesn’t see the point of your redesign

1. Jeffrey Zeldman suggested that the most important question to ask at the start of any redesign is "What problem are we trying to solve?" If the client can’t answer that question, you might not need a redesign. He points out that "you get tired of your site before the public does," and that doing a redesign mostly for cosmetic reasons is rarely a good idea. A redesign should take place to help a web site do something better or more effectively, not just to give it a new look.

2. Zeldman’s tips on design for non-designers: Limit the number of colors, type styles, type sizes, and use a simple layout. Do that, he says, any almost anything will look somewhat cohesive visually.

3. Along the same lines, Jason Santa Maria offered his "drop-dead guide for not making ugly stuff with type":

• don’t use two scripts
• don’t use two display typefaces
• don’t use two sans serif faces
• rule of thumb: ONE OF EACH (the key is contrast)
• if possible, pair fonts from the same designer
• look for contrast, not similarity, between fonts in use

4. Jason Santa Maria also suggested that when it comes to design, it’s better to think first and sketch out your ideas before sitting down at a computer. Let the computer be “a tool of refinement,” not the starting point for thinking through ideas for a design concept.

5. Kristina Halvorson said that the biggest reason for delays in web projects is content: people don’t plan for it, wait too late to create it, and don’t think through all the different types of content they will need to launch. She argued that web projects should START with a content strategy before a design strategy. And, perhaps most alarmingly to designers everywhere, she pushed a bold rule: “never use lorem ipsum.” (dummy text leads to mock-ups and design concepts that are removed/detached from the real site that will be delivered)

6. I didn’t love Dan Brown’s presentation (a bit too abstract and high-concept for my liking), but I loved — and totally agree with — this quote: “the curse of being a designer is you are perpetually unsatisfied with your work.”

Photo: FLICKR / John Morrison

Whitney Hess just called you a wimp.

7. Whitney Hess gave a great talk on user testing. “It looks good” is the worst feedback you can get from users: you want to hear what they don’t like, what confuses them. And the process of user testing and improvement should be ongoing, not a one-time exercise. She advocated doing user testing live, yourself, vs. online testing (“Don’t be a wimp! Be in the room with the test subject. Feel the pain!”) She quoted principals from a successful web business (iridesco.com) that relied heavily on user testing and feedback: “You have to have humility and listen. Users aren’t always right, but you need to hear them.”

8. Andy Clarke urged designers to shut off Photoshop and Illustrator and start designing “in the browser.” He argued that Photoshop mockups create static, unrealistic, flat model of a design for something dynamic. “We’re designing web pages, not a photo of a page.” Echoing many of the speakers, he advocated a “content-out approach.” He also argued emphatically that web pages don’t need to look the same in every browser — they just need to WORK in every browser. Experiences can vary.

Photo: FLICKR / John Morrison

Eric Meyer: Pro-JavaScript, Anti-Haircut

9. Eric Meyer predicted that within the next two years, JavaScript will largely replace Flash plug-ins on the web. He showed how JavaScript tools are helping enhance the web and lead innovation that browsers are slow to provide. “We don’t have to wait for the standards bodies or browser makers anymore.” Some cool stuff he showed: modernizr (making old browsers behave like newer ones), cufon (font replacement with JS, not Flash), typekit (a third-party font-replacement tool), raphael (JavaScript vector drawing), bluff (JavaScript graphing), and processing.js (lots of funky vector animation and games)

10. Luke Wroblewski talked about web forms and how they are almost all terrible. His pitch, in short: Nobody likes forms. Forms get in the way. Make them easy for your users. He provided a lots of examples and best practices (too much to summarize here), but his book covers it all in detail.

11. Dan Rubin’s talk was a bit all over the place, but he argued a simple, important principle: “If your design needs instructions, it probably needs to be redesigned.”

12. Dan Cederholm demonstrated lots of ways to use “progressive enrichment” in web design by using CSS3 today. His new book goes into detail. Lots of this will only be visible to people using newer browsers, but since most of it presentational, people with older browser won’t know what they’re missing. He refers to a Shaker design philosophy quote that applies well to web design: “Don’t make something unless it is both necessary and useful; but if it is both necessary and useful, don’t hesitate to make it beautiful.”