[OpenID] OpenID education: RP vs OP?

[Eric Sachs]

I would probably be shot if I suggested adding such as interstitial
education page between a user's login page and the application they were
trying to access (like AdWords or Gmail) :-)
But for the potential E-Commerce RPs scenario we have focused on, there is
no need to educate the user ahead of time of the ability to use federated
login at a site.  The RP just does it automatically after the user enters
their E-mail in a login box.  The "education" that is still needed is to let
the user know in the future they don't need to type a password on the RP's
login box, but can instead choose "help me signin."  However, that is not
required, it is just a suggested "best practice" to the user.  That
"education" page needs to show a picture of the RP's login box for the
education to work properly.  Thus, I cannot generically show an education
page on Google that includes pictures of all the different variations of
login boxes that different RPs will use.  But in any case, it just was not
necessary to give them that education ahead of time in the UI flow described
in our research.

Our UI research may well not apply to RPs in other market segments, but both
Google & Yahoo have done separate usability studies where we spent a few
minutes with participants ahead of time talking about federated login and
the ability to use their Google/Yahoo accounts.  Even after just going
through that "education" all of the participants in our studies and Yahoo's
missed the special login buttons/icons/etc. and went straight for the
regular login box.  So that does not give us much hope for the ability for
big IDPs to "train users to look for a special button/icon" unless we did so
on a repeated basis to "beat it into their heads" until they eventually
started to notice it.  That type of forced education tends not to go over
well with users to put it mildly :-)

I have been trying to talk to potential RPs in a wider set of market
segments to see whether our research would meet their UI needs (in which
case this type of education is not needed), or whether they have other
requirements.  So far I have focused on use case 7-9 listed at the bottom of
here:

http://sites.google.com/site/oauthgoog/UXFedLogin/09nov-uxsummit

So far most of them think that research would meet their needs, but the one
request that a few of them made was to make it easy for end-user to do
federated login where there OP was a social network in addition to a large
number of generic E-mail/OP providers.  I published some ideas on that
earlier this week, but I do not have any usability data yet on whether it
would work.  However for this model, I do think it would help for the big
social networks to educate users to look for a login button for that social
network on other websites.

http://sites.google.com/site/oauthgoog/UXFedLogin/CombineGoogYahoo



On Fri, Oct 17, 2008 at 11:50 AM, Dick Hardt <dick at sxip.com> wrote:

> Allen / Eric
>
> In reviewing your research, there seem to be challenges educating the user
> they can use a Yahoo! or Gmail ID at another site. You also mention how the
> user is just trying to login.
>
> It would seem to me that educating the user about SSO / OpenID etc. when
> they want to login to an RP is NOT the best time.
>
> What about promoting OpenID at your OPs? When users come to your site, you
> can have some copy somewhere telling users that they can use their account
> to easily login to other sites sporting this nifty OpenID logo/button. Users
> interested in the functionality can click through pages to learn about how
> it works, what to expect when they get sent back to the OP, do any
> configuration etc. Then when they see the OpenID logo/button, they know what
> to do.
>
> This way when a Yahoo! user sees the OpenID button on a site, they will do
> what they learned at Yahoo!, and likewise for Gmail -- without the RP having
> to do the education, or flood their page with an ever growing list of OPs.
>
> -- Dick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081017/6887236c/attachment-0002.htm>