openid implementation advice

Sun Feb 15 02:59:27 UTC 2009

Hmm, ok.
You mentioned user testing. I'm surprised that an act initiated by a user
would cause them to instinctively close the popup.

I was thinking about this, and I think that we need to address this with a
button or link that better describes what's about to happen. Here are some
rough mockups:

http://www.flickr.com/photos/factoryjoe/3280478828/
http://www.flickr.com/photos/factoryjoe/3279658729/
http://www.flickr.com/photos/factoryjoe/3280481558/

And for good measure, here's how to sign out:

http://www.flickr.com/photos/factoryjoe/3279663105/
http://www.flickr.com/photos/factoryjoe/3280495172/

Considering what Jacob Nielson has said about popups, I think this direction
is worth pursuing (even if the arrived upon conclusions don't look precisely
as I've mocked them up).

Unless you warn them, Web users are likely to expect the new page to load in
> the current window. Unexpected surprises can be fun, but not when you're
> browsing the Web.
>

http://www.sitepoint.com/article/beware-opening-links-new-window/

What do you think?

Chris

On Sat, Feb 14, 2009 at 5:48 PM, Ben Clemens <bclemens at currentmedia.com>wrote:

>  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-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 <
> 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
>
>
>
>
> _______________________________________________
> 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/631fa9bf/attachment-0002.htm>