On Monday of this week over 40 people from Yahoo!, AOL, Google, Microsoft, MySpace, Facebook, Plaxo, JanRain, SixApart, Vidoop, and others came together at an OpenID user experience (UX) summit hosted by Raj Mata and Allen Tom of Yahoo. Many thanks to Yahoo! for hosting and all the participants for making the time to contribute.John McCrea of Plaxo has provided a great summary of the event. This UX summit directly followed an earlier meeting in NY City of the OpenID Content Provider Advisory Committee where UX was identified as one of the key barriers to broader and faster adoption of OpenID by website operators.
The OpenID community recognizes that UX is currently inconsistent and sometimes confusing for certain segments of the market.This summit and other OpenID initiatives are exploring ways that OpenID Providers (OPs) and website operators (relying parties – RPs) can work together to make OpenID registration and login more consistent and intuitive for end users.
Today, there are 6 general UX approaches that are in production or being proposed for consideration.
1. Standard URL type in box like at CNN Political Market, AOL’s Ficlets site, and the majority of sites today.The user needs to know their full OpenID URL (i.e. bkkissel.myopenid.com) and type it in to a blank OpenID login box.
AOL Ficlets Login Box
So far, this user interface has worked well for tech savvy users who understand the concept of an OpenID as a URL, and may already have personal URLs associated with their blogs or social networks. However, it’s been less intuitive for mainstream web usuers.
2. Icon based approaches like SourceForge and Mixx that either let the user click on the icon to pre-format the OpenID URL so that the user only needs to enter their account/screen name, or where clicking on the icon takes them directly to the OpenID provider for authentication.
This approach has improved the user experience since people don’t need to remember their full URL, they just need to remember their username.So in the case of AOL, a user only needs to enter their screen name, and the login utility inserts the screen name into an AOL OpenID format: http://openid.aol.com/screenname.But it still presumes that people know that an OpenID is a URL, or at least they don’t get confused by the login process that creates a URL from a screen/account name.Additionally, this hardwired approach is static, in that the website operator needs to continually update the login experience if new OpenID providers enter the market, or OpenID functionality evolves and expands.
3. Selectors like ID Selector (http://www.idselector.com/) and ClickPass (www.clickpass.com/home) where 3rd parties provide a widget for website operators to place on their login pages.The widget fits in the space allocated for the OpenID login text box, with a pull down menu to select the preferred OpenID provider.
This approach can work well because the login widget fits within the existing OpenID login text box footprint on a website, and it gives the user a wide choice of OpenID providers to choose from.Further, most login selectors are configurable by the website operator to select which OpenID providers they want to support, and to arrange their positioning in the widget to meet their requirements.Also, since they are hosted services, they can be easily updated to include new OpenID providers as well as new features and services with no effort required by the website operator.
However, this approach, with so many choices, can be overwhelming or confusing for end users.Additionally, the pull down nature of the interface can be confusing to some.Like option #2 above, it also presumes that people know that an OpenID is a URL, or at least they don’t get confused by the login process that creates a URL from a screen/account name.
4. Single OP pop-up login interfaces like Facebook Connect’s login button on theInsider.com.This is a new approach that is being pioneered by Facebook, but is being considered by many OpenID providers.Website operators would then place as many OP connector buttons on their login page as they felt was appropriate for their users.This is similar to what happened with RSS feed reader buttons.So a website could end up with Yahoo, AOL, Google, MySpace, Facebook, MyOpenID, Vidoop, and other dedicated single OP buttons on their login pages.
Facebook Connect Login at theInsider.com
This approach is compelling since the entire login process is optimized for a single identity provider.It allows the RP and OP to interact in a closely coupled way to take advantage of the richest set of functionality and data that the OP is offering and the RP wants to consume. For example, in the case of Facebook Connect and MySpace Data Availability, the OP can provide richer data about its users to the RP than just authentication and simple registration data.Additionally, the use of a pop-up interface is less confusing to users since they never leave the relying party’s website, all the authentication occurs within the pop-up interface.
However, the proliferation of multiple login buttons can be confusing to end users and a maintenance challenge for the website operator, keeping current with each OP in a one at a time fashion on update schedules dictated by the respective OPs.
5. Another approach being considered is an integrated multi-OP, in-browser-page widget. This approach is similar to #4 above, but where a number of OPs would agree to support the functionality of #4 with some kind of icon based selection interface like #2 & #3.This way a website only needs to deploy one multi-OP widget instead of a login button for each OP (as in #4 above)
Multi-OP Browser Widget Login (Velog example)
After the user selects their preferred OP, they are directed to the OP’s authentication website, and then returned to the RP’s website.If OP’s choose to further optimize this approach, they could instrument their OP service so that the OP authentication happens in a pop-up similar to case #4 above, and the user never visually leaves the RP’s website, which is much more intuitive and convenient for the end user.
AOL Authentication Box
If the user doesn’t see their preferred OP listed on the top tier menu, by clicking on the “use OpenID” link or icon they could be offered the option to select from other OPs or to manually type in their preferred OP.
Multi-OP Pop-Up Second Tier OpenID Provider List
The advantage of this approach is that there is one unified login experience for all the OPs on a given website.This could be more intuitive for end users and easier to maintain by the website operators.Users may be less confused since the in-browser widget approach doesn’t redirect them away from the RPs website.Additionally, since this is a hosted service, the heavy lifting of managing and leveraging all the capabilities and updates of each of the OPs, or system wide services like whitelist/blacklist updates, can be outsourced.Finally, if this approach were to become widely adopted across multiple websites, end users would find the process more intuitive in much the same way that most websites have adopted top and left hand navigation paradigms.
However, as with the Selector approach of case #4, the list of OP choices can be overwhelming.To attempt to address this, the proposed approach uses the concept of “progressive disclosure” where the RP selects which OPs are on the “first tier” menu based on the capabilities of the OPs and the relevance for their target users.If a user doesn’t see their preferred OP, they can always select from the next tier or directly enter the URL of their preferred OP.Again, the RP can decide which OPs go on the second tier list and how they are positioned on the list.
Further, since the Pop-Up utility remembers individual user preferences, they are presented only with the user’s preferred OP, as a default, on every return visit.So if a user is already authenticated at their OP, they can achieve “single click login,” which is the easiest and fastest solution for RPs and end users.
6. An integrated email & OpenID login approach that Google has suggested can accept an email address to identify an OP for “directed identity” login.Once the user enters their email address, they can either enter their proprietary password from the RPs legacy authentication system, or they can login via OpenID by having the login utility extract the domain of the OP from the email address.The user then gets redirected to the OP for authentication and returned to the RP.
The advantage of this approach is that everyone remembers their email address.Additionally, it’s scalable in that it can support any number of email domains.So if a user’s employer issues them an OpenID, they could login to a website using their employer-provided email account.This potentially reduces the confusion between login with a user ID and password, and login with an OpenID.
However, this approach doesn’t support login from an OP that is not also an email provider, such as MySpace and Facebook.To address this, Google has suggested adding MySpace and Facebook login buttons below the email as a way to address this limitation.However, this approach may not be scalable if RPs want to support future OPs that are not also providing email services.
Additionally, this approach doesn’t support login from an email address that is not linked to an OpenID provider.So if a user’s employer was not also an OpenID provider, the email address would not work for OpenID authentication.
Another key question that needs to be answered is whether end users prefer to type in anything at all (email, URL, OP domain name, etc.) or whether they would just prefer to click on a visual icon for their preferred OP.
So this summarizes some of the current and proposed approaches and thoughts on OpenID user experience.What the OpenID community would now appreciate is feedback from website operators and end users.What do you think about these 6 possible deployment models?What concerns, considerations, or recommendations do you have about each of them? What other approaches might you recommend?We look forward to your feedback.
OpenID Foundation Customer Research and Marketing Committees