Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
I'll fill this up with notes and other content later, but in the meantime here are the slides from my talk this morning:
I've written a bunch of handy stuff on print styles, here are some links (or you can see all posts tagged print on my blog) along with other resources (most of this is referenced in my slides):
I got feedback from my talk, and it was overwhelmingly positive. Consider mine was the first lightning talk of the first session of the first day immediately after the keynote, I'm just pleased people took a moment to vote.
Voting consisted of asking attendees to drop a colored card into a basket representing my talk. There were three options. I got 15 green cards (it was amazing), 4 yellow cards (it was okay), and no red cards (I didn't like it).
Only one person left a comment, which was Talked too fast. I cannot disagree with that. With 10 minutes to cover 42 slides and do so to an audience of non-native English speakers, I'm thrilled I only received that comment once (though I suspect many others agreed).
A couple days ago I mentioned that I'd be speaking at the Ace! Conference in Krakow. I also suggested I might have other speaking gigs around the same time in Europe. Now I can announce that I'll be in Bergen, Norway speaking at the Booster Conference.
Most of my talks lately have been about accessibility, but for this one I'll be talking about another topic that makes me rant — print styles:
The push for responsive web design has helped web developers consider how the sites they develop can adapt to different devices, including sizes, screen resolutions, and even contexts. It should now be easier than ever to respond to a format that has existed since the start of the web — print. I'll walk through the process for making your responsive sites respond to the format we most often forget and show you how to use Google Analytics to track what pages are printed from your site.
Given the generalized nature of the conference (it bills itself as a software conference for the whole team), I am looking forward to speaking to a diverse group of attendees, both as users and developers.
The conference runs from March 11 through the 13th, but I'll be presenting on day one (Wednesday the 11th). The conference will be held at the Scandic Hotel Bergen City, and again for my own benefit I have embedded a map.
This afternoon I awkwardly stumbled through my talk for CSS Summit, Making Your Site Printable. I can tell you that speaking to a screen instead of to a room full of people is a whole different experience than I was expecting. Fortunately for you I do not have an audio/video recording. I do however, have all the slides.
I'd like to note that thanks to the generosity of CSS Summit, I was provided with two tickets to today's talks that I could give away as I saw fit. I opted to offer them to two deserving young women from the Buffalo chapter of Girl Develop It (neither heckled me):
Finally, one of the novel things about an online conference is that attendees seem to be more active on Twitter. I got feedback and questions, and even fielded a few sub-tweets (I happen to know the print styles aren't glamorous, but most of the fundamentals aren't). I've collected the tweets in a Storify, which I have embedded here:
Update: July 21, 2014
Based on the activity from these two tweets alone, I am really hopeful that web developers are starting to see that print styles have value and belong in a responsive workflow. Only time will tell. The tweets:
In just under two weeks the 6th annual online, live CSS and SASS conference, CSS Summit, will be underway and I have been asked to speak on print styles. You don't have to deal with airports, hotels, taxis, or strangers. Heck, you don't even need to leave your desk. The event description:
Environments for Humans brings together some of the Web's most notable experts in [CSS] and [SASS] for an all-new, three-day online conference, the CSS Summit 2014! Bring the experts to your desktop July 15-July 17, 2014 from 9AM
to
4PM (CT).
I'll be speaking on Tuesday, July 15 at 11am CT (10am ET). The abstract for my talk should sound familiar to those who have heard me rant about print in the past:
The push for responsive web design has helped web developers consider how the sites they develop can adapt to different devices, including sizes, screen resolutions, and even contexts.
It should now be easier than ever to respond to a format that has existed since the start of the web — print.
I'll walk through the process for making your responsive sites respond to the format we most often forget and show you how to use Google Analytics to track what pages are printed from your site.
The rest of the speaker lineup is Estelle Weyl, Jing Jin, Luis Rodriguez, Matt Carver, Jason Pamental, Rachel Andrew, Ana Tudor, Dave Arel, Russ Weakley, Rachel Nabors, Justine Jordan, Chris Eppstein, Patrick Fulton, Ben Callahan, Tab Atkins, Roy Tomeij, and Sam Richard
Whatever you do, don't pay full price. You can get 20% off by using the discount code 20ADRIAN. So go buy some tickets now and then listen to me rant. Go ahead. Really, go on, buy a ticket.
With more and more people relying on a mobile device as their primary computing platform, it stands to reason that more and more mobile users may want to print web page content — whether directly to a printer or as a PDF for later use (or display as in the case of scannable bar/QR codes).
Past
The state of print style support on mobile browsers has been abysmal for some time. At my talks on making sites printable I even demonstrated that by showing support in the latest and greatest (based on your platform preference) at the time (Samsung Galaxy S4 using the default Android browser). If you look at the slides (slide 50 from Stir Trek and slide 51 from WordCamp Buffalo) you'll see that the output was pretty much just the mobile layout centered in a sheet of paper, despite well-defined print styles.
Screen shots of printed output from a Samsung Galaxy S4 using the default Android browser, circa May 2013 (I forget which Android release this was). I didn't output to PDF because I couldn't at the time.
Present
Fast forward and support for print styles in mobile browsers has improved. At least for Android.
My tests on an iPad were futile, as Safari and Opera Coast both want to print to a printer (which I don't have at home) and not to a PDF. I tried to print to Google Cloud Print from Chrome on the iPad and got 404 errors. Opera Mini just doesn't seem to offer the option. Anyone with an iDevice who would like to chip in, I used the Algonquin Studios jobs page for my tests, as it typically fits on one sheet.
On Android I had better luck. The default Android browser, Chrome and Firefox all allowed me to print. None of Yandex, Opera, Opera Beta, Opera Classic nor Opera Mini offered a print option. Screen shots of where you can find the print option in these three browsers:
Screen shots of print dialogs from default Android browser (Mozilla/5.0 (Linux; Android 4.4.2; en-us; SAMSUNG SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36), Chrome (Mozilla/5.0 (Linux; Android 4.4.2; SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.141 Mobile Safari/537.36), and Firefox (Mozilla/5.0 (Android; Mobile; rv:30.0) Gecko/30.0 Firefox/30.0).
Unlike last year's tests, the print output of each of these browsers shows that they are using the site's print styles. Which means they are truly honoring responsive design by following the appropriate media query in the appropriate context. Examples of the output:
Screen shots of the PDF files from each of the three browsers (left to right, Android browser, Chrome, Firefox). Select an image to see the full PDF, but note that the Android browser (the first one) is a 14.7MB PDF while the others are less than 60kb.
Chrome for Android
Chrome did a great job of rendering all of the elements as I expect, namely similarly to how Chrome does on my Windows machine. By default it disables background colors, which is good for me since I have two errant declarations I did not clear. It also rendered the QR code which is only generated when the user prints the page (or performs a print preview). (I have a tutorial on how you can auto-generate QR codes at print-time should that feature interest you.)
Android Browser
The Android browser behaved a bit differently than Chrome. While it also ignored background colors and also pulled down the QR code, it didn't use the custom fonts. It also greatly reduced the margin at the top of the page. Most oddly of all is that it rendered the PDF as a bitmap. A 14.7MB bitmap. Whereas in the Chrome PDF you can zoom in to see crisp edges on the text and logos (SVG), the Android browser PDF shows the constituent pixels of every otherwise vector item.
Firefox for Android
Firefox honored the background colors (oops) and the typefaces. It failed to render the QR code. Firefox also scaled the text larger than Chrome and larger than Firefox on my Windows machine. Most interestingly of all, however, was the paper size. Unlike Chrome and Android browser (8.5 × 11 inches), the paper size on Firefox's PDF is 6.67 × 11.11 inches.
Other Platforms
As I noted above, I couldn't get print to work on my iPad. I also went to the Apple store to try it, but none of the devices that I checked were either connected to a printer or could print to PDF. I don't have a Windows Phone, though I also went to the Microsoft Store and still had no luck. I don't have immediate access to a BlackBerry of any kind. If you have a device and/or browser combo I did not test, feel free to comment below and let me know what you saw.
What to Do
(Continue to) make print styles. So far it looks like they will work on current mobile browsers that allow printing or that export to PDF.
Related
If you want to learn how print media queries can be useful to you, check out any of the following links (which themselves may contain many more links).
November was kind enough to test on an iOS device and saw the same output as I got from Android. That's two platforms covered, which is good news in general.
@aardrian print via Safari on iOS (current version) ends up looking exactly like your Firefox on Android sample.
Today my second article at Web Standards Sherpa has been posted, Tracking Printed Pages (or How to Validate Assumptions). I fit a lot in there, but the gist is that I show you how to track when and what pages from a site are printed so you can make a better decision about where to invest your effort.
I also draw a comparison to the time we all spend on building carousels for sites, but may not be tracking. After all, if no one uses the carousel and people do print pages from your site, you might just want to change where you are spending your development time.
The article also has the nifty ReadSpeaker feature which means that the page can read the article aloud to you in a voice that is entirely unlike mine (at least it's a male voice by default).
What guides your project decisions? Data or assumptions? Adrian discusses the importance of tracking site features, like print styles, to inform how and where you invest effort.Read it…
I have alluded to this point in the past. Usually when I get off on a rant about print styles, I lump it into the overall process of making responsive sites and I use media query formatting in my examples. But I haven't just flat-out said that print styles are media queries.
I believe I always assumed that the reader would just understand that in the context of my writing, in using print styles on sites, and understanding that print is a medium in which web pages have been displayed for years.
Peter-Paul Koch (@ppk on Twitter) has spent years tracking browser support for even some of the most minute features. From way back in the evolt.org days I've watched him dive into testing without concern for his own wellbeing (browsers have sharp edges). Most recently he put out calls on the Twitters for web developers to fill out a survey about how they use media queries.
I did not grab a screen shot of the survey, but he asked the following two questions (which you can glean from the raw results):
Which media queries have you used AT ALL in practical projects in the past year?
Which media queries have you used in MORE THAN HALF of your practical projects in the past year?
He presented the following options:
width
height
device-width
device-height
device-pixel-ratio
resolution
orientation
aspect-ratio
device-aspect-ratio
Other
You'll note that “print” is not an option. Despite that, 1% of his respondents to the questions (of the 33 and 23, respectively, that chose “other”) wrote in “print,” because that's what this chart indicates in his write-up (Media query/RWD/viewport survey results):
Media query use
Media query
Regular use
Occasional use
width
84%
7%
device-width
32%
15%
device-pixel-ratio
25%
18%
height
17%
16%
orientation
13%
20%
resolution
9%
5%
device-height
7%
7%
aspect-ratio
3%
4%
device-aspect-ratio
3%
3%
print
1%
1%
I want to be clear, I am not faulting PPK. His survey was very much about the work he's been doing lately understanding how viewports, pixel densities, and screen sizes are reported across the current landscape (jungle) of devices. Instead, I am happy that 1% of his 1,251 respondents consider print to be a media query and took the time to make it a write-in answer.
Now I just wonder how long before the other 99% would do the same. Or even for the much smaller percentage who write media query tutorials, examples, libraries, CMSes, and so on.
If you want to learn how print media queries can be useful to you, please follow the links below (which themselves contain many more links). “The more you know.”
Yesterday I had the pleasure of visiting the University at Buffalo (my alma mater) to give a presentation for its CIT professional development series. I got to talk about responsive design.
Knowing in advance that the room would have technical and non-technical users I went for a code-free presentation. One thing I learned is that code would have been useful, so if you're looking for any in here you won't find it.
I understand there is video from the event, and as soon as I have it I'll share it here as well. In the meantime, enjoy the slides without any context. Which may be more entertaining than my typically awful attempts at humor.
Today I spoke at Buffalo's second WordCamp. I am a casual WordPress user, not a developer, though my decade-and-a-half experience with multiple blogs and content management systems (even writing our own CMS at Algonquin Studios) gives me plenty of insight into the common challenges users and developers face across all platforms.
I have also learned that few developers work on just one platform. Nearly all of us touch more than one platform in our careers (or workday), and my experience from last year is that everyone attending falls into that boat. When I made these slides I wanted to make sure I was presenting ideas and concepts that developers could take to any platform.
There will be video of my talk (featuring my awful sense of humor) in probably a month or so (based on last year's timeline). When it's available I will post it here.
That being said, you don't need to be a WordPress developer to get something from these slides. Enjoy!
Looks like the WooThemes slider/carousel will be getting Google Analytics event tracking built in for a future release — now you don't need to be a coder to figure out if anyone is clicking your carousel:
Yay, @tomharrigan and I will chat about getting GA event tracking features into WooSlider! #wcbuf (now he's stuck)
This Saturday I will be speaking at Buffalo's second WordCamp. Last year was a great day-long event filled with many good speakers (not just me!), so I am looking forward to being an attendee as well.
If you are new to WordCamp Buffalo, a quick overview:
WordCamp Buffalo is a one day conference held in Buffalo, NY focusing on WordPress. Our goal is to increase knowledge about WordPress for people who already are working with it, and show some benefits of using it for anyone who may be interested, but aren’t currently working with WordPress.
As a regular WordPress user with over 15 years experience in content management as a concept and more than a decade experience having built our own multi-lingual enterprise web content management system (QuantumCMS) at Algonquin Studios, my talk should give you skills you can take to any platform. An abstract of my talk, Making Your Site Printable, is on the WordCamp Buffalo site. I'll post slides here after the talk.
For the talk I'll be drawing on my 20 years of web development experience, extensive work with responsive design, articles I've written for .net Magazine and Web Standards Sherpa, previous talks, my PrintShame site, and Google Analytics. It's guaranteed to be awesome (guarantees not guaranteed).
Last year I spoke at WordCamp Buffalo on the topic Content Strategy. The slides and video of my talk are online for you to watch, in case you want to make sure I speak well enough to warrant buying a ticket to see me this year.
You can learn more about the other sessions and speakers at the WordCamp Buffalo site. Here's a handy map:
On Friday, May 17 I had the pleasure of speaking for the first time at Stir Trek, a one-day conference in Columbus, Ohio, that drew over 1,200 attendees (and I understand sold out in just a few minutes). Apparently the name is a reference to the MIX developer conference, for which they were unable to obtain license to use a variation on the name.
I also had the pleasure of presenting for the first time on best practices for making your web site printable, built from my own professional experience, my PrintShame site, and an article I wrote for .net Magazine, among other resources (also linked in the presentation).
With 40 great speakers across 8 different tracks, there was quite a lot on offer throughout the day. Considering the other presentations held at the same time as mine, I was thrilled to get any audience and more excited to see that those who attended saw value in the topic and asked great questions throughout.
Well after the talk I got even more questions and feedback on the session, which I truly appreciated. Since there is no official survey for attendees to give feedback on a speaker, I am hoping any attendees will feel comfortable tweeting about it or leaving a comment here. So far I have gotten one great bit of feedback on Twitter:
Lest anyone think I'm just terminally negative, @aardrian had a REALLY GOOD talk on accessibility. And printability.
(I worked in some accessibility tips during my presentation.)
All other feedback is welcome (including if I was loud enough when the lavalier microphone failed).
While in Columbus I also had the pleasure of having a nice dinner (I arrived too late to make the speaker dinner), visiting the North Market, and, as part of the conference, getting to see a double feature of Iron Man 3 and Star Trek: Into Darkness. All around a good time which I look forward to repeating next year.
As of today I am an author over at Web Standards Sherpa. I wrote an article discussing the process of juggling a no-budget, tight-timeframe web site for Buffalo Soccer Club while still trying to adhere to best practices. The article is titled "Balancing Act: Features, Budgets & Timelines."
I get a chance to talk about responsive design and even rant just a little bit about print styles (the article itself prints well, too). The article also has the nifty ReadSpeaker feature which means that the page can read the article aloud to you in a voice that is entirely unlike mine (at least it's a male voice by default).
Adrian offers insight into the decision process of building a new site for the Buffalo Soccer Club, a not-for-profit with little to no budget and a looming deadline.Read it…
A few months ago I had the pleasure of writing a piece for .net Magazine about print styles (Make your website printable with CSS). It was posted to .net's web site last month and received an overwhelming one comment. That comment, however, summed up something I hear all the time:
Would be interesting to see some statistics on how many people actually print websites.
For years I have argued that the best user statistics are those for the site you are building. In the absence of global numbers for how many users print web pages, in this post I'm going to show you how you can measure how many (and which) pages get printed from your site by using Google Analytics. I am also hoping those who know everything about Analytics can answer some of my questions.
The Concept
While looking around for existing solutions to track printed pages, I found this article: Use Google Analytics to Track When People Print your Web Pages (written exactly one year before I got my own code working). While there doesn't appear to be anything wrong with this approach (I did not try it), how it both produces the tracking code (JavaScript) and presents the data in Analytics (different than how I report on custom events), doesn't match my preferred approach.
I want to be able to call the Google Analytics tracking image (__utm.gif) only when the page is going to be printed, skipping unnecessary HTTP calls and the resulting image download (brief though it is). I rely on the CSS @media print declaration to call the image. I also don't want to write that image call to the page with yet more client-side script when I can assemble it all right on the server.
Since my post Calling QR in Print CSS Only When Needed already outlines the general flow (presuming I only want to support Internet Explorer 8 and greater), I can lean on the CSS syntax there.
To reiterate this technique will not work in versions of Internet Explorer 7 and earlier.
Constructing the Query String
I had a heck of a time finding information on how the Analytics query string needs to be constructed, and when I did find information it didn't always explain the values in much detail.
Google's developer site has information on all the query string parameters for the GIF request, but no information on what is required or what all the possible values might be. I did find a list of what may be the required parameters while searching among a thread on tracking emails with Analytics. Through a good deal of experimentation I came up with the following minimum list for my purpose:
Variable
Description
utmac
Account String. Appears on all requests. This is your UA-#######-# ID.
utmwv
Tracking code version. While my standard GA requests use 5.4.0, I opted to use 4.3 for reasons I no longer recall.
utmn
Unique ID generated for each GIF request to prevent caching of the GIF image. I just concatenate the current year, month, day, hour, minute and second.
utmhn
Host Name of your site, which is a URL-encoded string.
utmr
Referral, complete URL. In this case I just insert a dash so it is not blank.
utmp
Page request of the current page.
utmt
Indicates the type of request, which is one of: event, transaction, item, or a custom variable. If you leave it blank, it defaults to page. Because I am tracking events, I use event.
utme
Extensible parameter. This is where you write your event. I use 5(Print*{page address}). See below for why.
utmcc
Cookie values. This request parameter sends all the cookies requested from the page. It can get pretty long. It must be URL encoded. It must include __utma and __utmz values.
Because the whole point of this is exercise is to track the event in Google Analytics, it was important to understand how to construct the event for the query string. I struggled a bit.
Lazyweb: Can anyone point me to a reference that explains the "5" in Google Analytics query string event params? eg: utme:5(Print)(/Engage)
I still haven't figured out what the number 5 maps to, but it works. I also found that I need an asterisk as a separator, though I found no documentation explaining it. In the end, the only way a print event tracked as I wanted was when I constructed it as: 5(Print*/Accessibility). In this example, /Accessibility is the address of the page I am tracking.
The other tricky bit is pulling the cookie value and stuffing it into the string. Conveniently I can get to this within our content management system (QuantumCMS, which you should use) on the server side. Many others (if not most or all) have a similar ability. At the very least you have to include the __utma and __utmz values, passed as encoded parameters for utmcc. Without these, my tracking would not fire.
The Completed Query String
For ease of reading, I will break the string to a new line at each &. This represents what is generated when I visit the careers page on the Algonquin Studios site using Opera.
Now that you have the query string and the Google Analytics tracking image, you just need to call the image when the page is printed. All you need to do is embed a style block at the top of your page with the print media query, and call the image within it:
If you read my post on embedding QR codes, then this code will be familiar — I use header::before in that example. As such, I use header::after here so you can use them both keyed off the same element (header) without conflict.
If you look closely, you may have noticed that my event parameter looks like 5%28Print*/Engage/Careers%29 instead of 5(Print*/Accessibility). I URL encoded the parentheses on the entire string to make certain that they do not conflict with the parentheses in the CSS. If you don't do that, the browser will get confused and fail to load the image.
Once you have the CSS in place, I recommend going into HTTP Fox or the Chrome Developer Tools to make sure the image is called when you fire a print preview (save paper!), and then to make sure it has the parameters you expect — particularly the utme value:
Screen shot of Chrome Dev Tools showing the query string parameters for the tracking GIF.
Checking Your Google Analytics Report
Assuming you've verified all is working well, you just need to run a report for events in Google Analytics. Bear in mind that Analytics isn't up-to-the-minute, so you may need to give it some time to capture all the data.
Log into your Analytics account and make sure you set the report date to the time period where you rolled out these changes. Choose "Content" from the "Standard Reports" on the left side. From there, expand "Events" and then select "Top Events." You should see "Print" as one of the items in the "Event Category" column (you may need to show more rows).
After you click "Top Events," you will see all of the events you are tracking (if any other).
Click on the word "Print" in that grid and you will see all the pages that were tracked (ostensibly because you or a user printed the page).
The report is handy if you know the page addresses, but Analytics doesn't think of them as such. As a result, clicking the addresses will not take you to the page.
From here you can run a secondary dimension to cross-reference this with more information. In my example, I tested different pages in different browsers so I could quickly verify the cross-browser support. You can run screen resolution, landing page, or any other dimension that you think might be handy to compare.
An example comparing the printed pages with the browser as a secondary dimension of the report.
Conclusion
I am just adding this to my own site, so I don't have any numbers to offer as part of this post. However, if you implement this please feel free to let me (and everyone) know how many users you have who print and for what site. I don't expect the numbers to be high, but I do expect to see it happen here and there.
If you have any additions, corrections or suggestions, please let me know. I am still unclear how all the Google Analytics query string parameters come together and exactly what they all mean, so there may be some optimizations I can work into it.
For those of us who put together print styles for our sites, we've probably tossed around the idea of embedding QR codes so that users can quickly get back to a page they have printed. In the hardcopy version of my article for .net Magazine, "Make your website printable with CSS," I show how you can embed QR codes in your page (it's not included in the online version).
In my example I use the Google Charts API to generate the QR code on the fly. The problem in my example is that the QR code image gets called whether or not you print the page. Not only is this an additional HTTP request, it's also an additional download that immediately gets hidden. This puts a bandwidth burden on users who aren't printing, but it's also the only way to support your users on Internet Explorer 8 and below (who may be the ones trapped at the office who want to bring the document home).
If you truly have no IE8 or below users, then the less bandwidth-hoggy approach is rather simple, if a bit inelegant.
Since each call to the Google Charts API to get the QR code must include the full address of the page, I cannot leave this to my linked CSS file (which is static, not run through any server-side processing), nor would I want to push every URL for every page of my site into that file. Initially I wanted to use a data- attribute to hold the URL and then, using the generated content feature of CSS, have it take that value and feed it into the content: CSS declaration to have it generate the image from there. Except that's not how CSS works. You cannot use CSS to generate an image from a CSS variable.
The easiest solution is to a put a style block at the top of your page (something I hate doing) and feed the current page's URL into the Google Chart API query string to dynamically draw the image. The rest of the styles that affect placement, spacing, etc. should all be in your print stylesheet already. The example:
That's it. Now when (and only when) you call the print styles, the image will load. As proof, here is a screen shot using HTTPFox showing the page before the print styles were called and after, where you can clearly see the QR code is called only when the print styles are fired.
Screen shots of the list of HTTP requests before and after the print styles were fired. You can click / tap to see the full-size image.Screen shot of the print preview with the generated QR code in place.
Note: This technique will not work in any version of Internet Explorer that doesn't support CSS generated content, which includes IE 8 and below. Internet Explorer 9 and above happily include the QR code generated with this method.
Update: March 26, 2013
I build on this technique to show you how you can use Google Analytics to track which and when pages of your site are printed: Tracking When Users Print Pages.
The Summer 2012 (#231) issue of .net Magazine has my tutorial on making print styles for your site. Not only did I get four pages, the article got a mention on the front cover (small though it is) and my photo in the contributors section.
If you've spent much time here or following me on Twitter, then you know I have written plenty about the lack of print styles on modern sites, particularly those claiming to use responsive techniques. I figured it was about time I showed some techniques to make it happen and hopefully demonstrate how dreadfully simple print styles are to do.
While my article is clearly the stand-out piece in the magazine, and totally worth getting just for my work, there is some other stuff in this issue that might interest you:
Creating flexible layouts that will work on any device and any screen size is the next big challenge for CSS. In this month's issue Peter Gasston takes us on a tour of some well-implemented properties you can use now as well as the exciting proposed properties we could be using in the future.
There's also a guide to creating or updating your online portfolio from Gary Marshall, an interview with Elliot Jay Stocks and tutorials on HTML5's Drag and Drop API and building a basic responsive site with CSS. Here are some more highlights:
Build smoother JavaScript apps
Make your website printable
Make your sites load faster
The pro's guide to Adobe Edge
Build an ecommerce store
Using PHP Data Objects
By the way, in case you want to read up on some of my prior discussions about print styles, here's a handy list of links for you:
After Net Magazine was subsumed by Creative Bloq, all the addresses for old articles were broken (once the articles were finally added). I have fixed the links above to reflect the new addresses.
For many years I've pushed for print styles for sites. It's an easy step to take in the course of developing a site, easy to test, and the techniques to do it have been around for over a decade. Something as rigid as a tabled layout could be relatively easily wrangled into a print-friendly document — without breaking any budgets.
With all the excitement over supporting mobile devices, web developers have been adopting the concept of responsive web design (RWD), which allows your layouts to scale and reflow based on the device and browser size the visitor is using. Yet somehow the gee-whiz factor of these techniques has not helped the printed page, particularly on web sites that are often regarded as great examples of RWD.
This weekend I was looking at sample sites that either proudly proclaim their RWD heritage, or which are held up by others as great examples of RWD. Having already been burned by sites that take a dozen pages to print one tiny piece of content I started testing their print styles and found that, for the most part, they had none. I decided that perhaps the only way to get anyone to address this was to use shame.
I registered PrintShame.com, made a new Blogger site (the same platform my personal blog uses), and got to work gathering the printed output of sites as PDF files to share with everyone.
I am only grabbing sites that claim to be the result of RWD and for now I am pulling URLs from Media Queries, a site that gathers examples of responsive design. The collection of sites can be ordered by popularity and so that's how I've started. I am excluding some that aren't fully built (though I have no idea why they are listed and ranked so well), but for the most part I am just grabbing what's there. I will probably also grab other sites that folks recommend, as I did in one of the posts I link below.
The process is quite simple: I capture a screen shot of the site in my 1,024 x 1,024 Firefox window with all my normal chrome. I also print the page to PDF. Usually I use the home page, but sometimes it's not appropriate and so I grab a contact page, an article, a product page, or even an event schedule. Then I post the screen shot and the PDF to Print Shame with a link to the original page.
Sometimes the printed pages are abysmal, and sometimes they aren't so bad. I am only posting them if there is something that I find poorly done. This ranges from excessive number of pages to failure to include the brand on the printed page. I am also posting without comment. I figure if a site owner sees his or her site there and thinks that the print output looks good, then that site owner probably needs to redefine his or her goals with the site.
You may note that Print Shame doesn't have print styles. That's a function of using Blogger. I don't really care to make a full RWD site with print templates and the like when it's far faster to just do fly-by postings in my otherwise busy life. Poorly-built sites without print styles have already taken enough of my time.
With this site I hope to demonstrate how some of these well-regarded responsive sites and show how they fall short in the most basic ways. Perhaps this is the only way to get site owners to pay attention.
Readers of this blog know of my regular frustration with web sites that don't have print styles. Part of this is fueled by all the lip service supposed responsive web developers pay to adapting to different screen sizes, but who fail to consider the printed page when we've had support for over a decade now.
Yesterday I stumbled across the site PrintFriendly. It promises to remove "Ads, Navigation and web page junk" (odd capitalization theirs). It positions itself as a way to save paper and ink and offers both a button for your browser toolbar to clean up sites like CNN when you print them, and a button for your own site to allow users to print your content. It can also output PDF documents if you don't want to print to paper.
For End Users
As someone who frequents sites that don't print well, I can tell you that this service can be handy. For the CNN page I tested (PDF of page fed through PrintFriendly) — which is linked off the PrintFriendly home page as an example — it clears out the banner imagery, advertisements, navigation, and lots of other cruft. It also removes the branding and turns the links in the page to light gray, making them a bit hard to see. As someone who has chosen to print a page from CNN, I know where it came from, but I can't quite forgive the too-light links.
I may use it for those rare times I need to print an article from a major site that doesn't provide any print options at all. It can come in handy.
For Businesses/Organizations
PrintFriendly gives you the option to add its print button to your web site. This is geared to web site owners who don't have print friendly pages as well as blog owners who have no control over print styles (or lack thereof).
That there are organizations out there that consider this a viable option at all is absurd. Let me explain why…
When I use the feature to print a page, I am given the option to remove imagery and any other element on the page. I can remove entire paragraphs of content from the printed page of a site I do not control. In addition, my footer is removed, which means if my contact information was there (phone, mailing address), it's gone now. The footer is also where I keep my copyright statement and some additional branding, which are both lost as a result.
Users may have a valid reason to remove elements of your content, usually to fit on a page, but what about users who may just want to print cherry-picked content to push an agenda? Are you also willing to let whatever content sits in your footer be purged? Someone motivated by your content while reading from paper is already offline, and a phone number or address is that much more valuable to display.
Advertisements Presented to Users
After printing I am presented with a box of advertisements. I saw ads for used tennis machines, metal forming machines, ultrasonic cleaners, and one large graphic ad for vending machines. None of these compete with what I offer in any way. They don't appear to be keyed off my content, but I cannot be certain.
If you sell a service or a product, are you willing to take the risk that users to your site, when printing a page, may be offered advertisements for your competition? Will those users understand that you don't endorse those services or products even if they aren't competition? Are you willing to take that risk?
Loss of Branding
The first thing I noticed on the printed pages I tried was that the branding was typically removed. Seemingly whatever lives at the top of the page, which probably contains your logo, tagline, and perhaps other important details, is removed. Even my site was affected, and I use text for my "logo" and tagline.
Considering how much effort (time and money) you may have spent in tweaking your brand and message for your site, are you comfortable having it summarily removed from every printed page? When the end user passes this printed page along to another, do you feel you are losing an opportunity to present your brand to the next reader?
Page Reformatting
There are elements of copy or imagery that are intentionally positioned in my content to draw visual connections. For non-visual users I make sure it linearizes (that's how it starts). But since the printed page is a visual medium, I often rely on the ability to continue to maintain those visual relationships. Those are discarded in the PrintFriendly version of the page.
If you have sidebars, pull-quotes, or other elements that are distinct from the main content and may be confusing to users not used to seeing content linearized (which are nearly all sighted users), then you may find reading comprehension suffers. It will take some effort to identify all the elements of content on your site and test how they behave in this model.
Find a New Web Developer
Any current web developer who cannot or will not create print styles for your site is probably not someone you want to use anymore. Even if your web developer isn't up on the new hotness of responsive web design techniques, that's not an excuse. Print styles pre-date nearly everything going on with the web now. Print styles work with tabled layouts, with ads, with all sorts of elements on your page. There is no good excuse not to include them in any web site built within the last 10 years.
If your web developer recommends PrintFriendly, make sure you understand why. If the answer is couched in lack of technical ability to develop print styles or just laziness, the decision should be pretty easy.
Today my second article at Web Standards Sherpa has been posted, 
I have alluded to this point in the past. Usually when I get off on a rant about print styles, I lump it into the overall process of making responsive sites and I use media query formatting in my examples. But I haven't just flat-out said that print styles are media queries.
For those of us who put together print styles for our sites, we've probably tossed around the idea of embedding QR codes so that users can quickly get back to a page they have printed. In the hardcopy version of my article for .net Magazine, "
Readers of this blog know of my regular frustration with web sites that don't have print styles. Part of this is fueled by all the lip service supposed responsive web developers pay to adapting to different screen sizes, but who fail to consider the printed page when we've had support for over a decade now.
