For the last two year's I've posted a picture from this bush in our front garden on Valentine's Day. The last two years there has been snow or ice either on Valentine's Day or the day before. However, today is bright and sunny and no snow. So this picture comes from the last week in Jan.
Saturday, February 14, 2009
Friday, February 13, 2009
OpenID UX Summit Musings
First, a huge thank you to Facebook for hosting the summit and live streaming the event. I wasn't able to attend in person, and being able to watch the wrapup and presentation of the OP and RP breakout groups made missing the event bearable.
Second, I think that for the OpenID Provider UI there needs to be a way for a RP to influence the UI. Basically, there would be one UI that is generic and totally related to the OP. This would be the default UI shown in the pop-up browser window. However, if the RP has a relationship with the OP, there should be a way for the RP to invoke the pop-up browser window such that some of the UI is customized to the RP. One feature I really like of Facebook Connect is that it gives clear UI context to what the user is doing.
I know for some OP's, its important to only allow customization from RP's that are in a relationship with the OP. This could easily be accomplished by using 2-legged OAuth and associating the UI customizations to the OAuth Consumer Token. The RP would then construct the 2-legged signed URL and load it into the pop-up browser window. The OP would verify the signature and make the necessary customization.
Here's one mock that should look familiar... (my apologies if this is what was discussed and drawn on the whiteboard. I couldn't "read" the whiteboard over the live stream. Final caveat; I'm no UI designer :)
In the default case, the RP's realm string would be displayed along with some generic text and a generic image representing the RP site. The OP image on the right would of course be unique to the OP.
In the case where an RP could provide customizations. The RP realm could be replaced by title text, the description could be specific to the relationship the user is establishing with the RP, and the RP image could be specific to the RP. To make these customizations work from a security perspective, the RP would need to obtain an OAuth Consumer token (and secret) via an out-of-band process (normal OAuth). The RP would then provide the OP with the necessary customizations during this provisioning process. These customization could include, RP realm, UI title text, UI description, and RP image. At UI display time, the OP retrieves the necessary customizations based on the OAuth Consumer token and displays the UI to the user.
With this kind of a model, the UI stays consistent and familiar to users, but also provides RP's with some ability to customize the content to their needs.
Second, I think that for the OpenID Provider UI there needs to be a way for a RP to influence the UI. Basically, there would be one UI that is generic and totally related to the OP. This would be the default UI shown in the pop-up browser window. However, if the RP has a relationship with the OP, there should be a way for the RP to invoke the pop-up browser window such that some of the UI is customized to the RP. One feature I really like of Facebook Connect is that it gives clear UI context to what the user is doing.
I know for some OP's, its important to only allow customization from RP's that are in a relationship with the OP. This could easily be accomplished by using 2-legged OAuth and associating the UI customizations to the OAuth Consumer Token. The RP would then construct the 2-legged signed URL and load it into the pop-up browser window. The OP would verify the signature and make the necessary customization.
Here's one mock that should look familiar... (my apologies if this is what was discussed and drawn on the whiteboard. I couldn't "read" the whiteboard over the live stream. Final caveat; I'm no UI designer :)
In the default case, the RP's realm string would be displayed along with some generic text and a generic image representing the RP site. The OP image on the right would of course be unique to the OP.
In the case where an RP could provide customizations. The RP realm could be replaced by title text, the description could be specific to the relationship the user is establishing with the RP, and the RP image could be specific to the RP. To make these customizations work from a security perspective, the RP would need to obtain an OAuth Consumer token (and secret) via an out-of-band process (normal OAuth). The RP would then provide the OP with the necessary customizations during this provisioning process. These customization could include, RP realm, UI title text, UI description, and RP image. At UI display time, the OP retrieves the necessary customizations based on the OAuth Consumer token and displays the UI to the user.
With this kind of a model, the UI stays consistent and familiar to users, but also provides RP's with some ability to customize the content to their needs.
Subscribe to:
Posts (Atom)