[step2] Re: OpenID Popup Extension - Draft 0

[Breno]

On Sun, Feb 15, 2009 at 11:14 AM, Allen Tom <atom at yahoo-inc.com> wrote:

>  Chris Messina wrote:
>
>
>> (2) Can we kill two birds with one stone here and make this the UX (as
>> opposed to popup) extension, and add stuff like language?
>
>
>  If we're going that route (which I generally favor), I think we should
> probably use UI as opposed to UX for the appropriate acronym. Since we're
> talking about the superficial OpenID experience here (rather than the
> holistic "user experience" -- which encompasses much more than just language
> and window mode), I think this extension should be called the OpenID User
> Interface Extension or OpenID Uniform User Interface Experience.
>
>
> I'm concerned about increasing the scope of the extensions, as both the
> Language Preference and PopupUX both seem to be very obvious improvements
> with universal support that can be implemented very rapidly by almost all
> OPs, so I would like to finalize both extensions quickly and to keep the
> scope limited so that we can move forward.
>
>
> openid.ns.ui = http://specs.openid.net/extensions/ui/1.0<http://specs.openid.net/extensions/ux/1.0>
> openid.ui.mode = popup|aural|braille|embossed|handheld|mobile|tv
>    (largely inherited from CSS media types, where "handheld" is
> differentiated from "mobile" by the capability expectations of the browser)
>
>
> I fully agree that we should address multiple form factors and modes,
> however I don't think there's an immediate short term need to formally
> specify this.
>
>  openid.ui.language = en_NZ
>
>   I have no problem with combining the popup and the language extensions
> into one, if there is consensus to do that.
>
> I do have a problem with expanding the scope to cover use cases that have
> not really been discussed yet. (accessibility, TVs, etc)
>

Ok. In the interest of expediency, we could at this point define only
ui.mode=popup which is extensible in principle without introducing any new
other use cases at the present.


>
>
>
>
>  Also, I might tweak this (section 4):
>
>  The RP SHOULD open the popup centered above the main browser window, and
>> SHOULD dim the contents of the parent window while the popup is active.
>>
>
> ...to suggest that if you DIM the contents of the parent window, that you
> also provide an indication of what's happening and how to cancel/escape the
> dimmed effect (i.e. if you close the popup and no communication happens back
> to the parent).
>
>   My concern here is that the RP and the OP would both be competing for
> the user's attention. I'd prefer that the user focus on the popup, and that
> the OP take care of the messaging.
>

I agree that we shouldn't have too much going on simultaneously with the
popup. However, it may prove useful for the RP to provide some context
"before the popup opens and the RP screen goes dim".


>
>
>  Should we also cover the case where the parent window is closed before
> authentication is completed?
>
>   Ah, I hadn't thought of this case.
>

This can be addressed as follows:

When the user completes the authentication and is returned at the RP, the RP
should proceed as follows:

Check if window.opener.location is defined and within its realm. If so, it
should close the popup after ensure that all side-effects (set cookies, etc)
that follow the login operation have completed.

If window.opener.location is not defined, not accessible (attempt to read it
throws a security exception, for instance) or not recognized to be part of
the RP's site, then the RP should try to load its normal landing page for
full-page redirects.


>
>
>  Lastly, typo in Section 5: "recieving" should be "receiving".
>
>   Thanks for pointing that, I'll take care of that in the next rev.
>
> Allen
>
>
>
>  Chris
>
>
>
>>
>> On Fri, Feb 13, 2009 at 7:51 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>> >
>> > I uploaded draft #0. Comments welcome:
>> >
>> > http://wiki.openid.net/f/openid_popup_extension_draft0.html
>> >
>> > I was really hoping to make the OP's default popup size discoverable,
>> > but I couldn't figure out how to cleanly embed the dimensions into the
>> > XRDS. Based on discussions at the Facebook meetup this week, it sounds
>> > like 450px width is the magic size, as both Google and Facebook
>> > independently chose 450px for their popups. My designers have indicated
>> > that 450x500 should be doable, so I've set that as the recommended size.
>> >
>> >  From a implementation standpoint, having the default popup size be
>> > discoverable might not be worth the added complexity.
>> >
>> > Based on the PuffyPoodles and MadStreams demos, it looks like the popup
>> > is already working well with iPhones, so perhaps we can just recommend
>> > that RPs just use the Popup UX for mobile devices as well as for
>> desktops.
>> >
>> > Allen
>> >
>> >
>> > >
>> >
>>
>>
>>
>
>
>
>
>
> --
> 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
>
> ------------------------------
> _______________________________________________
> user-experience mailing listuser-experience at openid.nethttp://openid.net/mailman/listinfo/user-experience
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "Step2" group.
> To post to this group, send email to step2 at googlegroups.com
> To unsubscribe from this group, send email to
> step2+unsubscribe at googlegroups.com <step2%2Bunsubscribe at googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/step2?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>


-- 
Breno de Medeiros
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090215/41a199f5/attachment-0002.htm>