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.”

The problem is that not only do different desktop email clients like Outlook or Thunderbird render HTML email messages differently, popular webmail tools like Hotmail, Yahoo Mail, and Gmail all rewrite, change, and alter your code to fit it within their web-based email application. Some disable CSS styles, some break any links to external stylesheets, and almost all of them will pick and choose between which CSS elements they will support, and which they will ignore.

Clients already receive slick, cool-looking HTML email in their in-boxes… They don’t care about coding and compatibility problems — they just want something cool, too. “Hey, if Apple can do it,” they say, “why can’t we?”

But wait, it gets better — increasingly, thanks to Spam and security concerns, the default mode of many webmail clients is to block images from new recipients until a user opts to allow them.

So let’s review: there are countless email readers and applications out there. All of them will render your HTML email differently, supporting all or none of your CSS. In varying degrees they will all rewrite your code. And, quite often, your images won’t be viewable to the end user. Swell.

One solution might be to take Zeldman’s advice and stop using HTML email altogether. After all, email isn’t the web, so why try to treat it as if it were? Save design for web pages and keep email light, text-only, and simple.

But most of us have clients or bosses who already receive slick, cool-looking HTML email in their in-boxes. As consumers, they already see that some people are generating pretty, polished, stylized emails. They don’t care about coding and compatibility problems — they just want something cool, too. “Hey, if Apple can do it,” they say, not unreasonably, “why can’t we?”

Moreover, from a marketing perspective, many organizations find that well-designed HTML emails get higher open and click-through rates than text-only email.

So, it seems, the solution for designers who need to design HTML email is to create designs that work relatively consistently across platforms and email clients. Here are eight tips for making that happen:

1. Make Nice with Tables.

Most good web designers these days have turned away from the use of tables on layout, opting instead for usable, accessible CSS-based presentation and layout. However, with HTML email, a lot of these approaches won’t work. Almost every web-based email client will ignore or mangle CSS-based layout. Those carefully floated and positioned elements will wind up in entirely different places than you intend. The only way to ensure that things line up the way you want them to across the wide range of email clients is to use tables.

Yes, tables. It’s tough to accept, but tables are a necessary evil for HTML email. You don’t have to don’t go back to the worst of table-based layout techniques — spacer images, hacked up artwork, and endlessly nested code. But tables can provide basic structure, columns, and grids for laying out HTML email. It may be a bitter pill to swallow, but if Rocky could team up with Apollo, if Sarah Connor could learn to trust a Terminator, if Johnny Damon could play with the Yankees, you can learn to get along with tables again. You may feel dirty, but you’ll get over it, I promise.

2. Use CSS… just not too much.

Here’s the good news: you can use CSS to style content in HTML emails. But the bad news: you can’t use it too much. Campaign Monitor has an essential, comprehensive guide to which CSS elements work in various email clients, but here’s the Cliff Notes version: generally speaking, you can use CSS to format content, but don’t rely on it for layout. Use CSS to style font sizing and color. Use CSS for basic border and background background color effects. Use CSS to apply some simple padding and margin effects. Beyond that, you’re starting to ask for trouble. When I design an HTML email template, I generally use CSS to handle the presentation of body fonts, headers, and simple alignment and spacing.

3. Ignore the HEAD, focus on the BODY

An important rule to remember is not to link to an external stylesheet. Many email clients, desktop and web-based alike, are suspicious of an email linking to an external file. Some will completely ignore the attempt to import or link to an external CSS file. Moreover, many webmail clients will disregard any code put above the BODY element. So the key is to not only put your CSS style inline in your HTML, but to put it in the BODY of the email, not in the HEAD. With the annoying exception of Gmail, almost every email client will understand and render your inline CSS for basic styling, as long as you put it all in the BODY element.

4. Be smart with images.

Some rules of thumb to remember with images:

Always give images absolute, not relative, paths. Because your message is going to places you can’t predict, all of your images need to be linked with fixed, absolute paths.

Always use ALT tags. They’re not just for good usability and accessibility practices. If an email client has images turned off (and increasingly, email clients turn images off by default) you want them to be able to read a description of the image.

Always provide size attributes for images. If you specify HEIGHT and WIDTH for images, your layout will stay more intact, whether or not someone can see your images.

Before sending out an HTML email, always test it with images turned off. When you try to read the email without any images, does it still make sense? Can a reader still understand your message without the images showing up? If not, go back and rework the design so that, in a worst-case scenario, a reader won’t miss anything important if their reader refuses to display your images. A great tool for testing this is the Web Developer plugin for Firefox. If you don’t have it already, get it now.

5. Go Skinny and Top Heavy.

These days, web sites are getting wider, thanks to the popularity of big monitors and supertanker-sized laptops. But emails can’t afford to get so big. Most people still see email in smaller windows on their desktops. And many only see the top parts of emails, if they skim them through a “preview pane” in their email client. So when you design an email, it needs to be more narrow than many web pages, and it needs to have the most important stuff at the top. Generally-speaking, stick to a width 600 pixels or less when building an email. Anything wider, and a lot of readers will never see the right side of your design.

And if you want readers to see anything more than your logo or some big, pretty image at the top of your email, be sure to get to some real content within the top 200 or 300 pixels from the top of your email. The “preview pane” in Outlook, for example, might only let readers see the a 600 x 200 pixel preview of your message. If you don’t design well for that space, your readers may hit delete before ever bothering to scroll down and find out what you had to say.

6. Design for the Worst-Case Scenario.

Take time to design your email for situations where images or CSS may be turned off. If you haven’t already read Dan Cederholm’s Bulletproof Web Design, order it now. Cederholm provides excellent techniques and methods for making design that is “bulletproof” to most potential problems. While of some Cederholm’s approaches won’t work in HTML email, his general principles are applicable. For example, if you have an image that might be blocked, be sure that there is a background color behind it that will maintain the general look of the page. Plan ahead.

Here’s another example. For one email template I built, we had a sidebar with a special header. To match a non-standard font from their branding, I used a graphic. But since I can’t guarantee that everyone will see this image, I need to make sure that an image-less or unstyled version of the same email will still convey the same basic information. I do this by wrapping an H5 tag around the image. Here’s the HTML:

<h5><img src=”[absolute path to image]/head-goodnews.gif” alt=”GOOD NEWS” width=”140″ height=”20″></h5>

The H5 has the following CSS applied to it:

h5 { font-size: 120%; color: #990000; margin: 0 6px 6px 0;font-weight:bold; border-top:solid #cccccc 1px; line-height: 1.8em;}

Viewed normally, all the H5 does is add a light gray line above the image. Since there’s no text there, it doesn’t need to apply font-sizing or color to anything. Interestingly, though, if the image is turned off, and it will still style the ALT text according to the H5 CSS. So, as you can see below, it will still make the header the right size and the right color. It won’t match the font I used in the image, but at least it will be a close approximate match, and it will still style the line above the header. Finally, if I turn off both the image and the CSS, the H5 still gives the ALT text the standard H5 styling, which is at least better than nothing:
This is just one example, but hopefully I’m making my point. The email should “gracefully degrade” by building it to communicate effectively, even if the CSS or the images get blocked.

7. Provide alternatives.

Your HTML email should always offer prominent links to two alternate versions of your message — a web-based version of the email and a text-only or mobile edition. If you want to make mobile web enthusiasts happy, offer a “mobile edition,” which is just simple HTML with basic content, links, and simple formatting (bold and italic). Yes, it’s more work, but you always want to give your audience a choice. Some people want no-frills text in their in-box, some will never unblock images in their email, but might click on a link to a web-based version of your message instead. And there are always blackberry-addicted readers out there who want to read your message, but need a cleaner, simpler edition. With a little extra effort, you maximize the chances that your audience will see your message. It’s OK if they decide how pretty it looks. Don’t write off any part of your audience because you demand they view your message in a certain way.

8. Test obsessively.

You can design an HTML email that looks wonderful on your screen and in your own email in-box, but that’s just the starting point. You can’t possible test for every email appication in existence, but you should definitely test as many of the major email applications as possible. If you don’t already have accounts with Hotmail, Yahoo Mail, and Gmail, take a few minutes and set up test accounts. If you use Outlook primarily, download Thunderbird or another free email client as a secondary email application to use for testing.

One method I use is to make this simple is to set up a email group that includes all of my test accounts. When I have a draft, I send a test email to that group in one blast and lets me quickly check how everything looks.

Don’t be alarmed if Gmail looks the worst. Gmail, my email client of choice, is sadly weak in terms of supporting HTML emails and often ignores CSS styling that every other email reader handles beautifully. I hold out hopes that Google may improve on this in the future. But for now, I find that you can use the techniques listed above to get Gmail close to matching the design that other readers will see, but it can be tough to get it to match exactly without doing endless inline styling with font tags.

Finally, if you design on a Mac, be sure to test how things look on a Windows machine — fonts appear smaller on a Mac, so you don’t want to be surprised at how it looks on a PC. Macs are great, but they still make up less than 5% of the overall home computer market. It’s flat-out irresonsible and arrogant not to test on the platform that the vast majority of recipients will use when they get your email. There’s simply no excuse for not testing on a PC.

That’s it for now. This is really just scratching the surface, but hopefully it will save you some time trying to figure out why your HTML email design looks terrible in Hotmail or Yahoo. For more on HTML email design, including best practices and tips on marketing, check out the following:

• Campaign Monitor: Email Design Guidelines for 2008
• MailChimp: Email Marketing Guide
• Loren McDonald: 20 HTML Email Tips

In the meantime, let me know if you have any additional tips and suggestions if your own… HTML email design is an ever-evolving and changing practice. Start with best practices now and you’ll be ahead of the curve.