July 16, 2008
[ 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.
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.