openid implementation advice

Sun Feb 15 00:21:00 UTC 2009

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-without-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> 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> wrote:
>
> Hi:
>
> I'm a designer working on an OpenID (and FB Connect) implementation for
> 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 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
>
> _______________________________________________
> user-experience mailing list
> user-experience at 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
>
>
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
>

-- 
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090214/40e8b6d4/attachment-0002.htm>