In Defence of QR Codes
If QR codes aren’t being used effectively, it is more the fault of the publisher than the technology. The technology, despite its looks, is quite elegant and offers a lot of opportunity. However, there are some pretty significant barriers to adoption and use. So the burden is upon the publisher to use QR codes in the right context and provide a compelling reason to scan.
Some contexts are better than others. As this discussion illustrates, places where written language is not based on Basic Latin characters, like much of Asia, QR codes can be used to help users avoid quite a lot of mobile typing. The beauty of QR codes, a type of character encoding in their own right, is that they are universal. They are like high fidelity emotions; a lot of meaning packed into a small print expression. This universal characteristic is why I decided to use both together in the example below.
From a pure technological standpoint, QR codes offer quite a lot. They store up to several paragraphs of text or complete contact information, they can uniquely ID physical objects like NFC, and they can also trigger phones to send SMS messages, download apps and open web pages. (No wonder marketers are so eager to use them.)
The trigger to open webpages is a useful feature but publishers’ use of this trigger have fallen short of its potential. A smartphone’s web browser is much more than just a content browser. It is a interface to the blossoming world of Web 2.0 Web services. This is the unrealized potential of QR codes.
QR Codes as Application Interfaces
The technology, on the surface, is simple, it’s utility is elegant, and it’s recognition is universal. It is, in essence, just a medium but its capabilities are broad. We just have to think within the right application.
The Web is your Application
Most of us use our mobile Web browsers to request documents from Web servers (most often HTML web pages) or interact with Web apps. And that is traditionally what QR codes have been used for. But if we think of a mobile web browser beyond just a medium for viewing documents and more a means of sending HTTP requests, there is a lot of World Wide Web territory that opens up.
Beneath the document-based surface of the Web, there is a lot happening. There is a lot of data being passed around from place to place. Most often this happens as data is requested and sent from an API to dynamically update a web page (think of your favorite travel booking site) or connect one website or service to another (think of Twitter streams on web pages).
See what Web Services are available via IFTTT
These API’s are, very often, available to authenticated users of the service or even the public. There are API’s for updating the price of items on eBay, posting to Facebook, getting the current weather conditions, or getting the structured data from your favorite Reddit page. And all of these API’s and many more, are RESTful, meaning that sending a request to a specifically structured URL will return some structure data or tell a service to do something for you. This is where mobile web browsers come in.
The QR Code is your Interface
So all we have to do to make a web service do something is send a request to a URL. And all we need to trigger a request to a URL is scan a QR code that contains that URL. This means that scanning QR codes becomes a physical interface to the power and connectedness of the digital world. It is now the same as pressing buttons to control the Web!
The question is now, what would you want this button to do? Depending on what you can connect to, this could be everything from light switch, a messaging service, an alert system, a doorbell, some kind of Kanban system … or a voting system.
Why not Mobile Apps or IoT Hardware?
If you’ve gotten this far and you’ve done more than just scanned for cat Gifs, you are probably asking, “Why not use a Mobile App or IoT hardware where you can literally use a button as a trigger?”
The answer is cost and ease. Their is a huge cost to DIY mobile applications and connected devices. Using QR codes is as simple as generating the codes and printing the papers. Again, the context must be considered. QR codes as triggers are probably best used where use is passive and takes place over a short timespan making investment in an app or hardware infeasible.
Also persuading the download and use of mobile apps is a massive barrier. The same could be said for QR code scanner apps but for most applications, QR code scanner apps are more universal than any application that would offer the same functionality. Additionally, in places where QR codes have a stronger value proposition, like Asia, (see above) QR code scanners will be found in apps that are already commonly used, like WeChat.
Uniquely QR Codes
There is also an interesting combination of properties of QR codes that can make or break them as triggers. If the publisher uses QR codes with intention, these properties can become a features of the technology rather than a weakness.
- Contextual – Users have to be in the same physical location of the QR code to receive or send the data that the QR contains. In a way, the location of the QR code acts as an implicit authentication. If and only if users are nearby can they scan the QR code.
- Inherent barrier to use – This one is difficult to view as a feature but the barrier could serve as proof of motivation. This barrier can allow us to infer some things about their user and/or the strength of their motivation. Digital fluency, to some degree, is required. There is also a measure of curiosity and/or motivation that is needed.
- Visual – You know them when you see them and they are their own call to action. They are the same as putting a big link on a page that says “Click Here!”
- Coded – Again, they hold more information or instructions than one could ever hope to print in the same space and have it make sense. They also allow for long, dynamic URLs or if you so choose, intentional misdirection.
- Can hold and send information about their context – Depending on how dynamic the publisher chooses to be in creating QR codes, the codes could contain an element of mass customization. The QR code’s URL could send the destination URL (web page or web service) information about the context of the QR code. This could allow the receiver of the Web request a customized response or action in the same way that a search query on your favorite ecommerce site provides customized information on the following page.
- Duplication – Ok, it’s really hard to see how this could be anything but a weakness. It is somewhat difficult to ensure that a URL is not requested twice, either by scanning a code twice or browser refresh.
Motivating this Example
The intent is to demonstrate two things: dynamically generated QR codes that hold contextual data and web requests to a web service rather than a web page. To do this, I decided to create a QR code ballot where votes are tallied in a cloud service.
There have been other applications of QR codes for voting. In most of these, the QR code provides a link to an online form (hopefully mobile-friendly) where voters can enter their responses. Unlike these applications, in this version, scanning the QR code is the actual act of voting. This infrastructureless mashplication is also free and a MVP of what could be done.
Building a Prototype
For a test case, I used a project that has been happening in my neighborhood for a couple years called HK Walls. This project pairs wall donors to artists from around the world to create awesome public art. At the moment, each of these walls, has nothing to signify that it is part of the project or the project itself.
The HK Walls project does fit perfectly into this voting idea because it is location-based and inherently mobile (it has its own hashtag). It is also clearly visual and lends itself to normative voting. Art is either the perfect or the worst use case for this but this is just a test. There are plenty of other applications for this if you use your imagination.
To build the prototype, very little is needed; just Google Spreadsheets, IFTTT, a B/W printer and some spare time.
Step 1: IFTTT Recipe Setup
This step provides the base URL for the IFTTT Maker channel. It even creates the spreadsheets for all future steps. See my recipe.
Step 2: Dynamically Generate Lots of QR Codes
I used Google Spreadsheets and Google Charts’ QR code API to generate the QR codes. Each QR code was dynamically generated by using Google Charts’ QR code API to encode a combination of an IFTTT Maker Channel URL, the location of the HK Wall and the variant emoji. The result was 88 QR codes with different contextual (location) and normative (emoji) information.
The normative emojis are placed above each location’s row of emojis so that they can be cut out with the set of QR codes. After finishishing step 3, I added a column of QR codes that would send scanners back to the chart.
See the Google Spreadsheet QR Code Generator for Voting
Step 3: Setup and Publish the Results Chart
The fifth column of QR codes holds a QR code that links scanners to the aggregate results of the poll (average rating values for each wall). This is a simple chart based on a pivot table of average scores. The chart was also published so it could have its own URL for scanning.
The Google Chart URL shows this on a mobile browser:
Step 4: Print the QR Codes and Rock the Vote!
If I were to do this in real life, I would print these all out and paste them up on the walls. But it is not my place to facilitate judging of free public artwork. That seems to oppose the spirit of the project. I encourage you to though to use this for your own Democracy!
Use Your Imagination
I had to see this was possible. I had to know that QR Codes could control the connected web. I had to see that it could scale with minimal technical know-how.
I am satisfied with the result, I think there is some testing to do, (I am still thinking of ways to gather some actual data of QR code use in Hong Kong.) and there are many applications yet to explore. I hope that this might motivate your curiosity to find what’s left to find.