QR isn’t an end, it’s a means

QR seems to have taken on a bit of a life of its own over the past few weeks. Not only have I seen far more of the codes in the wild, but there seems to be many more people writing about it, many more news articles – and also (which is nice) – lots of people emailing me to ask how they can “do QR”.

Google Trends graph for "QR"

QR is a great technology. Actually, no – it’s an ok-ish technology. The more important thing is that the awareness means gains in popularity, which in turn means more people will know what a QR code is, how to use it – and also make them aware of some of the foibles. As with anything, this isn’t about how awesome the technology is. Many, many geeky people will tell you QR is crap – which in some ways it is per se – but the important thing is market penetration, expectation, device support – and (most importantly), the content experiences which underly it.

Underlying the concept of QR though is something rather more important, which I think many people miss in their rush to play with the latest and greatest thing. The important thing is this: QR is a way of poking the digital world into the real world. In a way, QR is simply one technology in a line of technologies that does this. Remember the first time you saw a URL on a piece of print advertising? That was digital poking into real, albeit in a slightly crap way. Then bluetooth. Now QR.

Ultimately, the concept is the same in each of these cases: put a marker in the real world which allows your audiences to connect with content in the virtual world.

The technology with which you do this can be agnostic. This year it might be QR. Next it might be NFC or AR. The following – who knows, image recognition / hyper-accurate GPS / whatever. The facts remain the same:

First: People have to have a desire to engage with the marker in the first place. Why would you go to the effort of scanning a QR code with no knowledge of what that code might provide for you? Nina Simon just recently blogged about QR Codes and Visitor Motivation which asks this question. The cost curve – as always – has to balance: the value that your user gets out must be greater than the effort that they have to put in – and (almost more important), you have to make this value clear before they scan.

Second: A proportion of people will never take part / have the technology to take part. QR scanning (or – even more so – NFC or whatever the next big thing is) will be a niche activity for the foreseeable future. Bear in mind that not only does your user have to have a QR code reader installed, they also need the right kind of phone, an internet connection at the point of scan AND a contract with their provider that lets them use this connection. These things are becoming more real, but it is by no means a given yet.

Third – and possibly the most important – the content that you deliver should add something significant to their experience. This is tied to the first point. Here’s a banner I snapped when I was in London recently:

UCL zoology QR code

If you scan this you get a link to the UCL Zoology Museum (and ironically, out of shot to the left is the URL that the QR code sends you to..). From a user experience perspective, I bet you 50p I can get my smartphone out, type in the url and be looking at the relevant content quicker than you can boot up a QR app, scan and open.

In this instance, you do actually end up at a mobile-friendly site and some interesting links to QR technologies in use at UCL – which is fantastic. But the use case and motivation aren’t really articulated in the physical world.

Finally – you can easily put some measures in place to track usage, and use this to inform future activity. Here’s another example, this time from the British Library:

British Library QR

If you follow this link, you’ll find it goes to http://www.bl.uk/sciencefiction. The problem with this is that the URL is the same one as is being used on the poster, around the web and in all their other marketing. So when it comes to evaluating the use of QR – and whether it has been successful as a means to pull in new visitors – my suspicion is the BL won’t have any idea how to separate out these clicks from any of the others.

The simple solution to this is to use something like bit.ly and create a unique URL which is specifically for this QR code. More advanced techniques might include things like appending a string to the end of the URL (for example www.bl.uk/sciencefiction?source=qr) – or using Google Analytics “campaigns” to track these.

(Note that you could also get even more clever by having separate unique QR codes for separate advertising zones or even for separate posters – imagine the impact of being able to track which posters or areas have been most successful…now that’s cool use of a technology…)

Coming back to the beginning of this post – the overriding point here is that QR, and many other technologies similar to it, provide a very exciting way of bringing digital content into the real world. With some upfront thinking, genuinely interesting content can be delivered in this way and users can be made to engage. As ever, though, it isn’t about the technology but about the use, motiviation and content which lies behind the technology. These are the things that count.

Links in print

I’m working on the new Eduserv website right now – content inputting, structuring, trying to hang the whole thing together – and the question came up the other day about how best to deal with incoming links from printed materials. We do a fair amount of these at work: brochures, leaflets, case studies – that kind of thing. I’m also writing a book at the moment, and this’ll have a supporting website – so the same question is looming large in another part of my life too.

When I gave this some brain time, it struck me that there are several possible solutions, and also some obvious problems which come along with those solutions, so I thought I’d punt the ideas I came up with here and see if you clever people had any better or different ideas.

The problem that needs solving is obvious: URL’s tend to be fairly cumbersome, and frankly a PITA to type in. Getting people from print to web on the other hand seems to be something which has a fair amount of potential value in it, either from a marketing “measure the effectiveness of our campaign” perspective or purely (as is the case with my book) because the web gives you an opportunity to offer additional and more up-to-date material than the printed page.

The barrier is high, though. We’re almost (I think) past having to type the http:// bit. We’re also (I think) past having to type the www bit too (unless you’re talking many government institutions, that is..).

The obvious solution, and one which – if you flick through a newspaper or magazine – seems to be the most favoured is to simply use an aliased url of some description. So there will be somewebsite.com/specialoffer or whatever. Easy enough, although there is some alias hackery required and needing to be maintained at some level. Also, the URL is still a bit of a mouthful, especially if your root domain is a bit chunky in the first place. So my old stomping ground has sciencemuseum.org.uk/launchball for example – fine, but a bit of an arse for a user to have to type.

The next obvious one is to URL shorten. Bit.ly, tinyurl, goo.gl – they’re all much of a muchness: immediate, short, measurable URLs, and if you fork out for “pro” versions of these services then you can get a similar(ish) domain to the one you originally started with. TechCrunch for example shortens to tcrn.ch/whatever. All good, but as per wider criticisms of URL shortening: not only does it kind of “break” the web, it also relies on a 3rd party. If you’re talking about printed material then the link potentially needs to be maintained and maintainable over a more extended period of time, so this becomes more of an issue than online maintenance. You can always create your own shortening service (there are a whole number of scripts out there that do it), which makes things a bit safer, but you still need to maintain a secondary shorter domain.

Next up, and potentially good but not yet widespread enough is QR coding. Instant links, but suffering from two main problems: 1) few people know what to do with a QR code or have the necessary hardware to deal with it and 2) typically you’ll scan with a mobile, which probably isn’t where you want to be experiencing the web content. There are ways round this: you could for example ask people for an email address on first scan, and send links to this address – but it’s all a bit clunky.

The final thing I can think of is to use a variation of the “big brand” approach you often see on TV: “Search the web for: ***”, but this time say something like “Search our site for: ****”. You could do this using some kind of magnifier icon to keep the words short.

I’ve got a suspicion that I’m over-thinking the problem, especially given that most brands – even companies who have a fair overlapping of offline and online presences – seem to do it using the obvious first method. But it also strikes me as a problem which could be better solved with a bit of clever lateral thinking. Any ideas?

 

UK Museums on the Web 2009 – QR in the wild

Last week was the annual UK Museums on the Web conference.

Things were particularly hectic and exciting for me this year for a whole host of reasons:

  • We launched a new MCG website in the week before the conference – this was a full migration to WordPress MU which I’ll write more about shortly;
  • We were working behind the scenes with the excellent Laura Kalbag to develop a new logo and design guidelines for the group which we also needed to get live by conference day;
  • I suggested I build and trial a QR tag demo based on individualised badges (more below..);
  • I was giving a presentation on ubiquitous technology…

Crazy busyness aside, overall this was for me the best UKMW conference yet, for one very simple reason: we’d managed to get a range of speakers from outside the sector. Often, domain-specific conferences have a tendency to focus inwards, and although it is incredibly useful to see projects that are specific to that sector, I think it is as important that everyone keeps an eye on the outside world. This is particularly the case right now, as museums come down off the 2.0 peak and start to ask where the value is and how best to capitalise on an ever-decreasing budget.

Many other people have done a much better job of describing in detail who talked about what at the conference. If you’re interested, see the many things tagged ukmw09 on Google Blog Search. For me it was probably Paul Golding, Andy Ramsden or Denise Drake who did the most insightful talks for me, but actually every presentation was really interesting and led to a fascinating day.

So now to the point of this post: the beta “onetag” system I put in place to allow delegates to use QR tags in a “real-world” scenario.

For those who aren’t familiar with QR codes, I’d suggest a brief moment over on Wikipedia or go with the one-line description: “barcodes for linking the real and virtual worlds”.

As well as wanting to give people a QR example to play with, I based the idea for the system on a problem which I think needs solving, particularly at conferences: business cards are irritating, wasteful and require re-keying (hence duplication) of details. The idea, therefore, was to give everyone at the conference a personalised badge with the QR code on it, get them on-board prior to the event so that as many as possible had QR code readers installed on their mobiles, and then sit back and watch how this kind of system might be used, or not!

For the badges, I used local print firm Ripe Digital, who are not only incredibly helpful but also have the ability to run what is essentially a large-scale mail-merge: I designed an A6 badge in Adobe Illustrator which had various fields in it which were populated from an Excel spreadsheet of delegates. (Incidentally, we’d made extensive use of Google Docs during the conference for gathering and munging delegate names, and this really paid off in terms of sharing, collaborating and processing delegate information).

I created the actual codes using a fairly nasty mix of Google Charts, downthemall and mailmerge (don’t ask) – once I’d got a local folder with all 100 or so QR codes in it, I just referenced those codes in the AI document and asked Ripe to insert the specific QR tag at top right of the printed badge.

Here’s the front of my badge – note (important, this) that the grey code under the QR tag is also unique to each person, allowing those without QR readers to take part in the demo as well.

The badge, incidentally, also contained sponsor information and outline timings for the day on the back, a detailed description of the timings and speakers on the inside fold and a delegate list on the reverse. The badge was folded from a single sheet of A4 into an A6 wallet hung on a lanyard around people’s necks. The basic premise was to save as much as possible on enormous (mostly unwanted) wads of printed material and focus instead on the key information that delegates are likely to want.

Assuming (not a great assumption, but go with me for now) that someone not only had a reader installed on their mobile but also managed to successfully read the code, here’s what happened:

The very first time a delegate uses the app, they get directed to a mobile-formatted web page which asks them for their PIN (QR number) details – that’s the bit in grey under their glyph:

Delegates only had to do this once (I placed a cookie to keep the logged-in state) – once they had, and on all future taggings, they get redirected to a screen showing them details for the person they just tagged:

This is only so much use, especially given the name badge itself has all of this detail on it already, so I also built in the functionality behind the scenes to email the “taggees” details to the “tagger”, both as a plain email but also with an attached vCard. This therefore means that the person who did the tagging can easily add this contact to their address book without having to re-key any of the information. Here’s how the email looks in Outlook:

And that, basically, is that – 🙂

So did people use it? And if so, how?

Behind the scenes, I was grabbing some data each time anyone carried out a tagging. The data I intended to capture was: who did the tagging, who they tagged and when. As it happens, and annoyingly, my script failed on the “when” bit. I also realise that in hindsight I really should have captured the user agent for each tagging as well – then I would have some insight into what people used, most common devices, etc. With a fair amount more time (of which I currently have none!) I could probably marry up the server logs with device types, but for now I’ll leave that bit of information to one side.

The first bit of interesting information is this: there were 81 taggings during the day, which was actually much higher than I’d anticipated.

27 different people used the system (out of around 100 registered delegates)

On average, the people who did tag someone did it on average 3 times, although this figure is skewed upwards by one person who tagged 21 people! Here’s how the distribution looks:

Another view on this data shows that a fair number of people also tagged themselves, presumably to familiarise themselves with the software (that’s the visible diagonal line bottom left to top right):

So what did we actually learn from this: first of all, total simplicity from a user perspective is – as always – absolutely key. Here, we had a willing audience who had been given a heads-up to expect to install the software, definitely would have been “geek skewed” in terms of internet-enabled devices and were willing to play; and although I was pleased that lots of people took part, the figures show that this is clearly far from being a “everyone does it” activity.

Secondly, the blocker – again, as always – wasn’t just the technology but the social issues that surrounded the technology. I saw lots of people tagging, but this wasn’t an “invisible” activity of the type that makes for seamless interaction. People had to stop other people, ask them to hold still, take a photo, wait for the software to catch up, try again when the barcode failed to read and so-on. However hard I tried to make the back-end seamless, QR software just isn’t good enough (yet) to deal with quick shots, moving targets, wobbling hands. In this particular instance (and this is actually the next stage of onetag that I’m going to look at), RFID or SMS based tagging would have been slicker.

Thirdly, although I see business cards as an issue, it isn’t necessarily a problem which is identified as such for everyone. Exchanging a business card is natural; scanning a badge isn’t. So for this to really work, the technology either needs to be invisible (I just wave my reader over your badge, no focussing or waiting or holding still..) OR the win needs to be much more tangible (a tagger gets more information about a tagee, or there is some kind of other incentive to make the connection, etc). Providing more information obviously has privacy issues, and also potentially usability issues; as the incentive becomes bigger, so – normally – would the complexity of both the system and the explanations underlying that system.

Overall, I was very pleased with how the system worked, and also delighted that so many people took the time to test it out – so thanks to you, whoever you were!

I’m going to be continuing to develop the various onetag systems, and am always up for hearing from you if you’d like me to put something together for your conference or event – just comment or email and I’ll get in touch.