Supporting a Printer-Friendly Page Button (Part 2)

In last week's column (Supporting a "Printer Friendly Page" Button: Part I), I posed the problem of how to create a printer-friendly version of a Web page. I assumed that this meant getting rid of most -- but not all -- of the stuff on your Master Page (copyright notices and legal disclaimers would have to remain, for instance). I also assumed that you'd want to offer this button on every page on your site, rather than have to deal with it on a case by case basis. The solution I proposed last week involved swapping in a new Master Page with the minimum number of controls on it at run time, when the user clicked on a "Printer Friendly Version" button. This week I'll look at two other solutions.

Use the Theme
My second solution is to swap in a different Theme rather than a different Master Page. The structure of this solution is the same as the Master Page solution I proposed last week, but with this code in the PreInit event.

Here you'll want to create a new theme that uses CCS rules to remove items from your page or adjust their location. Your existing stylesheet is probably already controlling the appearance and placement of your controls so you just need to tweak those settings as part of creating your new theme. For instance, these two rules control the tags with the ID LogoImage (an Image control on my MasterPage) and Main (a ContentPlaceHolder control):

As with the Master Page solution, you'll need to keep your default and printer-friendly themes synchronized. At the very least, if you add anything to your Master Page that you don't want on your printer-friendly page, you'll need to update both stylesheets. Depending on the differences between your printer-friendly theme and your standard theme, this solution might be easier or harder to maintain than having a second Master Page. Unlike the Master Page solution, you can't add new controls to the printer-friendly version of the page.

Use JavaScript
My third solution is to add some JavaScript to your Master Page that does what the stylesheet in the previous solution does: make some items disappear and others move around. The JavaScript equivalent to the CSS in my previous example would look like this:

In many ways this solution is the best of the three that I've presented, as it doesn't require a trip to the server to redisplay the page. Furthermore, the whole solution is encapsulated within the master file and doesn't require another file to be added to the site. You will still have some synchronization work: As items are added or removed from the Master Page, the JavaScript will need to be updated. And the JavaScript is sufficiently simple that even a JavaScript-phobic developer like me can probably work with it.

However, because you are using client-side code, you do need to recognize that executing JavaScript is browser dependent (though this code ran successfully in IE 7 and FireFox 3.0). Unlike the Theme-based solution, there is a penalty for removing controls from the Master page. Your stylesheets won't mind having a rule with no corresponding control, but JavaScript code will fail if you remove a control it's trying to modify.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.