What’s so great about mobile?

I gave a presentation recently at UK Museums on the Web entitled “The Intertubes Everywhere”. It was a re-working of my Ignite Cardiff talk, with a gentle angle towards cultural heritage. Here are the slides:

[slideshare id=2742484&doc=theintertubeseverywhere-091218044628-phpapp02]

The one-liner for those that don’t have the time to go through the slides is something like this: I believe that although mobile has been held up as THE NEXT BIG THING for some time, we are reaching a kind of “perfect storm” of conditions where it is at last becoming a viable reality for many users and therefore something for institutions to think about, too.

This is as much to do with effective marketing and consciousness raising as it is to do with device or network capability: if you’ve tried buying a mobile phone in the last year or two, you will have been offered mobile internet; if you go to a mobile phone company website today, you’ll see smartphones, dongles and internet on the go on their homepage. It would be very hard to miss this kind of marketing push. Couple this with the radical improvement of mobile content, the beginnings of location-based services and the increasing speeds and capability of a “normal” mobile device, and it seems pretty clear that we’re on the cusp of something pretty big.

If you’re in any doubt, check out slides 25-35 of the presentation that Dan Zambonini and I did at DISH 2009, which have some interesting figures on changing mobile usage. With device replacements happening on average every 14 months, even the old-school phones that don’t support mobile internet won’t be here for much longer.

With this level of exposure, it’s obvious that museums and other cultural heritage institutions are going to be following along and getting excited about mobile, either building iPhone apps or creating mobile versions of their sites.

While it is excellent to see innovation in this field, I’m slightly underwhelmed by some of the mobile offerings starting to appear that seem to be more “because we can” rather than “because we should”, in particular the current trend (and I’m deliberately not giving any examples – you can go find them yourself!) for “mobile collections search”.

It seems to me that the single mantra which should surround any mobile web development project right from the start is something like “never forget: the mobile browsing experience is far, far inferior to the desktop browsing experience”.

Browsing a mobile website is generally not a fun time. You don’t relax when you’re browsing on a mobile; you don’t lose yourself in the content: you’re there in sit forward mode, and you want to do one of two things:

  1. find some information and get out as quickly as you can
  2. use the capability of the “mobile” bit of the experience to do something…well, “mobile”

The first point is a no-brainer, IMO. Consider when and how I might choose to browse a museum website on my mobile. The answer is not “in my living room at home” – if I’m there, I’ll go find my laptop and have a far easier and more pleasurable experience in sit back mode. The answer probably is (and don’t shout at me for being obvious..) but when I’m mobile. I’m out and about, wondering what to do at lunchtime, thinking about whether a museum is open or where I can get tickets or how to get there. I’m not on WIFI, and I want the information as quickly and as seamlessly as possible. I don’t want images, I don’t want interaction, I want information. And I want it right now. And – this is the painful bit – I really, really don’t want to browse the collections. Why would I want a second-rate experience of browsing content using a 2″ screen, some clumsy non-mouse interaction touchpoints and a slow connection? And – more to the point – why would I possibly want to stand in the street (being mobile…) and look at museum collections? I don’t*.

* Actually, sometimes I do, provided the mobile experience adds something. And this is where point 2 comes in:

If I can have an experience which augments my real experience rather than just providing a poor quality facsimile of an online experience – then you’re talking about truly putting mobile capability to good use.

So for example – if I’ve got a known location (and this can mean GPS but more likely in our museum context means “I’m standing in front of artefact X and my phone knows that because I’ve keyed in something to tell it this”), then now is the time for the museum to give me additional information about other similar exhibits, let me bookmark that artwork, or share it with my network.

mobile.nmsi.ac.uk - something I knocked out about 5 years ago and still live!

Some of the museum sites we’re starting to see are making use of this capability – check out BlkynMuse on your mobile (and note the immediate emphasis on “where are you on-gallery?”) as a good example; but there also seems to be an increasing number who are simply putting their museum collections online as they are in some kind of mobile format – either a mobile optimised site or (worse) an iPhone application, with none of the context-sensitivity that makes mobile a value-add proposition for end-users.

Much as I’m glad to see innovation in this space, I’d much rather see museums focussing on point 1 above by having a mobile-sniffing code on their homepage and redirecting to an optimised m.museumsite.com page with visiting information, than putting in a huge amount of effort into providing mobile-optimised collections search. At the very worst, museums should have the subdomain m.*** or mobile.*** and there have a script to strip out the images and so on. There are many ways to do this – here, for example is the Museum of London site stripped using a simple PHP script from Phonefier, or see these tips on how to create simple “mobilised” versions of your existing site with zero extra effort.

Once the simple and high-gain win is done, then it’d be great to see some location-specific and innovative approaches to “virtually collecting” or augmenting collections experiences. But the “browse our mobile collections site” without really thinking about the use-case is pretty much saying: “go here on your mobile and you can have an experience which is infinitely worse than the one on your desktop with absolutely no upside”. In other words, no thanks.

What do you think? Has your museum got a mobile site for visitors, or just for collections, or none at all? What mobile apps have you downloaded or accessed that provide museum collections (or other) information? How was it for you?

UPDATE (about 3 minutes after I posted this…): I just realised I utterly neglected to talk about gaming. Which, IMO, is where mobile (and in particular mobile collections) have a huge amount of potential. I think this’ll have to wait for a future post 🙂

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.