Terribly successful

Imagine a web application as it should appear in 2010.

Now lower your expectations in absolutely every way.

Design? Absolutely terrible. We’re talking default and mixed fonts, no thought given to typography, spacing. Bad 1995 animated GIFs scattered around.  Terrible Photoshop, or more likely MS Paint skills – that kind of gratuitous dropshadowbeveladdsomesunglareandanotherlayer thing you do when you’re first fiddling with image editing programs: no subtlety, no restraint, no style.

Lower your expectations a bit more. The UI is awful – any sense of navigational place has been whittled away not just by the design but by the FULL ON nature of the interface, the ads, the lack of anything consistent.

Actually, the web interface is less important than it could or should be: really, all the action happens instead in your email inbox. By default, you get 550 or so emails from this site every week. That’s 80, every single day.

What else? Oh, no tagging, no taxonomy, no (meaningful) search, no API, no feeds. No proper database of past posts, actually…

Sounds terrible, right? Sounds like hell on a stick? Sounds like the kind of site you’d laugh at, one you’d definitely not get involved with? In fact, maybe I’m making it up as a kind of case study of how not to do the web, right?


This is Bath Freegle. And the thing that utterly confounds anyone who looks at it (apart from the fact it flies in the face of everything we believe in as web people) is this: it is utterly, totally and unbelievably successful. Not just “not bad” successful, but in-your-face “literally, you’ll have people picking your stuff up within minutes of posting it” successful.

There’s a number of reasons why this works, of course (ranging from “people understand email” to “hey, free stuff!”). A passionate audience of more than 11,000 members helps. Free stuff certainly helps. Fulfilling genuine human needs helps (I need to get rid of shit, and can’t be bothered to sell it on eBay: you fancy said shit. Let’s deal).

Nonetheless, this makes us web types twitch for two main reasons: 1) it flies in the face of most of the things we believe in, and 2) it could / should be so, so much better.

So can we learn anything from this (apart from the fact that humans will do nearly anything for free stuff)? Maybe it’s something about going where the people are. Maybe it’s about simplicity. Maybe it’s about priorities, and how we should spend more time working with users to understand what makes them tick. Maybe it’s about all of the above.

Maybe. But that doesn’t make it any easier to swallow…

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.

There is no PEBCAK

Watching Google’s amazing “what is a browser” video (below) it is easy (and I can almost hear the geeks laughing) to assume that these are just stupid people on a bad day. I mean, what the hell is wrong with them? “My browser is Google”? WTF?

The thing is, these aren’t stupid people. They’re just normal people, going about their normal lives doing normal things. And these are the people we’re building websites and interactive experiences for.

The phrase Problem Exists Between Chair And Keyboard (and wow, isn’t it interesting that there are LOADS of phrases on the same page which mean the same thing, and all equally rude..) was invented by developers trying hard to find excuses for the poor implementation they just rolled out.

The thing is, the problem isn’t BCAK, it’s In The Dev Team. Maybe we should invent a new acronym: PEITDT

Longer term, this is of course more to do with tech literacy, being a digital native, familiarity with the web and so on. Shorter term, until we solve the literacy problem, we need to pay extra-special attention to users. And maybe never, ever say the phrase PEBCAK or any of its permutations again…


OpenID: fail.

[ Do you know what – I’m a bit nervous about this blog post. The reason I’m nervous is that I’m writing about something I really don’t understand too well. I’ve tried – I really, really have – I’ve watched videos and slideshows, looked at diagrams, read explanations. But I still don’t really understand how OpenID works. And for a long while that put me off writing this. I know that OpenID has a lot of people gunning for it. And I know that support is gaining, at least in numbers of service providers. But in the end, it comes down – as always – to the user – and the experience I have had has been as that user. And I simply can’t, won’t – and don’t use OpenId. Because it’s rotten, and broken, and failing. So I went ahead and wrote this anyway..I’m sure you’ll let me know what you think 😉 ]

The geek world has been getting excited for a fair while about OpenID. You’re probably all familiar with it and I’ll leave it up to Wikipedia to describe the service in detail, but in short the notion is that managing multiple identities online is increasingly problematic, and that some kind of way of managing these identities in one trusted, decentralised place is what is needed to make life better.

OpenID is based around the use of a uri as the unique identifier for an individual, not an email address, as is so common today with most sites.

All well and good, you’d have thought. The only thing is there’s an enormous, hulking great elephant in the room: OpenID doesn’t work.

I should clarify. In a technical sense, OpenID works. But from a usability perspective, it’s absolutely horrible.

Let’s examine the user flow for someone signing up to a.n.other site using the “traditional” method: they arrive, they click “register”. They put in their details, including email address. They go to their email account and click on the “validate” link. Done. The purists all shift uncomfortably in their seats – the users’ identity has been propogated to yet another site (eek, duplication) and there is also a reliance on the email provider (eek, single point of failure / “evil” company fear, etc).

Now let’s have a look with OpenID. And let’s consider it in the best possible case scenario – user has not only already created an OpenID but knows the address AND is signed in (i.e has a currently active session/cookie) to that providers’ service.

So..user arrives at site and is asked for their OpenID. They put in the address and push go. The site then redirects them to their OpenID provider. User clicks to allow access to data, and selects a persona. Provider site then redirects back to the original site. Original site then (inevitably, in my experience) asks user to fill in additional “persona” data for their service as well as what they already entered. User enters site.

That’s at least a couple more steps, and remember that’s if they’re signed in or even have an OpenID account. If they’re not signed in (but have an account) then they still have to sign in on the OpenID providers’ site. Using a username and password…If they don’t have an OpenID, just add at least 3 more steps. If they forget their OpenID then the process to get it back has to be done on the provider site and not on the site they’re wanting to access.

There are several thing that are really badly wrong with the OpenID / user landscape. Here’s how I see them:

1. Users don’t understand the use of a URI as identifier
This is about education, but it’s an important point. People see URI’s as “web addresses”, not as personal identifiers. They don’t get it, and aren’t being encouraged to get it, either.

2. Users don’t like redirects
Actually, users don’t care about redirects – what they do care about is maintenance of trust and brand. A user mid-basket on Amazon is not going to be happy about a jump away to another site unless they’re very clear that there is brand association between the sites.

3. Users won’t remember OpenID’s
Not only are OpenID’s longer and more complex, they’re also a dog to get back once forgotten. With email/pwd, you just click the “forgotten pwd” link. Email, click, done. With OpenID you have to go back to your provider site and do it from there, not on the site you’re trying to access.

4. There is no paradigm
Apart from password remembering within the browser, there isn’t a “central persona management” paradigm. This doesn’t mean there shouldn’t be one, but it makes the job of invisibile tech that much harder.

I’ve left what I see as the single biggest issue until last:

5. There isn’t a problem that needs solving
As I’ve indicated before, we (tech savvy geek types) are not the normality. I may have a sign-up obsession and belong to hundreds of sites, but normal people just don’t. By some gentle “finger in the air” reckoning, I’d suggest that most people have – what – ten sites they sign in to? That’s hardly shouting out for a distributed, decentralised, persona-based solution, is it? What’s actually wrong with a “remind me of my password” link, anyway? And using email as identity is secure enough for pretty much any application. We geeks are making assumptions based on our experiences of the web. It’s us, not Joe Normal who has 400 passwords in our heads, surely?

So on the one hand we’ve got an elegant, beautiful, technically “good” solution that is almost completely unusable. On the other is something ugly and flawed – but something that works well for most people: something that isn’t actually broken, and – frankly – doesn’t need fixing.

OpenID feels like it could and should be better, but the current scenario whereby hundreds and thousands of sites are becoming providers (AOL, Orange, Yahoo!, etc) and very little effort is being put into fixing the flawed user flow – or user education for that matter – is just a road to nowhere. Some sites (LiquidID, ClickPass, Vidoop as examples) are just starting in the usability direction, but it’s nowhere near enough. And right now, I – like most people I know – are just fine sticking with the original email/pwd alternative.

IT tools I *really* use

I keep having moments of needing to consolidate and simplify. Maybe it’s a puritanical precursor to some kind of horrific mid-life crisis which will see me going nuts and buying cars, motorbikes and a Macintosh Air*.

More likely, it’s the realisation that I personally use IT tools in several different modes, and that understanding these modes is increasingly important to the way I evaluate new systems, paradigms and technologies.

Firstly, I’m a serial tryer-outer. The word serial shouldn’t actually be underestimated here. I am reasonably sure (I have absolutely no way of telling) the number of alpha/beta sites I’ve joined is in its hundreds. I suspect maybe 3-400. Apart from the obvious psychological weirdness of this (please still be my friend), it also means I am constantly installing, un-installing and otherwise evaluating whether tool A or website B actually does anything of any use.

Quite apart from the fact that Windows hates this kind of behaviour and my Gmail account is now full of endless newsletters from Yet Another Damn Web Service, this is actually a very valuable exercise. It very quickly highlights the things I really can’t do without as opposed to the things that are really exciting but not actually of much use. Usually I manage to avoid things that really aren’t any of the above and frankly shouldn’t ever have happened in the first place but every so often these feature too.

The distinction between invaluable and merely exciting is an important one. In fact, it’s so important I reckon it lies somewhere near the heart of the whole problem with IT. That’s another topic altogether, though.

For this post, I’ve chosen the top five applications I use every day – the ones that make a real difference to the way I work. And make no mistake, each and every one of these tools has emerged (following the try-it-out approach above) as the current leader in a harsh and crude evolutionary race. All of them have fought against others in the same space, and won (for now…) – they simply do what I want better than anything else I’ve tried.

1. Syncing = Google Browser Sync and SugarSync (£various)
I can’t even begin to explain the positive impact both of these tools have had on my working life. Google Browser Sync (FF only) keeps your history, passwords, open tabs, bookmarks synced across any browsers that you install the extension for. I’ve tried a bunch of other tools but GBS is low-impact, easy to use and does what it says on the tin. SugarSync does the same thing for files and folders and it is utter genius. You install a client on each machine (PC or Mac), choose which folders to sync. Done. Never again will you arrive at conference and find your keydrive can’t be read. Never again will you get to work and think “arse, I left that document on my home PC”. In fact, you’ll never use a keydrive again. Oh, and did I mention it also provides mobile access…?

2. Email = Gmail
Head, shoulders and several entire bodies above the rest. I’m not going to go on about it here – you’ve all heard of it, you’ve probably tried it and with any luck you’re also using it too. For spam protection, labelling, search, 6Gb+ storage, functionality, mobile access….no other contenders.

3. Images = Picasa
PC only (although I might have read somewhere that it’s coming soon for Mac?) – just simply the best image management system bar none. Chuck in easy re-sizing for emailing files, XML output, online galleries, tagging, yada yada

4. Doc sharing = Google Docs
It’s another Gmail and just continues to get better. The latest stuff (forms for spreadsheets – genius!) and the Google Visualization API reading data straight from your documents just keeps pushing the boundary so much harder and further than the other contenders in this space.

5. Tasks = Tudomo ($30)
I get a fair amount of stick in the office for this one. Yes, I know all about Outlook tasks. Yes, I’ve got Outlook 2007. Yes, I know it all integrates with email, contacts, calendar, yada yada. But the fact of the matter is, if you haven’t tried Tudumo, you’re just simply not going to get it. That’s fine. If you want to continue with slow, clunky, inflexible, shortcut-less control of some corporate, creativity-free nastiness, then carry straight on. If instead you’re looking for a tag-centred task-list which doubles as scratchpad, ideas register, GTD dashboard and reminder system, give Tudumo a whirl. The first time you try it, you think – “well hey, nothing special” or (if you’re me) “desktop app? Soo last year darling..”. But then you realise it’s something pretty special. If you’ve tried online task tools, you’ll be surprised how much better a lag-free desktop tool is for quickly sketching down ideas or tasks. It could really do with a web version which echoed your tasks online, but that’s on the roadmap, so for now I’ll forgive.

Any on your list? Things I’ve missed that could knock my choices off my top 5…?

(* I of course do need a Mac Air. I just need to sell my children first.)