Marketing with QR Codes

Two weeks from today, I’ll be representing Algonquin Studios at the Legal Marketing Association’s annual conference. This year, in addition to exhibiting at the conference, Algonquin is participating as the official QR Code Sponsor and we’ve created what we think is a pretty cool and engaging interactive experience for conference attendees to participate in.

One component of this experience is a series of educational pieces about the use of QR codes in marketing but, since most readers of this blog won’t get to experience presentation we’ve developed for the LMA attendees, I thought I’d share some of the topics the presentation covers here:

Are QR Codes a Good Fit for Your Business?

Probably; they’re easily adaptable to many industries. Provided your clientele is comfortable with smartphone usage and wants to engage with you on an “outside the box” level, adding QR codes to your marketing campaigns is an easy way to boost visibility and reach. Just remember to stay focused on using codes in ways that provide your visitors with value and they’ll likely become a great addition to your overall advertising and brand awareness outreach.

How Can You Use Them?

Arguably the best thing about a QR code, from a marketing standpoint, is their wide range of applications. You can create codes that lead to information about your company, employees, products and more:

  • Employee bio pages or vCards
  • Event dates and registrations
  • Special offers and discounts
  • Social media profiles (Facebook, LinkedIn, Twitter)
  • How-to/Instructional videos
  • Product reviews/comparisons
  • Shopping cart pre-population
  • Phone numbers

And codes can be used on all sorts of company collateral:

  • Business cards
  • Signage
  • Trade show materials
  • Sales brochures / Leave-behinds
  • Corporate apparel
  • Product labels

Why Should You Use Them?

Because QR codes can help you go beyond your traditional marketing and advertising efforts. You can include audio and video elements, create a series of codes that take people on an educational journey, as we’ll be doing at LMA, or help your message reach a broader segment of the population.

QR codes also make it easy to collect information. You can track when and where codes are scanned and identify repeat visitors. You can also create codes that lead to forms asking for contact info like phone numbers or email addresses.

Things to Remember When Using QR Codes:

First and foremost, remember that codes are most effective when used on printed collateral. We’ve seen people use them on web pages, but this makes little sense since the point of most codes is to direct you to the internet. We’ve also seen them used in emails but, since people read emails on their computer or mobile device, this is also an odd choice. Scanning a code would either be really silly (think about holding your phone up to your computer screen in order to scan a code that leads to information on your phone) or downright impossible (how do you use your phone’s camera to scan something on your phone’s screen?).

  • It’s also important to remember that your landing pages and content need to be mobile-friendly (i.e. navigable on a small screen). And, as mobile engagement is often on-the-go engagement, you’ll want to keep things short and sweet.
  • Think about if your viewer will have WIFI access. Sure, subway stations can seem like an ideal place for an ad – you’ve got a captive audience with nothing to do but wait for the next train; why wouldn’t they scan your code?  But, since many subway lines aren’t equipped with WIFI, you could literally paper the walls with your codes and people still wouldn’t be able to scan them and access your info.
  • Remember to keep your content updated. There’s nothing worse than scanning a code that leads to an out-of-date promotion, a registration page for an event that’s already taken place, or, worst of all, a non-existent page. Even if your code was originally intended to drive traffic to time-sensitive content, once it’s over, leave a landing page loaded with something interesting for code scanners who come late to the party.

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.

The Mobile Web

Author: Garret Hussak
February 15, 2012

If you’ve been listening to the word on the street, you’ve noticed…everyone’s talking mobile. We now expect that companies will provide us with access to their sites from mobile devices like smartphones and tablets, and developers are being called upon to create mobile sites and applications more and more often.

So, Why The Push For Mobile?

It’s simple – people are using mobile devices and the technology isn’t going away.

  • By one count, there are 5.3 billion mobile device subscribers in the world.
  • In the 4th quarter of 2012, manufacturers shipped more mobile devices (100.9 million) than PCs (92.1 million).
  • According to one source, mobile browsing has jumped almost 200% worldwide in the past year and is closing on 10% of total browsing.
  • It is estimated that by 2014, mobile browsing will surpass desktop browsing.

What To Consider?

While we can probably agree that mobile development is “where it’s at,” we need to remember, of course, that developing for mobile devices is it’s own animal, with both limitations and advantages that need to be taken into account:

  • Smaller screen size
  • Potentially slower connection speeds
  • Higher resolution displays
  • Access to the user’s location with GPS & other technologies
  • Access to the user’s camera
  • Access to the user’s contacts

How Do We Implement Mobile Functionality?

There are a variety of methods to reaching mobile users and catering to the benefits and limitations of mobile devices:

  • Mobile Applications – Apps are a great, often fun and engaging way to present content to people on the go. But it’s important to remember that apps are platform specific and can a long time to develop. You also need to take individual device capabilities into account when creating mobile apps.
  • Mobile Web Sites – Mobile versions of web sites that are either already in place or are being redesigned or developed from scratch are a perfect way to ensure visitors have the best possible experience when they access your site on their mobile devices. Mobile sites come with some great advantages over applications, as well, since they don’t have to be platform specific (though they can be, if necessary) and usually have a faster development time. Device capabilities also aren’t the issue they can be when developing apps.

Finally, Let’s Talk About Some Of The Technological Hurdles Involved In Mobile Development

As I mentioned earlier, mobile development is its own animal and we have to keep a few important practicalities in mind when we think about a mobile project:

  • The “old-school” idea that tables can be used for layout simply won’t fly on mobile devices. In a mobile environment, elements need to be able to stack as opposed to live side-by-side as in a desktop element.
  • Fixed widths won’t work. A 450px element might fit great on a desktop version of a site, but on most mobile devices that will have be switched to a fluid width.
  • Different users will see things (slightly) differently. Each device can have a different display resolution, aspect ratio, and browser.
  • Flash is dead slow and dying. Content previously presented using Flash should now be displayed using one of many mobile friendly technologies.

HTML5 Will Play Nice with Translation

This is an update to a note originally posted on my blog on January 17. As of yesterday (February 7, 2012), this new attribute is officially part of the HTML5 specification. If you are interested you can read the part of the bug report where this change was accepted.

HTML5 Logo with character for Chinese number 5.Back in late 2009 I wrote a little something talking about Google Translate and the risks associated with relying on machine translation for anything critical (“Facebook and Google Want to Translate Your Site“). I even offered some examples of things that are tough to translate.

One real-world example I did not list was when I used machine translation to process a page with someone’s name. The first name we’ll say was “Bill,” but the last name was definitely “Belt.” Somehow instead of “Bill Belt” being retained as his name throughout the article, he was renamed to “Bill of Leather Strap.”

This particular example is one step closer to being a thing of the past. In the latest W3C Open Web Platform Weekly Summary, a new attribute has been announced for HTML5 that will allow authors to exclude specific content from being translated — for any service that will honor it. The announcement:

A global translate attribute will be added to HTML5. The values are yes or no with the same inheritance policy than the lang attribute. The goal is to specify if a piece of text should or not should not be translated automatically.

Of course, if I want to exclude Bill Belt from being translated, I’ll probably have to wrap his name in a span in order to throw a translate="no" in there since I doubt I’ll have an otherwise semantic or structural element in place already. This does, however, offer a far better solution than the previous suggestion of using a class to achieve the same effect.

To be fair, Google Translate already has its own support for excluding content from automatic translation, specifically using class="notranslate". Head over to the Google Translate Help page and expand the bottom-most option, “General information for webmasters” (nice to see they make it easy for a direct link).

If you are curious about the process this went through to become a change for HTML5, you can see the bug report that started it all back on April 4, 2011: Bug 12417 – HTML5 is missing attribute for specifying translatability of content.

I don’t believe that machine translation is ever a good way to translate or localize content for anything more than casual use. For example, legal matters, healthcare, and things like that are poor candidates for machine translation (I have far more to say on this point in the post linked above). For organizations that do provide manual human translation, this attribute can be a boon to them as well, allowing them to understand pieces of content that do not need to be processed, saving time, effort and cost to everyone in the translation workflow.

As developers it’s our responsibility to make sure it is used correctly, most likely by helping to train content authors.

No DHTML, Please

Originally Posted by Adrian Roselli on January 25, 2012, on his blog.

HTML5 logo mocked up as DHTML logo.The trend continues where I speak to clients, vendors, young developers fresh out of college, and even the teachers/professors who instruct them and they don’t understand that HTML5 and CSS3 aren’t the same specification. I have repeatedly shown an HTML 4.01 site with CSS3 to explain that they are each distinct specifications which can be applied in different combinations of different versions. This is further complicated when JavaScript is folded into the mix — some folks even think jQuery is part of the HTML5 specification.

I am repeating a request that when we who know better (developers, tech writers, robots named Frank) speak about discrete specifications, we refer to them as such.

When I talk to another developer about a feature, I want to know that when one of us says “HTML5” we are both talking about that particular specification. When we use terms like “WOFF” or “WebGL” I have comfort knowing the developer has a particular set of technical standards in mind, but when one of us says “HTML5” we each have to pause to consider what related specification the other might actually mean.

It seems fair to raise what sounds like a semantic point when we are discussing a specification that is all about encoding content in semantic and structural elements. I don’t think I should let this go, otherwise it feels like I have failed the semantic goal of HTML right at the outset.

What Motivated the Mini-Rant

Another free and fantastical service was released to the web development community on Tuesday, HTML5 Please. The same folks who also brought us sites like HTML5 Boilerplate, Modernizr and CSS3 Please are the fine team behind this resource. And this is part of the reason why I am so frustrated. Each of them knows the difference between HTML, CSS, and unrelated specifications like WOFF, SVG, Geolocation, WebGL, and so on.

In a (Google-doc-brokered) conversation with Ian Devlin (author of HTML5 Multimedia: Develop and Design), Paul Irish (one of the folks behind HTML5 Please) agreed to add a disclaimer to the site for the chronically unlikely-to-read-any-specifications-or-bother-to-know-the-differences-among-them. Mr. Irish made short work of it, too:

While named HTML5 Please, this site discusses features beyond the HTML5 specification, coming from CSS, SVG, and the greater Open Web Platform umbrella.

On Wednesday I went back to the site and noticed that the disclaimer was gone. I tweeted about it and was ultimately directed to a bug/issue report that provided justification for its removal:

[…] However, HTML5 represents an umbrella term for all new technologies (as is inferred from Also, the specification itself is now a living standard known as HTML and not HTML5.

Of course I was motivated to leave a comment:

I feel the ship has sailed when trying to communicate this point to the general public, tech writers, bosses, clients, and small children up the street. However, since the site is aimed at developers I think it does a disservice to not remind them that HTML5 means a very particular specification, and that it makes it easier in the future to cite new specifications that will be supported on the site (as they come up), but are otherwise distinct. For those who do know better (me, a couple folks above), it just looks like the site got it wrong and doesn’t understand the difference itself.

If we as technical professionals cede the meaning of HTML5 when speaking to other technical professionals, we are falling prey to marketing speak that has no place in discussions about specific technical matters.

That’s it, that’s the background. I’ve explained my thoughts on this before and am concerned that HTML5 has become a distilled marketing term that, unlike DHTML and Web 2.0, neither of which shared the exact same name as the version of a technical specification, only leads to confusion when developers are interacting with marketers, bosses, clients and vendors.

You may read previous variations on this rant here:

Directly Engage Your Tech Partner To Avoid “Used Car Sales” Experience

Originally posted by Algonquin Studios CEO, Steven Raines, on January 29, 2012, on his blog.

The Internet has brought the worlds of marketing and technology together and customers expect their advertising agencies to be able to provide full service solutions on the web and social media. These solutions often include integration with internal systems and data that fall outside the core competences of the agency, who aren’t able to support the technology staff to provide these services on-demand and seek external partners to provide software solutions. Unfortunately, many companies feel that having an outside vendor provide technology solutions puts them at a disadvantage in the eyes of clients (and prospects) and try to funnel all communication through the agency and prevent the technology partner from directly interacting with the client.

I have written previously about the fundamental differences between solving technical and creative problems and this kind of collaborative solution demands both. Advertising and marketing firms are oriented to solve creative problems, but account executives often lack the training to perform the critical analysis necessary to define the requirements necessary for software development. When the agency buffers the tech provider from the end client, AEs aren’t able to provide feedback on how (and if) an objective can be accomplished or give “ballpark” pricing on items that come up during brainstorming. This means that every discussion requires the agency to go back to the software provider. I liken this to the “I have to ask my manager…” experience of buying a car. Is there any sales experience more frustrating as a consumer? This breeds distrust between the client and the AE – exactly the experience the agency was trying to avoid by keeping the solution provider away from the client. We have a saying at Algonquin Studios: “You will do what you fear most” and this is a perfect example. The things you fear drive your actions and inevitably it back fires. Like getting caught in a lie, the best way to avoid it is to tell the truth from the start. Face your fears honestly… problems delayed are problems expanded.

Advertising and marketing agencies need to educate their clients that technology providers are like the other traditional vendors (printers and media companies) they outsource to because they offer specialized services better suited to an organization designed around those competencies. Similarly, software vendors need to educate their agency customers about the added value they can bring when they are at the table with the customer.

Finally, if you are an agency that is afraid you will be cut out of business by your technology partner, get a new partner.