QR Codes: bad idea or terrible idea?

People have a problem finding your URL. You post a QR Code. Now they have 2 problems. Or more:

1. They see a chunk of robot barf on your poster, and have to realise it isn't a crossword puzzle, but a QR code.
   
2. They need to take a digital photograph of it with their phone. If they have a laptop, even with a camera, this requires physical contortions
   
3. They need an application on their phone that can make sense of a QR code.
   
4. They need a lot of patience as they fiddle with it.
   
5. They need a working network connection to resolve it.

Conversely, with a URL they could type it in, take a photograph of it and type it in later, or if they have the right app, it will recognise the URL text from the image and make it clickable.

That is the irony of this. QR Codes ignore years of research and culture on how to communicate meaning in symbolic form designed to be captured by image processing tools behind a lens. We have this technology. It is called writing.

Written language has a set of symbols that are relatively unambiguous, that are formed of curves rather than hard edges making them resilient to noise, and have been market-tested for milennia. QR Codes don't just ignore this, they ignore the relative success of one dimensional barcodes. Notice something about a barcode? It has the number printed on it as well, so you can type it in if the scan fails. QR Codes don't do this, so it's far too easy to put the wrong one in, or fail to replace a mockup. Which is why so many QR codes link to Justin's site instead.

The only place you should use QR codes is if you have a dedicated reader for them, like a classic barcode scanner, and a workflow that is designed for this that actually saves time. If you do empirical research on using QR codes for the public, you'll likely see 80% worse performance than text like this museum did. By all means try the experiment and report your results. Put up a QR code and a printed URL and see which gets the most usage.

Or listen to others:

a majority of our respondents knew more or less what they were for, very few (n=2, or around 7%) were successfully able to use QR codes to resolve a URL, even when coached by a knowledgeable researcher.[..] A strong theme that emerged — which we certainly found entirely unsurprising, but which ought to give genuine pause to the cleverer sort of marketers — is that, even where respondents displayed sufficient awareness and understanding of QR codes to make use of them, virtually no one expressed any interest in actually doing so.

As Alexis Madrigal puts it:

Is it really faster and better to use a QR code that will direct you to part of a marketing campaign rather than getting a broader sweep of information by simply using the browser that you already use all the time on your phone? In the instant cost-benefit analysis I do every time I see a QR code, it has yet to make sense for me to fire up the decoder app I have installed on my phone.

QR code at the bus stop to get time of next bus. Really useful in the dark. Not. yfrog.com/mgicpqj

— Martin Geddes (@martingeddes) January 27, 2012

Shortening URLs, or getting inbetween?

With the rise of short message systems like Twitter, there is a growth in URL shorteners (as each one's namespace gets full, others get shorter). Today bit.ly launched to big fanfare in the blogosphere.

I took a closer look. What I noticed is that the older generation of these - tinyurl.com and xrl.us use a 301 Moved Permanently redirect, whereas bit.ly and is.gd use a 302 Found redirect, which means 'don't cache the redirected URL, keep checking the original'.

In other words, these services are saying in their HTTP responses that they may change what the short URLs point to in future, putting browsers, indexers and caches on notice that this may happen.

I also noticed that bit.ly, like tinyurl.com, allows you to pick a custom label from their namespace, but if you do it returns two 302 redirects in sequence (once to a more cryptic bit.ly url, then to the external one you chose). I pointed bit.ly/k at this blog, so you can check it yourself with curl:

$ curl --head http://bit.ly/k
HTTP/1.1 302 Found
Location: http://bit.ly/fwNKA

$ curl --head http://bit.ly/fwNKA
HTTP/1.1 302 Found
Location: http://epeus.blogspot.com

Apart from the extra delay this introduces, this is also telling your browser and web crawlers not to cache this, as they may change it in future. Compare tinyurl.com:

$ curl --head http://tinyurl.com/kevinm
HTTP/1.1 301 Moved Permanently
Location: http://epeus.blogspot.com

Google's advice for webmasters is to use 301 for redirects, as this signals the preferred URL.

URLs are people too

There is an assumption buried in the collective mind of developers that is hard to remove, and it is that people are best represented by email addresses. Go to almost any website to sign-up, and you are prompted for an email address and password. Signing up usually involves digging out the site's reply from your spam folder and clicking on a link to get confirmed, then giving it a password. Sometimes you get to pick a username too, from whatever stock of namespace is left at the site.

Elizabeth Churchill and Ben Gross looked into this and found out that people find it easier to remember passwords than usernames, because they use the same passwords everywhere, and they end up with multiple different email accounts to handle the problem of having handed them to to all these sites and getting spammed by them.

Meanwhile, over here in the blog world, we've been using blog URLs to refer to people for years, and social network sites have proliferated URLs that are people. I have several that refer to me, my events, my music, my twitters and my photographs linked from the sidebar here. We even have XFN's rel="me" to connect them together, and OpenID to allow them to be used as logins elsewhere, instead of emails.

The underlying thing that is wrong with an email address is that it's affordance is backwards - it enables people who have it to send things to you, but there's no reliable way to know that a message is from you. Conversely, URLs have the opposite default affordance- people can go look at them and see what you have said about yourself, and computers can go and visit them and discover other ways to interact with what you have published, or ask you permission for more.

So, developers, remember that URLs are people too.

Update: This tension between email-as-identifier and email-as-way-to-be-spammed is what makes Scoble's attempt to extract 5,000 people's emails from Facebook for his own use less defensible than it appears at first. Dare Obasanjo recognises the tensions, but strangely dismisses the OpenSocial attempt to abstract out this kind of data into a common API.