[OpenID] Combining Google & Yahoo user experience research

[Nate Klingenstein]

Eric,

> Nick, I may have missed it in this thread, but did you indicate  
> which UI options are working better then others for your users?

As I mentioned, we've found no single best UI.  Drag-down lists that  
set long-lived cookies on selection are by far the most pervasive.   
You can see a basic example at the demo resource linked here:

http://www.switch.ch/aai/demo/

> I have only talked to a few RPs with a similar situation to your  
> own, and the most common approach was to split the login process  
> into two steps, where the first page asks for the identity provider  
> (which might even be the local website), and then the user is  
> redirected to their IDP's authentication page.  However a key  
> change was removing the password field completely from the first  
> page, otherwise many users do mistakenly type their IDP's password  
> there.

Yes, this has been our traditional approach.  I'm glad you've  
encountered a few RP's that have a similar use pattern; they're quite  
common in our experience.

> In fact, if you go to www.google.com/a you'll see we use that  
> approach for our GoogleAppsForYourDomain service.  The first login  
> page can then include buttons/dropdowns/selectors for IDPs, as well  
> as a text entry box for a user to just enter the domain name of  
> their IDP (and try to using any other hints from the browser or  
> browser history to suggest the IDP).

I can't find the page you're referring to, but yes, we've  
experimented with text entry boxes where the user is asked for their  
domain.  It's supported in a few ways in our standard distribution.   
However, it's not used often because our users have no concept of  
domains and questions such as "What is the right half of your email  
address?" or "Where is your university's homepage?" are confusing.   
You mention that in your own summary, in fact.

Did you experiment with this further?  Some data would be really useful.

> In terms of Google's research (and I believe Yahoo's) we were  
> focused on sites that had specifically chosen not to implement  
> federated login because of usability problems.  I don't expect  
> those UI guidelines to work for every website, especially for  
> websites who have decided to deploy federated login for other  
> reasons (like the ones you listed), and are willing to use a more  
> complex UI.  And those UI guidelines are complete overkill for a  
> website who is willing to just use a single IDP and completely  
> eliminate its own legacy login system.

For such a site leveraging Shibboleth, our guidelines suggest an  
immediate redirect to the associated IdP.  The trust fabric and  
protocols under the hood are still federated.  I disagree with John:  
I see two distinct advantages to that.  You only need to support one  
set of protocols and software, and if you do choose to open up your  
site to users from other IdP's someday, your identity system doesn't  
need to change.

Take care,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081014/3b0cf42d/attachment-0001.htm>