Putting your website to the print test, part 1
December 15, 2007 · 8:30 pm · tags: codinghorror css print series usability webstandards www
I am an avid reader of the interwebs. Google Reader is my only hope of staying (almost) up-to-date with the enormous stream of information that my always-growing list of subscriptions produces.
From time to time I stumble into a really good essay which screams to be printed on good ol’ paper: maybe it’s long and complex, maybe the original website layout is not optimal for reading, maybe I’m about to go to the bathroom and, boy, I love reading while… well, you get the point.
The problem is that not all authors cares about their content being put on something other than a screen… Yes, your pale-green background with darker-green 7pt text is totally rad, and will totally suck when my laser printer turns it into a blob of (simulated) gray.
In this article series I’ll be putting a bunch of popular websites to the printer test, and see how they fare.
Test Setup
- Open a single post in Firefox (simulating a desktop width of 1024px) and take screenshots of the content.
- Use Firefox to print the post to a PDF printer (the freeware CutePDF, which in turn relies on GhostScript for PDF generation).
- Open the generated PDF and take a screenshots of the content.
- Crop & resize the webpage screenshot to match the PDF one as much as possible.
- Elaborate and comment :)
Test subject nr.1: Jeff Atwood’s “Coding Horror”
web address: www.codinghorror.com
Jeff is one of my favorite bloggers: he regularly writes a tremendous amount of well-documented and interesting articles, with an overall quality I could only dream of.
As soon as you open his blog, it’s clear that Jeff is all about content and readability: a two-column layout with fluid content area and a thin and unobtrusive sidebar, almost-black (#333333, for us color-obsessed) text with white background and blue links which underline when hovered. Jeff has advertising, but all the ads are text based and carefully placed where they do not interfere with the content: two in the sidebar, one at the bottom of the post, before the comments.
Comments are allowed with CAPTCHA as a safety measure. Each comment has a light blue background, except for Jeff’s own comments which have a light red tint. And that’s it: no annoying gravatars, no shiny AJAXy stuff, just the meat. Oh, and a small copyright notice at the bottom.
Overall, this is a layout that could already fit the printed media. But Jeff went the extra mile and customized things further with a dedicated “print.css”:
The sidebar is gone and the post content takes all the available width. The search bar on the top right is gone, while the (small) text ad at the end of the post is still there. Comments are still there, as well as the final copyright notice. The comment input form is obviously gone.
Overall, Jeff did a great job with his print stylesheet. However, there are a few glitches:
- The “almost black” body text, which works like a charm on the screen, should have been replaced by black: monochrome printers dither everything which is not pure black. On big headings, no problem. On body text, it’s unnecessary noise and a loss of resolution.
- Links: what good are links on a sheet of paper? You can’t click them, you can’t hover them, so give them the same attributes of regular text, otherwise they’ll just be randomly colored (or grayed) words in your printed post.
- Each comment entry retains its background, whose only purpose seems to separate each comment from its siblings. An horizontal ruler would have served the same functionality, without wasting that much toner/ink (OK, Jeff, you can keep the red “boss background” :)
And that’s it for part one. In part two, we’ll take a look at Scott Hanselman’s Computer Zen. Stay tuned!
TDD ain’t no snowboarding
November 4, 2007 · 12:18 pm · tags: programming tdd
In his latest post, the excellent Jean Paul Boodhoo answers publicly to an email he received from a guy who has doubts with TDD:
“I’m not using this methodology (TDD) because my principal question remains unanswered. I know that with TDD you should release less bugs, but what about the time needed to develop with that methodology ? I would like to know if the time to develop an enterprise solution is faster, equal, or longer with TDD. I hope you will be able to answer me because I’m very intrigued and interested by TDD and DDD.”
Jean Paul, being the nice guy he is, writes:
“Like snowboarding (or any new skill you wish to acquire), in the beginning a lot of learning is going to be taking place. For the majority of people who venture into TDD waters, they realize that there are potential big holes in their skillset that may cause them pain in this new world.”
Let me disagree. I am an enterprise programmer, and I have tried both: snowboarding and TDD. The first, I quitted immediately. The latter became my natural way of coding in a few days.
When I first approached snowboarding, I definitely lacked a LOT of prerequisites needed for such a manly sport:
- I had NO previous experience whatsoever in winter sports (except for distant memories of an old C64 hit, which didn’t include snowboarding, either).
- The nearest mountain was 3hrs from my place.
- I was definitely overweight (like, 98 kg x 172 cm — that would be 216 pounds x 5.64 feet).
- My ankles are quite fragile.
The very first day I put my feet on a snowboard, my good, already-skilled, very-athletic friends brought me on the top of the track and let me there on my own. It took me four hours to reach the bottom (it was a 15 min. track), and I nearly passed out for trying to get my fat arse off the soft, cold snow I constantly kept falling into. By the end of that atrocious first day, I had realized two things:
- If I really wanted to learn snowboarding, I had to loose a lot of weight and hire a good instructor.
- I didn’t really want to learn snowboarding. Wasn’t really worth it.
When I decided to give Test Driven Development a try, the only “prerequisites” I had were my natural curiosity and the sensation it was going to be great. No one else was doing it at my workplace (or so I thought), so I had to start it all on my own. I read a pair of excellent introductions to the concepts behind TDD, I found out the de facto standard for .NET unit testing, and started experimenting, following the One Rule behind it all: first the tests, then the code.
And that’s all. Everything came (and keeps coming) naturally: good basic principles like isolation, self-contained tests, dependency injection, and so on. There is no steep learning curve, there is no big initial investment (try buying a full set of snowboarding equipment to discover shortly after that you’re not going to use it…), there is no need for a professional instructor other than those good guys that already inspired you in the beginning.
Of course, I had to fight with my bosses, because yes, it does cost you that extra span of time, and you’ll have to show them it’s time well spent. And show you will. If, and only if, you stop seeking pre-cooked answers from those who already tried it and start friggin’ DOING something.
Just double-click that (whatever-)Unit installer. Beats snowboarding everyday :).
