Julie Zhou of Facebook discusses usability findings from Facebook Connect. Photo © John McCrea. All rights reserved.
Monday last week marked the first ever OpenID UX Summit at Yahoo! in Sunnyvale with over 40 in attendance. Representatives came from MySpace, Facebook, Google, Yahoo!, Vidoop, Janrain, Six Apart, AOL, Chimp, Magnolia, Microsoft, Plaxo, Netmesh, Internet 2 and Liberty Alliance to debate and discuss how best to make implementations of the protocol easier to use and more familiar.
John McCrea covered the significance of the summit on TechCrunchIT (and recognized Facebook’s welcomed participation) and has a good overall summary on his blog.
While the summit was a long-overdue step towards addressing the clear usability issues directly inhibiting the spread of OpenID, there are four additional areas that I think need more attention. I’ll address each separately.
Make it easier!
Overwhelmingly criticism of OpenID has been leveraged by developers and web users alike against OpenID’s ease of use.
For developers, implementing OpenID is confusing and cumbersome, and often tacked on as an afterthought to appease annoying early adopters (like me) who badger them to support the protocol. Even those who support the protocol report little upside, compared with something like Facebook Connect, which brings with it richer aspects of someone’s profile and social graph.
For web users, OpenID is confusing and frustrating, resulting in what I call “OpenID double registration taxation” — where a user, immediately following OpenID authentication, is prompted by the relying party (RP) to supply, and then verify, their email address. Why bother with OpenID if they’re going to have to go through the old school registration process anyway? Where’s the benefit in that?
On this latter point, we probably won’t make much headway until email harvesting goes out of vogue, which won’t happen until there’s a better way for sites to spam/bacn their members (bacn: “email you want, just not right now”), or until OpenID Providers (OPs) more consistently pass on profile attributes via SREG, Attribute Exchange or PoCo (or until people realize that email is dead to the MySpace generation).
Unfortunately, mandating that providers pass on profile data is something that cannot, and probably should not, be mandated by the OpenID spec, even though in comparison, Facebook Connect always provides some data. Fortunately OPs like Yahoo! are starting to improve this situation, by enabling opt-in controls that enable users to share their data more easily. If this trend continues, we may see fewer “double taxation registrations” and smoother OpenID login flows.
Still, for both end users and developers, OpenID must become easier to use and more obvious to implement. Fortunately, there is now fairly widespread recognition within the OpenID community of specific issues and a strong willingness to address them.
To that end, for example, advocacy for email addresses to be used as OpenIDs is growing, providing web users the convenience of reusing a familiar identifier, and affording developers a way to “upgrade” legacy userbases that may have been keyed to unique email addresses.
It is my opinion that enabling an email address to be used as a “hint” that resolves to a valid OpenID URL is a necessary step to dislodge one of the main nettles against OpenID. I also believe that this step is necessary to bridge the impending generation gap that’s sure to develop when MySpace flips the switch on their OpenID provider, enabling over a hundred million URL-based OpenIDs. Privacy concerns notwithstanding (remember, most RPs already demand a verified email address anyway), there are few reasons not to use email addresses for OpenID. I’d rather just make it so and let people pick for themselves how they feel most comfortable identifying themselves on services and move on to meatier issues.
Branding and marketing
On that note, Max Engel from MySpace brought up some important points about what it would mean to enable email addresses as OpenIDs. Soon to be one of the largest providers of URL-based OpenIDs (i.e. myspace.com/factoryjoe), he’s concerned that people will only implement support for email addresses if the OpenID spec provides a way to translate email addresses into URLs. This is a valid concern, but one that can be mitigated both in the language of the spec, and in the libraries that perform OpenID authentication.
Here is where I see an opportunity to finally establish OpenID as a brand unto itself, where the word “OpenID” can and should come to mean something to people (though of course not without an ongoing substantial and sustained marketing effort, lead by the OIDF, but primarily prosecuted through grassroots and community “spreading vectors“).
Here’s why: people have learned, over time, that “email” is easier to say (and shorter to type) than “electronic mail”. When you ask someone for their “email address”, most people on the web can give you the answer you’re looking for. We’re a long way off from the same kind of familiarity with OpenID, but ultimately you have to start somewhere. And because “URL-based identifier”, “blog address”, “profile link”, “home site” — ad infinitum — probably don’t mean much to anyone (let alone the same thing) there’s an opportunity to converge on a term that’s easy to say and captures the concept fairly well (or well enough) and is otherwise not known.
It’s also important to consider that not all URLs are in fact OpenID-enabled. This point alone is enough to convince me of the importance of the OpenID name and the potential for the brand. When you ask someone to sign in to your site, you can be pretty sure they’ll know what their email address is. If you ask them for a URL, and they provide you with a perfectly valid address but one that is not OpenID-enabled, they will not be able to sign in. If we can make it clear that “having an OpenID” is something special, and that not all URLs are OpenIDs, then we can begin to create the kind of awareness necessarily to confidently ask people for an OpenID, and have them respond appropriately.
It is here that I disagree with Scott Kveton, who has long argued that his mom didn’t “get SMTP, they got email”. I appreciate his sentiment and used to agree with his argument in principle, but now that I’ve thought about the fact that only “special URLs” are OpenIDs, I think it’s worthwhile to give that class of URLs a specific name.
Consistency
Furthermore, one of the greatest threats to the viability of OpenID is an inconsistent user experience. Unfortunately, this manifests itself both when signing in to a malfunctioning relying party, or attempting OpenID authentication using an OP that an RP doesn’t support (e.g. Microsoft Health Vault currently supports three OPs).
Another manifestation of this problem is that OPs are not required to consume OpenIDs. Though there’s validity in this complaint, change should not be forced at the technical level, because it really should be up to each individual provider to determine whose credentials it’s willing to accept. Now that the majors (save Facebook) have all gotten into the OP game (most recently Microsoft), it really just seems a matter of politics and inertia that none have moved to accept the OpenIDs of their competitors in any significant way (that is, neither Yahoo, Google, or Microsoft allow authenticating against their respective services using one of the other’s OpenIDs — and no, Blogger doesn’t count and Google hasn’t really released their OP yet).
While I’m sympathetic to Allen Tom’s argument that more OPs is frankly better for the web, I’m not convinced that a Visa card is all that useful if none of the major department stores will accept it.
I certainly respect large providers’ desires to both minimize the potential for abuse and to wade through the legal morass around identity technologies, but I can’t see how becoming an OpenID relying party is any worse than letting people create accounts with arbitrary (and untrusted) email addresses.
Hopefully through both political pressure and success-in-the-wild over time, we will see the majors become relying parties to their competitors’ OpenIDs for accessing accounts, and over a longer period of time, enable the use of personal/private OpenID providers or delegated OpenIDs (e.g. factoryjoe.com).
Should we see this situation change, I think it’ll bring about a watershed migration to patterns established by the majors — leading to consistency in the OpenID sign up and sign in experiences, and consistency in what people expect of OpenID account federation, leading to increased credibility and use of OpenID generally.
Leadership
But let’s get real: all these issues are going to require, above all else, solid foresight and leadership and a commitment to pushing through the thorny political issues that can often scuttle the best intentioned technologies (consider HD-DVD and Blu-Ray).
For reasons beyond my grasp, the OpenID Foundation has not met up to my expectations of leadership. Despite considerable progress in some areas, large swathes of stagnation have come to subsume many of the organization’s initiatives. International progress, as overseen by the OIDF, is lacking, except where local chapters (such as in Japan and in some European cities) have taken matters into their own hands. Code improvements to the OpenID libraries has languished and implementation of OpenID in various platforms and open source projects seems non-existent. Marketing simply isn’t happening and even if it were, I’m not convinced that there’s consensus on what we should market. And only now, after research from Yahoo and Google confirm what many critics have said for a long time is there finally work being done to address OpenID’s usability pitfalls.
Now, I realize that technologists don’t always make the best politicians (or designers or marketers for that matter) but that we haven’t seen the kind of OpenID visibility, credibility, innovation and adoption in North America that has been seen in Japan suggests to me that we’re either on the wrong course, or no apparent course at all. Worse, I fear that certain companies are already dividing up the proverbial “identity pie” before the damn thing’s even been put into the oven — a situation that needs to be addressed immediately by prioritizing a series of steps that the OIDF will take to establish OpenID in the marketplace, set firm how it will support individuals and companies alike, plot out its administrative and advocacy agenda for 2009, make clear its budgetary outlook, and list the marketing, design, education and research initiatives it plans for the coming year.
Without a clear path forward, I think that a lot of otherwise positive energy will devolve into useless sniping and infighting. Without strong leadership, we risk marginalizing many of the gains we’ve made to date in establishing OpenID as a core building block of the open social web.
For comparison, consider the progress that has been made with OpenSocial: only a year ago, people dismissed it as a “Gadgets API” (which, arguably it was). Since then, a large coalition of the willing has gathered to support and develop the protocol (which is still far from perfect, but demonstrates steady progress towards a goal), even convincing that old salt David Recordon that what they’re doing is decent. When OpenSocial 1.0 is released (they’re at 0.8.1 right now), there will be a distributed social graph with over 350 million potential customers available to developers (compared with around 100 million on Facebook). While David is right to point out, with Microsoft coming on board, there’ll be well beyond half a billion OpenIDs in the wild, that doesn’t mean that our work is finished. Rather, it’s just begun, and David sums up our situation fairly well:
While this is great news from Microsoft, real web-scale adoption of technologies always faces a chicken-and-egg problem between developers and vendors. Developers don’t want to adopt a technology without buy-in from platform providers and platform providers don’t want to support a technology if developers won’t use it. We’ve largely been able to successfully avoid this concern with OpenID as it grew from roots in an open source community with lots of people and companies involved in making OpenID what it is today. There are now well beyond half a billion OpenIDs available on the web which means we can mark the first phase of OpenID adoption, platform support, as a success.
The next phase of developer adoption will not be measured in the number of OpenIDs or sites that support it, but rather user experience, accessibility, and seamlessness of integration into a wide variety of applications and experiences.
To that end, there will be an Internet Identity Workshop in Mountain View November 11-12 where many of the primary participants in the ongoing identity conversations will converge. Historically the event has been one of the most productive in the space and with all the recent OpenID news lately, I’m hopeful that many of the issues I’ve mentioned above will be addressed and progress will continue to be made.
I will continue to be a staunch advocate of OpenID and think that it’s best times are still to come, but not without a redoubling of focused effort around concrete and ambitious goals.
Factory Joe 
I hope I understood correctly, but if so, I have doubts about the relevancy of “OpenID” as a consumer brand. For Joe the User, an Open ID is an “ID that is open”, is that something he wants? don’t think so. This is a great name for early adopters but not what is needed to go beyond 500M users.
If your goal is to seek broader adoption, my feel is that our best hope is actually not to position Open ID as a brand, but to let implementers use their existing brands (“Yahoo! ID”, “Google Account”, etc.). This is ultimately where their sustainable defensible can be built, especially by establishing partnerships around their brand, rather than the “OpenID” brand.
We might see first bilateral agreements between majors (ex. Google accepting OpenID-enabled Yahoo ID and vice-versa) before we see them accepting ANY OpenID provider.
In the meantime, there are some great opportunities for independent OpenID providers to develop OpenID-enabled consumer brands that have meaning/value to users and are able to strike the right partnerships. I think Clickpass understands that and came with a name that has actual meaning and value to users: pass/password in one click or click instead of password.
i completely agree on the importance of enabling e-mails as a valid OpenID, and believe that we should ultimately empower the user to enable the identifier he or she most strongly identifies with. at myspace, we are uniquely positioned to work with OpenID because we have a user-base that already thinks of themselves as being represented by a URL. if you ask any myspace user what their vanity URL is, there is a very good chance they’ll know it. however, beyond us and the blogging community, most users from major OP’s don’t know what their URL is, even if many of them actually already possess an OpenID. that is why, even with the excitement around Microsoft becoming an OP, a user with valid OpenID doesn’t equal a user leveraging their OpenID. it is this disconnect that e-mail-based OpenID can help to alleviate. further, we need to be flexible enough to include other identifiers that might emerge, such as cell phone numbers.
it is this eventual freedom to use the identifier you identify with as your OpenID that necessitates that the foundation take a more proactive role in marketing. it is only once the brand has been strengthened that users will understand that their URL, e-mail, or type foo identifier is something special. people know they have a credit card number, and they know who gives it to them, even if they aren’t being expressly asked for their “Visa” or “Mastercard”. we need that type of recognition.
this is certainly shaping up to be an exciting couple of weeks, and am hoping that all of us, as a community, can come together to solve these fundamental problems of usability so that our users can be as excited about this technology as we all are.
URLs are already thought to be places, not people. Google.com is a place. ESPN.com is a place. But then factoryjoe.com is a place, except when it’s not.
While email addresses are not thought to be people, everyone understands that a person is at the other end of them. Same thing with a phone number, or a Twitter username.
An OpenID needs to look like it belongs to a person, so it can’t look like a URL. But it shouldn’t look like exactly like an email address either, because it’s not one.
Here’s what I propose:
@factoryjoe.com
@johndoe.live.com
@stanlee.yahoo.com
It’s something new, yet at the same time contains very familiar elements.
Hrm… I’m not sure this is right either, but there are things to think about here. The largest problem seems to be consumers. (There’s always something wrong with them, we don’t have enough, they’re not usable enough, etc… it’s getting a bit old.) A good amount of code could improve that slightly, but there’s still some stuff we’re not really doing there. SREG was a welcome extension to the spec, but is also fairly limited in scope.
As for mapping e-mails to URLs, wow that would be ugly. Doable though
Weren’t inames supposed to take over the world anyways? 😛 (Not sure how I really feel about inames, part of me thinks they’re a terrible idea, another part of me feels they might be alright.)
On the upside, for me, I don’t have to care about inames because my domain (which doubles as my identity thanks to OpenID) is already better than an iname. Presumably we should be offering the same capability to non-technical users.
Also it appears that your OpenID code is buggy. Testing to figure it out…
Hrm, weird… please moderate this comment out and the one above it. Might be an issue with the server I was using too. (Delegated id to livejournal, so presumably, should follow the spec.)
The irony of this comment requiring an email is not lost on me…
Thanks for your kind words about OpenSocial, but I’d like to correct a couple of points. OpenSocial already supports well over 350 million users, and with both Yahoo and LinkedIn launching support today, that number has gone up even further. Telling people to wait for OpenSocial 1.0 is a misunderstanding of the spec process – OpenSocial from 0.7 onwards has been ready for App developers to use, and 0.8 adds the REST APIs needed to federate identity properly – this is a numbering scheme like Microfomats, not like Atom.
Sort of echoing @Guillaume it does seem to me that from a branding perspective the name implies an affordance that is backwards. Most people don’t want their ID to be open because they will tend to think that that means it isn’t secure. Open means different things to different parts of society, depending on your perspective.
I work at the BBC and it surprises me how many people who use our services (and non-tech folk inside) don’t grok what OpenID is. It tends to be thought of as a central service which people and services can use. I’m not sure I fully understand why that is, although I have some ideas.
It seems to me that the name needs to be more people focused. Needs to imply that it’s something that you, as a user, own. Although I don’t know what that would be 🙂
It also strikes me that it might help if OPs carried a standard icon i.e. your OpenID URI had the OpenID icon, a bit like your credit card carries a Visa logo. RPs could then carry branding that mapped back to that i.e. ‘OpenID accepted here’ even if that were also branded Yahoo! Facebook or whatever. You know a bit like shops do with Visa.
@Guillame: I understand your concern, but for lack of something better, I think OpenID can be made to be about “choice” and “freedom”, rather than about “insecurity” or other meanings of “open”. Consider that “open source” is now, I think, mostly understood to mean that the “underlying code is available”. Firefox dealt with this issue, and over time, the word becomes a token for something else — regardless of whether it starts out being a perfect fit or not.
As for consumer brands being what consumers interact with — I think there needs to be a balance struck, but a weak OpenID brand will not help us if one of those major brands screws up and makes OpenID look bad. Instead, OpenID needs to be understood as an enabling technology that can be used to make things better — and that your favorite brands use it to make their services more useful — but that anyone can use it too, without permission.
There should absolutely be an opportunity for independent brands to emerge as OpenID providers, but to your last point, if we rely on awareness of phrases like “Google Account”, “Yahoo! ID” and so on, how will a scrappy startup like Clickpass ever get on the login screen? That’s why it’s critical that a neutral brand like OpenID become the thing in and of itself — making way for such independent providers to earn their way up the ladder of success.
@Max: Thanks for your comments and support. I’m glad that you see and support both sides of this issue. I agree too that being liberal about what constitutes a valid OpenID is key — so long as (to my current thinking) we can resolve the identifier to a URL on the web (that goes for phone numbers too).
Visa and MasterCard didn’t achieve awareness overnight; so too will it be for OpenID.
@Luigi: I disagree. You prove it with your own domain name, as well as mentioning mine. And what’s the different between remembering factoryjoe.com and twitter.com/factoryjoe? I think that for different people, different identifiers will “look like” people — for some of my friends, myspace.com/factoryjoe looks like me; for others, it might be chris@factoryjoe.com. Ultimately, I should be able to think of myself in either of those ways, and validate that I own those identifiers if indeed you can find me at the other end of them.
As to your proposal — I’m not sure that’ll gain much traction in the marketplace. Take a look at XRI and I-Names and then let me know what you think.
@D.J.: Sorry about OpenID on my site. It has been acting wonky lately!
For mapping emails, check out EAUT. We already have a spec for doing this, and apparently @yahoo.com email addresses already work with existing OpenID implementations.
@Kevin: indeed. A limitation of WordPress perhaps?
And thanks also for your clarifications about OpenSocial. Hard to stay on top of it these days!
@Tom: Again, I take your point but don’t necessarily agree that “open” *must* mean insecure. This is why I think marketing is so important — as well as choosing our messages and language well.
Frankly, Passport was a pretty good name for this kind of thing, but as you know, that name’s been used already. 😉
OPs and RPs typically do carry the OpenID logo, but it’s mostly an accidental convention, rather than a standard approach. This is something that came out of the UX Summit that we hope to address in some UX guidelines for OpenID.
+1 to the “OpenID accepted here” branding concept. Exactly what I was thinking!
Thanks for the reference to i-names. I knew they had used the =, but I didn’t know they were also using the @. I’m not sure exactly why they differentiate for a business though.
Back to my anti-URL screed: URLs as identifiers works for geeks: people who have had the experience of buying their own domain name, buying hosting, setting up DNS, setting up a blog/CMS, etc. We understand how we can take ownership of, and control over, a domain name.
But that doesn’t extend to normal people. Normal people think of URLs as websites. Normal people, when asked to log in to a website using OpenID, must type in another website. That makes utterly no sense to the uninitiated. We’re asking people to change the definition of the deeply-ingrained concept that a URL is a website.
Until OpenID can look like an identifier that people can associate with solely being an identifier and nothing else, it will never be adopted by the masses.
About OpenID usability, I had drafted some forms last week in order to be consistent with Google report:
http://www.biologeek.com/ergonomie,openid/interfaces-didentificationenregistrement-openid-et-ergonomie/
It’s in French but forms are in English, let me know if it makes sense.
About Microsoft announcement, I second Max Engel, half a billion OpenID is useless if there are no consumers and if those users do not even know that they’ve got one!
Now how to improve it, EAUT is certainly a good thing but as Guillaume points out, OpenID doesn’t mean anything, OnlineID or WebID or NumericalID is much more descriptive. Initiatives like SelectorID are interesting to forget the problematic url part too.
Anyway, I’m still convinced that OpenID should be provided by states like physical identity cards, this way they can be certified. But our administration is so slow…
I, personally, am really, *really* annoyed when an OpenID supporting site tries to use the email address from my provider for me. The email address I will use differs from site to site (for instance, factoryjoe.com at elliottcable dot com is what I typed above to comment here). I often am ushered straight from the ‘enter your identity URI’ to ‘you’re registered!’ without so much as a chance to check the data that my OpenID provider offered.
Just my 2 cents.
Today there are roughly 6 user experience (UX) approaches being deployed or proposed to help facilitate adoption and usage of OpenID: http://blog.janrain.com/2008/10/openid-user-experience-ux-summit.html.
From the website operators and end users we’ve been talking with, they are most interested in faster and easier registration and login, not necessarily the OpenID brand. Longer term, they also are excited about the overall data portability aspects of “user centric identity” including OAuth, Portable Contacts, MySpace Data Availablity, Facebook Connect, etc. But we have to get the basic authentication piece done first and intuitively.
Some end users understand and prefer the OpenID URL approach. Some haven’t been educated about what OpenID is and how to use it, but might if properly educated. Some would prefer to just “click a button” from a known account (AOL, Yahoo, Google, MySpace, Facebook, Hotmail, etc.)
Perhaps we need to find a UX model that accommodates the needs of all these user personas, but is optimized and targeted at the largest potential user base with a progressive interaction model that evolves from mass market to specialized users. IMHO, approach #5 of the 6 approaches comes the closest to doing this, but we all need to hear from more website operators (not OpenID providers) and end users.
The other thing to remember is that the most challenging part of the OpenID UX is the first time registration/login. In the best practice for OpenID UX, the website operator cookies a user’s preferences, so that the next time they return to a site, their preferred UX and OpenID provider is pre-populated. This should then enable “single click login,” which is clearly what website operators and end users would like to achieve.
The OpenID Foundation and its members are actively soliciting feedback from website operators and end users, so please keep the comments coming.
Cheers, Brian Kissel, OpenID Foundation Marketing and Customer Research Committees
I think it can be an oxymoron especially when it doesn’t work for your sign in–the part where it’s their to streamline that portion of your online experience. Plus its tough to explain this to a friend who is not so tech literate. I hate going to another site to log in.
“apparently @yahoo.com email addresses already work with existing OpenID implementations”
Unfortunately, it’s still *only* Yahoo from the email providers. Hopefully this will change in the future as more people recognize the pattern that Yahoo! inadvertently enabled 🙂
“and no, Blogger doesn’t count”
Hey, _standing right here_ dude… 🙂
@elliottcable: Use a better OP then. http://myopenid.com lets you set up profiles, and you choose which one you give to that website.
As for more OPs, I’m not sure but I think the number of openid’s I now have (and don’t use) exceeds the number of email addresses I now have (and I don’t use most of these either)…
When flickr and googledocs, etc. allow openid rather than yet another provider open might actually become useful.
OpenID – interesting idea, but horrible implementation.
Wow, thanks for that. That’s a really original perspective. And glad you provided some ideas on alternatives or ways to improve it.
😛
I like OpenID. I already used it (more than 2x). But… I found this post while trying to find out what to enter on http://bitbucket.org/account/signup/ as a OpenID. And you know what? This post didn’t help at all.
Nice thoughts, pros and cons, and interesting tech stuff (no, I’m not a n00b, I’m a pro), but what’s the damn thing I have to enter for OpenID with e.g. GoogleMail? Here is the answer, and it’s worth more than all blabla’s before: http://weblogs.asp.net/meligy/archive/2009/07/28/small-tip-use-your-google-account-openid-url-but-what-s-the-url.aspx
To paraphrase Dave: OpenID – great idea, but horrible UX.