Scott Blomquist

Following Clickpass‘s lead, there are 3 key scenarios that a Universal OpenID Button needs to enable in order to gain widespread use on the web: 1) new user sign up, 2) existing user sign in, and 3) merge existing Identity 1.0 user with a new or existing OpenID user.

Despite the existing best practices for all 3 requirements (and many more), as you look around the web you’ll find implementations that demonstrate dozens of completely different takes on what it means to be an OpenID Relyer. One very important side effect of Clickpass’s approach is that their button essentially comes along with mandatory best practices. That is, any site which chooses to implement the Clickpass button will behave nearly identically to any other site that chooses to implement the button.

By necessity, this minimum set of behaviors will be very small–sites probably wouldn’t be as quick to get on board with the button if full-on AX support is required, for example. But the clear guidance that such a button program would provide would be invaluable in helping site owners understand what work goes into getting started with OpenID and doing it right.

Just to throw out a strawman to get some conversation going, I’d say that a Universal OpenID Button should start by supporting the three scenarios I called out above plus it should help users get their very first OpenID if they don’t already have one. This last bit might seem like it diverges from Clickpass, or even from the current practice of each site owner choosing which OpenID provider(s) to refer users to for whatever arbitrary reasons they like, but it doesn’t have to. Site owners could still choose to send their users to myVidoop.com or MyOpenID.com or Clickpass in the interest of either themselves or their users. Or if they don’t want to choose favorites, they could send their users to the OpenID Foundation for help in choosing a provider.

By the way, next post will be the one where I start going into deeper technical detail on how I think we can pull this off.

The great OpenID usability work that Clickpass recently launched and the reactions that followed have induced me to spend some time thinking about what this all means for OpenID.

The first conclusion that I reach is that Clickpass-style single-click single sign-on is almost inevitably the future of OpenID–it makes it trivially simple for even the least savvy user to understand how to sign up and how to sign in. And interestingly, Clickpass is not the first company to realize this–they’re simply the first company to tell a story that causes this to stand out to me as a particularly brilliant feature. Yahoo provides an OpenID button (whose obnoxiously typical terms of use require a 25 pixel moat around it), and Microsoft’s Passport Live ID has employed a button for approaching a decade.

The problem with all of these buttons is that there are bound to be so many of them. As in my article on annoying social bookmark icons, I can already begin to imagine the OpenID button area that we’re soon to start seeing pop up (and there are already some examples of poor re-inventions of the button-area):

The right way to solve this problem is for us all to agree right up front on a way for each publisher to only have only one button–an OpenID button. Clickpass has an implementation that’s more than halfway there, and I think that one possible future would consist of Clickpass having opened up their button to the point that a user who already has any other OpenID gets a first-class experience with the Clickpass button. I believe that Clickpass won’t ultimately thrive without being as open as possible and collaborating closely with the OpenID community, but from my brief conversations with Peter Nixey, it seems clear to me that they get that.

Another possible future (which is not mutually exclusive with the previous one) consists of the OpenID community coming together to build an OpenID button that does things right. Clickpass would certainly still have a business in providing added value over the community-owned OpenID button, but the community button would provide a non-proprietary alternative for those site owners who value openness over features.

I’ll follow this article up shortly with a description of the minimum set of features that would be required for a community button to take off.

Microsoft released Beta 1 of Internet Explorer 8 during MIX08. They’ve done some exceptional work during the 15+ months since IE7 shipped (passes ACID2 out of the box, implements some neat new JavaScript features, has moved the IE Dev Toolbar developer tools into the browser, and too many other things to list here).

My personal favorite feature is a thing that Microsoft calls “Activities“.

IE8′s web site describes Activities as:

contextual services that provide quick access to external services from any webpage. Activities typically involve one of two types of actions:

• “Look up” information related to data in the current webpage
• “Send” content from the current webpage to another application

They can be discovered and installed from anywhere on the web much like the search providers that plug into the search box in the upper right corner of any modern web browser.

To understand why this is my favorite IE8 feature, and further why I believe that every major browser will end up adopting this idea, let’s take a look at one of the scourges of the modern social internet–the social bookmarking icon collection:

This incomprehensible clutter is found below many news and blog articles and is supposed to help you bookmark the article for future review or to share it with your friends.

Unfortunately, if you didn’t already know that, there’s very little way for you to figure it out for yourself. And even worse, unless you’re so familiar with at least one of the sites that you know its icon by sight, you’ll never be able to pick which of the 26 little buggers to click on.

If you’re an avid social bookmarking user, you can probably find your favorite site’s icon somewhere in that mess. But if you’re an avid social bookmarking user, you probably already have a browser plug-in or bookmarklet that can do the same task–even on sites with fewer (or no) social bookmarking icons.

So it’s a polychromatic eyesore, and it isn’t helpful whether you know what you’re doing or not.

Before we get back to talking about Activities in IE8, I’ll point out that there has been some progress lately on consolidating the hideous collections into a single button and letting a central site worry about making sure everyone’s favorite bookmarking sites are supported. http://www.addthis.com is the first such site that I remember hearing about, and http://www.sharethis.com is doing some interesting work in the consolidation arena, having created an icon that they encourage all social bookmark cosolidators to use. The icon is apparently gaining some traction, judging by Google’s use of it on Google Shared Stuff.

Activities fit into this whole thing by giving each user the ability to tweak their browser’s context menu to include all of the icons for activities that they consider useful while not cluttering it up with dozens of icons for sites that they don’t care about. As you can see from the samples on the list in the picture above, there is a variety of things that activities can do beyond simply sharing a bookmark. The IE8 Service Gallery groups them into activites that Blog, Define, Find, Lookup, Map, Send, Share, and Translate, but the developer documentation leaves room for making up your own activity types.

It’s also incredibly easy to create new activities. You simply create an XML file that describes which URL to use depending on whether the user has chosen a page, selected some text, or right-clicked a link. You simply tell the Activity what extra info to send along to the URL, and off you go.

Far easier than getting all the news and blog sites or even just sharethis.com to include icons for all your favorite sites, and more in your control.