openid implementation advice

Sun Feb 15 01:48:40 UTC 2009

No reason to beat the issues to death, everyone is aware of them... it¹s
probably better to focus on how much better it¹s become recently...

Taking the auth into a pop-up certainly works better once the pop-up is
launched, but in testing many times this would be a failed completion (users
would instinctively close a launching pop-up, and three users who did allow
it to launch were sure that the login was an ad ‹ a legacy of ads that look
like dialogs I guess). I am sure all of this will get better as people
become aware of openid, etc.

PS; the site is user-contribution-driven, so I¹m claiming safe harbor and
all that on the pugs :)

best,
Ben

On 2/14/09 4:21 PM, "Chris Messina" <chris.messina at gmail.com> wrote:

> Thanks for posting to this list Ben. It's experiencing like yours that should
> inform the guidelines that we produce for implementing remote auth in a
> consistent way.
> 
> I'd like to first ask about what is specifically hard to "embrace"? That is,
> is there one part of this user flow that's harder to embrace than another?
> Just the popup or something else?
> 
> As for the flow, I'm starting to see some behaviors that suggests that the
> entire authentication flow (for legacy accounts or OpenIDs) should happen in a
> popup, and with the smars that Luke outlined in his post [1], just update
> elements on the page that vary depending on logged in/logged out state.
> 
> Specifically, I was taking a look at the Get Satisfaction sign in experience
> (recently redesigned):
> 
> http://flickr.com/photos/factoryjoe/3279892028/
> 
> It looks great, until you click OpenID, when you get this message:
> 
> http://flickr.com/photos/factoryjoe/3279893768/
> 
> FAIL!
> 
> The irony is that if, instead of launching authentication from within a
> lightbox, they'd launched a popup using Luke's non-reloading fragment trick,
> this whole experience could be made seamless for the user...
> 
> So, I'm leaning more and more towards pushing towards a nice fat universal
> "Sign in" button that always pops a new window when non-legacy accounts are
> available. Over time, I think people will become more familiar with the
> experience and possibly with the button too (if we design it well) so that
> throwing a popup won't cause confusion.
> 
> Are you generally opposed to this approach?
> 
> Chris
> 
> P.S. What are those pugs doing in currentauth_4_openid_link.png??
> 
> [1] 
> http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-witho
> ut-leaving-the-page/
> 
> On Fri, Feb 13, 2009 at 4:10 PM, Ben Clemens <bclemens at currentmedia.com>
> wrote:
>> I really appreciate the reply, and I understand the large problems of
>> breaking a security model; I imagine the "big button that spawns a pop-up"
>> solution is where we will have to go. Perhaps I just have to accept the
>> "least bad" scenario given the limitations that exist, but it is hard to
>> "embrace." :) 
>> 
>> 
>> On 2/13/09 2:16 PM, "Luke Shepard" <lshepard at facebook.com
>> <http://lshepard@facebook.com> > wrote:
>> 
>>> First, these mocks look pretty sweet. It's clear you've done a lot of
>>> thinking about the experience of a relying party.
>>> 
>>> Steps 1,2, and 4 can all be done on your site, and for step 3, there's no
>>> need to break security policy by using an iframe. I think the providers are
>>> working on better designs that make it completely clear what's happening to
>>> the user so as to require minimal context from the RP. However, if you
>>> really want to tell the user what's happening before they click, then I
>>> suggest making an iframe lightbox explaining what's happening, then giving
>>> them a big fat Google button to click on, which spawns the popup. That would
>>> seem to accomplish the same goals.
>>> 
>>> If they weren't already, I'm pretty sure Google and others will start
>>> putting iframe-busting Javascript to make this kind of thing impossible.
>>> 
>>> We are working on putting together a best practices doc on the wiki as a
>>> result of the UX summit on Tuesday. Any feedback would be appreciated:
>>> http://wiki.openid.net/Details-of-UX-Best-Practices-for-RPs
>>> 
>>> On 2/13/09 1:10 PM, "Ben Clemens" <bclemens at currentmedia.com
>>> <http://bclemens@currentmedia.com> > wrote:
>>> 
>>>> Hi:
>>>> 
>>>> I'm a designer working on an OpenID (and FB Connect) implementation for
>>>> current.com <http://current.com> , a social news site from Current TV (a
>>>> cable TV channel). I've
>>>> consulted with Chris Messina and wanted to ask this group for advice on the
>>>> design I have so far.
>>>> 
>>>> The largest issue for me has been attempting to do parts of the process in
>>>> a
>>>> pop-up window. While the domain of the site the user is providing their
>>>> credentials to is a gigantic issue of course, the issue of *what exactly
>>>> current.com <http://current.com>  will use the account access for* is *even
>>>> bigger* for users I've
>>>> talked with. Users do not want to provide access if we will be adding items
>>>> to their account without their permission, and after a pop-up is launched
>>>> (or there's a redirect), I have no ability to message the user about what
>>>> my
>>>> site will do with the access they are providing. So, this version of the
>>>> design loads the external auth into an iFrame (now, excuse me while I cower
>>>> behind a mattress and prepare for the tomatoes and other thrown objects).
>>>> 
>>>> Thanks in advance for any feedback, advice, criticism, and an obvious, easy
>>>> way around these issues :)
>>>> 
>>>> http://labs.current.com/openid/currentauth_1_default.png
>>>> http://labs.current.com/openid/currentauth_2_openid_identity.png
>>>> http://labs.current.com/openid/currentauth_3_openid_auth.png
>>>> http://labs.current.com/openid/currentauth_4_openid_link.png
>>>> 
>>>> Ben Clemens
>>>> current.com <http://current.com>
>>>> 
>>>> _______________________________________________
>>>> user-experience mailing list
>>>> user-experience at openid.net <http://user-experience@openid.net>
>>>> http://openid.net/mailman/listinfo/user-experience
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> user-experience mailing list
>>> user-experience at openid.net <http://user-experience@openid.net>
>>> http://openid.net/mailman/listinfo/user-experience
>> 
>> _______________________________________________
>> user-experience mailing list
>> user-experience at openid.net
>> http://openid.net/mailman/listinfo/user-experience
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090214/6aaa552c/attachment-0002.htm>