[OpenID] Combining Google & Yahoo user experience research

[Eric Sachs]

>> I can't find the page you're referring to
Well that's another data point on the usability of our login UI :-)

But seriously, go to www.google.com/a (note the /a) at the end.  Then in the
top right, click "Returning user, sign in here."  User's then enter their
domain name, and pick a destination page.

>> Did you experiment with this further?  Some data would be really useful.
That UI is live, and as you found yourself, it is hard to use.  What we have
found in practice is that user's have to start at their IDP's website, and
click a link that takes them to our site with a URL parameter that indicates
the domain of the IDP.

We have another live example you can look at.  Try this URL:
  http://sites.google.com/a/alertblue.com/testui/
That URL is for a webpage created by an enterprise whose email Google hosts
on our AppsForYourDomain offering.  But the owner of that site has allowed
some people outside their enterprise to access this webpage.  So when a user
visits that webpage, they might be one of three types of users:
 - An employee of that enterprise
 - An employee of a different enterprise that uses AppsForYourDomain (and
which might run its own IDP that authenticates users to Google via SAML)
 - A consumer user with a regular Google Account that the user established
manually
We are experimenting with different login UIs for this page, so you might
see different versions.

On Tue, Oct 14, 2008 at 11:47 AM, Nate Klingenstein <ndk at internet2.edu>wrote:

> 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/293362cd/attachment-0002.htm>