Archives

Home » Blog

Calling QR in Print CSS Only When Needed

This post originally appeared on my blog on March 8, 2013.


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:

@media print {
  header::before
    { content: url(http://chart.apis.google.com/chart?chs=120x120&cht=qr&chl=http%3A%2F%2Falgonquinstudios.com/Engage/Careers); }
}

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.

Letting Mobile Users See Desktop View of RWD Site

Originally posted on my blog on January 11, 2013.

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it’s enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the “desktop” version of a site from a menu built into the browser.

Except that feature doesn’t work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn’t do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we’re kind of stuck. While I have many ideas on how that might work, that won’t address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

  1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
  2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
  3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the “desktop” CSS.
  4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
  5. Now display a link to view the “mobile” version of the site. Again, this can be done with or without script.
  6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by “desktop” or even “mobile.” You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don’t clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.
CHSBuffalo_iPhone_desktop CHSBuffalo_Nexus7_desktop

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking “View desktop layout” (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.
CHSBuffalo_iPhone_desktop_oops

This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don’t make the same mistake if you try this.

Related

Accessibility Bookmarklets and Tools

This post originally appeared on my blog.

Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even cognitive impairment. Having resources in the community is important as is tracking down the same tools in use in that community.

Despite all this it’s nice to have some quick techniques for testing your sites without the need to break from your regular workflow. Conveniently, there are a number of tools already out there. Here is a quick rundown…

WCAG 2.0 parsing error bookmarklet

From Steve Faulkner, this experimental bookmarklet uses string matching to evaluate a page against the WCAG 2.0 success criterion for section 4.1.1 Parsing. It leans on the W3C Nu Markup Validator to do its job.

Get the WCAG 2.0 parsing error bookmarklet from The Paciello Group for yourself and while there, read up on how to use it.

Nu Markup Validation Service Bookmarklets

Excuses for failing to use the W3C Nu Markup Validator fall away when all you have to do to validate a page is click on a bookmarklet. Also from Steve Faulkner, this collection of four bookmarklets allows you to validate the current page (in the current window or a new one) or provide the URL of a page to validate (in a new window or not).

Get the four Nu Markup Validation Service bookmarklets (also from The Paciello Group).

Favelets for Checking Web Accessibility

Jim Thatcher has come up with a series of bookmarklets (or as he calls them, favelets) that allow him to make the human review process easier by highlighting details he might otherwise have to wade through code to see. Bookmarklets include image checkers, heading counters, data table notes, ARIA details, and form features.

Get the full collection of “favelets” for checking web accessibility and be sure to read the detailed instructions on how to use these in conjunction with a manual testing process.

Web Accessibility Toolbar

This particular tool is not a collection of bookmarklets. It is also not built to work for any browser other than Internet Explorer. It does, however, provide far more features than bookmarklets can do on their own. Used in conjunction with a manual test and the bookmarklets listed above it can help our overall accessibility testing process far more than just the bookmarklets alone.

Download the Web Accessibility Toolbar For IE and give it a test run on your sites.

If for some reason you are running Opera 8 or Opera 9, there is a version of the Web Accessibility Toolbar for Opera (but again, only 8 or 9).

Juicy Studio Accessibility Toolbar

This toolbar is a Firefox add-on from Gez Lemon. Like the toolbar above, it provides a bit more control than a bookmarklet will afford. This will show you ARIA live regions, show you ARIA landmarks and roles, provides a table inspector and a color contrast analyzer.

You can get the Juicy Studio Accessibility Toolbar from the Mozilla add-on site.

NonVisual Desktop Access (NVDA)

Since I’ve strayed far afield of bookmarklets I thought I would toss this last one into the mix. NonVisual Desktop Access (NVDA) is a free, open-source screen reader for Windows. While it’s intended for the entire OS, it’s also great for testing web pages. Its support of different accents makes for much fun when it speaks to me as a Scotsman.

Download a copy of NVDA for yourself and make sure to donate when you do — this is how projects like this are able to continue and how you can support the disabled community.

Somewhat Related on My Blog

Ongoing Misunderstanding of Flash and HTML5

This post originally appeared on my blog on Saturday, March 3, 2012.

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, “What the Demise of Flash Means for the User Experience.” To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe’s decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe’s decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn’t anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it’s fair to challenge the claim that HTML5 creates “ubiquitous user experiences regardless of device” when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It’s also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let’s not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of “graceful degradation” and “progressive enhancement.”

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author’s math doesn’t bear out the assertion — by the author’s numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author’s word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5′s doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn’t tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn’t need to change. The user shouldn’t need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don’t know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn’t do anything to advance HTML5 and its related specifications.

I’d love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Comparing Mobile vs. Desktop Data for Improved Experience

Mobile web sites and web pages are all the rage and it’s no wonder, with sales of mobile devices soaring (Gartner). So, maybe you’re considering a mobile version of your own site, but you want to be smart about it, doing what’s best for your site based on what makes good sense for your business. Thankfully, web analytics is here to the save the day! Analytics = super exciting, right? Well, bear with me here.

Start by accessing your Google Analytics account (if you don’t have Google Analytics installed on your web site, check it out to learn more about the insights and information the service can help you gather about your site).

You’ll want to set your date range for the past 12 months and go to the Mobile Overview section* (Click images for larger screen shots):

Mobile Data Overview

This report will show the percentage of visitors came to your site from mobile devices during the past year. If it’s a decent piece of the pie chart, usually 10% or more, the data is telling you it would probably be smart to invest in the development of a mobile site.

Click one level down to Devices and you’ll see which mobile devices are the biggest drivers to your site. It’s important to note if Apple devices are at the top of ­the list as Flash won’t work on these devices (and probably never will). You’ll want to keep this in mind and consider an alternative to Flash when designing your mobile site.

Now, let’s dig a little deeper. What kinds of content are your mobile visitors viewing most often (Content>Site Content>Pages)? Does it differ from desktop users? If so, those answers can point you to better ways to organize your content for a mobile site design.

Here’s how: Hop down to the Content section, click on Pages, and bust out some Advanced Segments. Under the defaults, you’ll automatically have a Mobile Traffic option at your fingertips. This report will give you insight on what the most viewed content from your mobile visitors is. Is this same content at the top of your mobile site design or extremely easy to access on a mobile device? It should be.

You could just compare “Mobile Traffic” to “All Visits” but let’s be more awesome.

Create a quick and simple “Custom Segment” for Desktop Visitors.

Click “+ New Custom Segment” > Name itDesktop Visits” >Select “Include Mobile Exactly Matching No” > Test then Save your segment. You’ll know you did it right if your Mobile Traffic and Desktop Visits add up to All Visits.

Creating Desktop Visits Custom Segment

Now, you can start comparing differences between your mobile and desktop site visitors. Just select the “Mobile Traffic” advanced segment and your new “Desktop Visitors” custom segment, hit apply, and check out the differences. For example, on our own site I found mobile visitors spend way more time on our Web Design and Careers pages than a typical desktop visitor.

Mobile vs Desktop Visitor Data

If you don’t see a lot of differences between the way mobile and desktop user visit and interact with your site, simply creating a more mobile-friendly version of your current site is probably a valid option and should work perfectly for the vast majority of your mobile visitors. On the other hand, if there are big differences between the two kinds of interaction, you may want to consider a new design for your mobile site, pushing the most important content for mobile visitors to the top or highlighting it to make it more easily accessible via mobile devices.

If you’re an analytics user, have you tried any of these reporting options and checked out your metrics? Did you find anything interesting? I’d love to hear about it.

*All data shown is anonymous and is not reflective of our clients’ accounts.

Flash is Dead! Long Live Flash!


A lot of news has been made of Adobe’s recent move to end development of the Flash player for mobile devices (such as your smartphone or tablet). Even people outside of the tech community have heard about it and are trying to understand what it really means. I wrote up the details last month (Flash Isn’t Going Away, Except from Your Mobile) and tried to remind everyone that Adobe isn’t giving up on Flash, it’s just changing its direction on its mobile player based on industry trends.

Consider that Apple won’t allow the Flash player on its iOS devices, and that the mobile version of Windows is following suit. Consider that web developers are (finally, after a decade now) starting to focus on standards-based web development and accessibility. Consider how many different mobile devices and browser combinations exist, requiring Adobe to develop a Flash player for each.

Much of Flash on the web has been used to deliver rich multimedia experiences that either don’t translate well to mobile browsers (giant file sizes, areas too small to “click” with a finger, optimized for large displays, etc.) or can be replaced with new HTML capabilities which mobile browsers tend to support now without the Flash player (such as the lowly Flash video player).

Add all these factors together and it doesn’t make sense to push the Flash player to mobile devices any more. Adobe is instead using AIR to allow Flash developers to build native apps on the phone, bypassing the hassle of the browser plug-in altogether and still allowing those legions of Flash developers to do what they do best.

Here’s where people get confused — Flash as a platform isn’t going away. Regardless of the hype you hear about HTML5, HTML5 (including CSS3, SVG, and so on) just doesn’t have the capability (whether via the specification or by browser support) to do what Flash does. Flash is the only technology that can currently do what Flash does for such a broad audience. Its ubiquity across the web (98% installation) has guaranteed that users see what the developer wants, regardless of platform; regardless of whether or not what the developer created is any good.

This doesn’t mean we are Flash-crazy over here. Quite the opposite — we have historically counseled against Flash for web sites for many reasons, some of which are simply because it doesn’t address the goal. As we develop sites that are both mobile-friendly and desktop-friendly, we are increasingly coaching our clients on the right technologies to use to achieve their goals. Our position on Flash isn’t changing because of Adobe’s move, Adobe is simply reflecting the trend.

You can expect to see less Flash in web pages on your mobile, but you can also expect to see more of it behind the scenes in apps for mobile devices. As for your desktop browser, Adobe will release Flash players for years to come and people will still develop in it for as long as it takes HTML5 and its related specifications to finalize the rules and for the browsers to support them.

Good Design Starts With Good Content

A web site’s design should not dictate how content appears on the page. Rather, the content should dictate the design.

Successful designs arrange content in a manner that effectively engages users. This is particularly important on the home page, which is really a gateway to key areas of content. That means that the first step in the design process is to determine what content is most beneficial in achieving the goals of the web site.

Let’s use a legal web site as an example. In this case, the most important areas of content may include the following:

  • Practice history
  • News and articles
  • Attorney biographies
  • Practice areas
  • Client testimonials

Most of the time, a web site will have many objectives so it’s also important to assign priorities to the identified content pieces. These priorities will ultimately help determine how that content is arranged and presented to the user. For example, on our legal site, we might set the following priorities:

  1. Client testimonials
  2. Attorney biographies
  3. Practice areas
  4. News and articles
  5. Practice history

Now that we’ve defined the key areas of content and their priorities, we can quickly and efficiently determine the optimal arrangement of the page by building a wire frame. The wire frame for our legal site might look something like this:

Homepage Wireframe Example

As you can see, the wire frame has laid out the content on the home page according to their priorities. As the design process moves forward, the wire frame will be used as the underlying structure of the home page design.

Site Structure

In addition to shaping the home page design, the content should also dictate the site’s page structure. Since we’ve identified the key content areas of the site, we can begin outlining the page structure by creating a Site Map. A very basic Site Map might look something like this:

  • Attorneys
  • Practice Areas
  • Case Studies
  • Testimonials
  • News and Articles
  • About the Firm
  • Contact

These represent the top-level pages of the site and will be displayed as links in the Primary Navigation bar shown in the wire frame. These links will appear on every page and play a key role in establishing the usability of the web site. If the site structure is straightforward and well organized, then the site will likely be easy to navigate and generate a positive user experience.

Engaging the User

By following the processes outlined above, we should be well on our way to driving users to the key areas of the web site, but once they arrive at those pages, we must also continue to engage them in order to complete our goals, whether our goal for the page is to get users to click a button, fill out a form, make a phone call, or just read the content.

Writing genuine, engaging content is the first step, but there are also some simple things that we can do in displaying that content that will help us attain our objectives.

  • Make use of headings and lists. Web users tend to avoid large blocks of copy, but by using headings and lists where appropriate, the content is more inviting and optimized for skimming.
  • Make use of “call outs.” We can draw attention to important quotes or statements by emphasizing that text in some way.
  • Insert relevant imagery. Many users are drawn to visuals more than written words. Adding photos, graphs, maps, or other imagery can help draw users into the content.
  • User alternative media. Many users are more inclined to watch a video or listen to audio than read a lengthy article. When considering posting video or audio on our web site, it’s important that we understand our audience before making the decision as it may not always be appropriate. We should also keep in mind that, for accessibility purposes, transcripts should always be made available.
  • Highlight related content. If we have engaged users with our content, we may be able to engage them further by providing easy access to similar pages.
  • Include a “call to action.” If we are looking for users to do more than simply read the content, we should make it obvious by including a “call to action” that encourages users to complete an action that helps us to achieve the objectives of the web site. The “call to action” may be a link to the Contact form, a link to your Twitter feed, or just your phone number.
On the web, content is king and successful web sites are those that present content to users in an effective manner.

The Subjective Internet

Author: Steven Raines  10/19/2011

When we choose which web sites, blogs, and newspapers to read and which television stations to watch, we are knowingly filtering the information we receive. But what we may not realize is the the explosion of personalization on the internet is doing the same thing. But how personalized are things really? More than you may think. Recent peer reviewed research shows that Google will return search results that vary from user to user by up to 64% (First Monday.) Or consider the difference between stories that appear in the “Most Recent” view of Facebook’s news feed as opposed to what it determines is “Top News” for you?

In a past interview with New Scientist magazine, Eli Pariser – board president of MoveOn.org, says that Facebook and Google now act in the same fashion as editors… highly personalized editors that reinforce what we already believe and limit our exposure to new ideas. His new book The Filter Bubble addresses the concerns around these issues and offers tips for busting your own filter bubble.

- Eli Pariser: Beware Online ‘Filter Bubbles’ TED Talk

We Really Still Have to Debunk Bad SEO?

Author: Adrian Roselli  9/27/11

Image of bottle of SEO snake oil.I’ve been doing this web thing from the start (sort of — I did not have a NeXT machine and a guy named Tim in my living room) and I’ve watched how people have clamored to have their web sites discovered on the web. As the web grew and search engines emerged, people started trying new ways to get listed in these new automated directories, and so began the scourge of the Search Engine Optimization (SEO) peddler.

The web magazine .Net posted what to me is a surprising article this week (surprising in that I thought we all knew this stuff): The top 10 SEO myths. I am going to recap them here, although you should go to the article itself for more detail and the full list of reader comments. Remember, these are myths, which means they are not true.

  1. Satisfaction, guaranteed;
  2. A high Google PageRank = high ranking;
  3. Endorsed by Google;
  4. Meta tag keywords matter;
  5. Cheat your way to the top;
  6. Keywords? Cram ‘em in;
  7. Spending money on Google AdWords boosts your rankings;
  8. Land here;
  9. Set it and forget it;
  10. Rankings aren’t the only fruit.

The problem here is that for those of us who know better, this is a list that could easily be ten years old (with a couple obvious exceptions, like the reference to AdWords). For those who don’t know better or who haven’t had the experience, this might be new stuff. For our clients, this is almost always new stuff and SEO snake oil salesmen capitalize on that lack of knowledge to sell false promises and packs of lies. One of my colleagues recently had to pull one of our clients back from the brink and his ongoing frustration is evident in his own retelling:

I have a client who recently ended an SEO engagement with another firm because they wouldn’t explain how they executed their strategies. Their response to his inquiry was to ask for $6,000 / month, up from $2,000 / month for the same work in two new keywords.

This kind of thing happens all the time. I recently ran into another SEO “guru” selling his wares by promising to keep a site’s meta tags up-to-date through a monthly payment plan. When I explained that Google doesn’t use meta tags in ranking, his response was that I was wrong. When I pointed him to a two-year-old official Google video where a Google representative explains that meta tags are not used, his response was to state that he believed Google still uses them because he sees results from his work. My client was smart enough to end that engagement, but not all are.

Because I cannot protect my clients in person all the time, I have tried to write materials to educate them. For our content management system, QuantumCMS, I have posted tips for our clients, sometimes as a reaction to an SEO salesman sniffing around and sometimes to try to head that off. A couple examples:

Along with these client-facing tips I sometimes get frustrated enough to write posts like this, trying to remind people that SEO is not some magical rocket surgery and that those who claim it is should be ignored. I’ve picked a couple you may read if you are so inclined:

And because I still have to cite this meta tags video far far too often, I figured I’d just re-embed it here:

Related

My ire doesn’t stop at SEO self-proclaimed-gurus. I also think social media self-proclaimed-gurus are just the latest incarnation of that evil. Some examples: