OpenID and OAuth are the open, standards based and interoperable editions of this technology, but Yahoo’s deprecated BBAuth and FlickrAuth and others all came before. Also at the tail-end of last year came Facebook Connect, a system whereby websites can piggyback on Facebook profiles for building applications.

For example, take Fire Eagle. It’s a service that stores your location on your behalf, for use by other applications on the web. It uses OAuth to control access to that location; no application can see your location by default. When you visit a site needing your location, it asks Fire Eagle for that information.

Instead providing your Yahoo! username and password to this third party site (which would grant access to your entire Yahoo! account), you are taken to a special page on the Fire Eagle site, click a button to grant specific location permission and then jump back to the original site, which now holds a token to access to your location.

This process means that the site you shared your location with can’t access anything apart from your location (it can’t log into your Yahoo! IM account, for example, or send emails through Yahoo mail). Furthermore, you can log in to Fire Eagle and remove that application any time; you don’t need to change your password to do so.

It’s the future, it’s user empowering, and it’s going to be great. Eventually.

The user experience of this OAuth process — and OpenID alike — has been criticised a bit. Users don’t expect to be moved between different websites, but they are familiar with entering their passwords all over the place. The short ranty version of this article would go like this: If you stop whining and just get on with implementing the OAuth flow, users will get used to it and will be just fine. It’s is usable as-is, so shut up already. But this is the long, constructive version, so:

The user experience of OAuth and OpenID is immature, and can still be massively improved and smoothed out with concerted design effort.

Which brings me to Facebook Connect. Connect is a product as well as a proprietary technology. It’s a packaged and complete offering from Facebook, and as such, comes with a far more complete and polished user experience than the technology-focused, open standards have so far achieved. Polished and mind bogglingly stupid, in places, but, y’know.

Facebook Connect, whilst proprietary and product-specific and therefore irrelevant in the grand scheme of things, has UX that can be applied to OAuth and OpenID flows. If service providers support this, I think user experience gets much better, quickly.

How does Facebook Connect work?

The most common use case for Facebook Connect appears to be commenting on blogs, such as on Gawker sites. Rather than enter your details standalone, or uniquely register with a site, you log into Facebook, and Gawker uses those details instead.

So, you click the shiny ‘Facebook Connect’ button in the comments form, and an overlay appears:

This is the crux of the learning for OAuth. Rather than redirect to Facebook, this granting of permission happens right in the page in an embedded control.

It’s not quite as simple as this, mind. It’s ok that this action occurs in an overlay only because the user is already logged in to Facebook. No exchange of credentials takes place: The overlay is an iframe serving a page from Facebook’s server, so my current login cookie is used and there’s no need for Facebook to ask for my password. A malicious site would gain nothing by spoofing this dialog.

Since writing this article, Facebook have improved the behaviour of Connect. Now, if you are signed in you see an overlay as before, but if not signed in Connect opens a new window, where all usual browser functionality is available. This a huge improvement and fixes the complaints that follow.

Unfortunately, Facebook Connect then screws up. The whole point of delegated auth is that we stop users entering their passwords into third party sites. It has to stop. That means both actually entering their details into third parties, but also interface that gives the impression of giving your password to a third party. When you are not currently logged into Facebook, you instead see this dialog:

Millions of Facebook users, openly encouraged to enter their password into any site that asks. This is wrong. If the user is not already logged into the service, you should be redirected in a more traditional bounce between pages. That way browser-level phishing tools kick in, the URL in the address bar can be manually inspected by the user and, critically, the user is conscious of logging into a different service.

Facebook ranting aside, the first half of their Connect overlay UI would be very useful to enhance the user experience of OAuth and OpenID.

Here’s a hypothetical Fire Eagle app built into Last.FM.

In the current implementation of OAuth, clicking ‘Get Fire Eagle Location’ would redirect you to the Fire Eagle website, and then you’d redirect back again after clicking ‘Confirm’.

Instead, OAuth apps should do this by default:

No redirect, lighter weight UI and more responsive feedback. This, I think, is something that OAuth APIs should support out of box along with their other language wrappers; provide drop-in support.

Now, this behaviour applies for logged in users only. If you’re not logged in to Fire Eagle for any reason, you should still be moved to the separate site as before. We need to stay strict on keeping users spatially aware of where they are entering their passwords, otherwise the whole effort is undermined.

Overlaid OpenID

With one example down, here’s a mock of how Open ID could benefit from the same integrated flow, this time working with Dopplr, since they already support Open ID:

If not logged in to Yahoo, you get a prompt and just as before, are guided to step through the regular, separate-site process to sign in:

Clicking ‘Sign in to Yahoo!’ would take the user to Yahoo’s standalone page.

How to make this happen?

For this to happen, services need to provide support for it; it can’t be done just at the client side. The dialog-sized interfaces for authorising applications or logging into sites need to provided, and they need to support the ‘break out to enter passwords’ flow. But, sites like Fire Eagle already provide a mobile-scale version of the auth page, so further variants are not a major hindrance.

It also needs a JavaScript component to handle the UI side. With a bit of luck, this only needs to be done once and shared between projects.

The core technology behind OAuth and OpenID is pretty robust. Both have major adopters like Yahoo and Google. OpenID has a bit of a bit of a way to go before users need it, perhaps, but regardless, it’s well into the same phase where user experience needs to be a concerted effort, and the status quo needs to be challenged.

Everything in this post is just a small step from what we already have, it’s just smoothing out the edges. Maybe that’s enough, but I suspect there’s a long way to go and a wealth of other ideas out there.

The curious thing about this is that really, tabs suck. They always existed as a simple hack around the operating system’s (Windows) inability to handle many windows together. The taskbar got full too easily, and when 75% of the items were browser windows, it all became unmanageable. As a result, tabs went into every browser on every platform, effectively providing a second, browser-context-specific taskbar.

The problem now (and likely then as well) is that the idea of one single ‘browser context’ is bogus. Browsers are now used for such a variety of tasks and applications that it makes less sense to keep, for example, Gmail and Google Calendar in the same context as a set of blogs you might be reading. Your cycle of looking at those pages is different. Mail more regularly than Calendar, and the blogs might just be a reading list to refer to later. Whilst browsers were very quick to add tabs as a feature, non of them have worked them into the idea of working contexts. New items always open in your last used window. Even if you manually break Gmail out into its own window, the moment you open a link you’re putting a reading list of pages into your email context. Tabs are implemented in a physical, window based manner, rather than in a workflow based manner.

On Mac OSX specifically, there’s an addition problem (actually, physical). The otherwise quite-useful Exposé function doesn’t work with tabs in any application. So whilst in Pages, Fireworks, Preview and so on I could hit F10 and see all my documents together, the tabbed browser hides all the content away behind tabs.

Which is a roundabout way of getting to a point. I’ve turned off tabbed browsing. Switched back to the old way of having each document or application in a separate window. Switching between then with Cmd+` rather than Cmd+Shift+], gaining the ability to see them visually with a swift tap of F10, and losing the recurring bug of thinking I’m finished with all the documents in one manually created context window, only to find the music stops when I accidentally close Last.FM.

To defy my muscle memory for hitting Cmd+T, I’ve used Mac OSX’s excellent Keyboard preferences to override ‘New Window’ to Cmd+T, and New Tab to Cmd+Option+T.

It’s just an experiment. Sometimes you do want tabs to keep things under control, for example working through a feed reader, opening links for reference later creates a single ‘reading list’ task, and you wouldn’t want dozens of those individual pages cluttering up the rest of the desktop. There will always be exceptions. But since the browser software has failed to handle work contexts properly, I think reversing the default behaviour is the way to go.

Initial reactions are that this is easier to manage, results in less accidents and no accidents in losing windows (Safari has a ‘Reopen last closed window’ option, but is less graceful with tabs).

Note, this problem with tabs is just a result of needing to break web applications and documents out of the browser context. Efforts like Fluid (a WebKit based browser that creates standalone executables for specific websites) also help break out these contexts for apps you use regularly, but is less suitable for infrequent or new apps. Also, this is not to say that all tabs are broken. Tabs in IM apps like Adium still work me, because the amount of content open at one time is fairly small, and managing two work contexts (‘Work Conversations’ and ‘Personal Conversations’) within a single window interface is trivial. The web browser falls down because the amount of content and the number of contexts now exceeds what I can manage.

We could build better browsers, but it strikes me that the better first action is to step back and stop bypassing the capabilities of the host operating system.

There are a few things I’d like enhanced: More keyboard shortcuts for launching/pausing VMs, the ability to override keyboard shortcuts (so that ⌘+⇥ will work even when Windows has focus, for example). But though those would be very functional and useful enhancements, my biggest grip is mostly aesthetic.

On the Mac, windows don’t have borders. The edges are instead highlighted by the subtle shadow effect on each window. Parallels, for a reason I don’t quite understand, includes 2 pixels of white margin and a 1 pixel black border around the VM workspace. Frankly, it looks yucky. It also proves a pain when trying to set an optimal resolution for the VM. Rather than run fullscreen I prefer to run in a custom-sized Window (you can set custom screen resolutions before boot in the Virtual Machine options).

On my MacBook Pro, this would ideally be 1440x800 pixels (allowing space for the Parallels title bar, OSX menu bar and my Dock). Unfortunately, the margin and border around the VM workspace pads the Window out beyond my screen size, so I must instead use a smaller width. But resolution widths must be multiples of 8, so the smaller width doesn’t fit flush with the screen width.

Yes, I’m being very pedantic. But really, I don’t think it’s unreasonable to ask for a bit of polish on the software I use daily.

I’ve actually been far more interested in the less visual enhancements: Tasks being moved into a centralised service for Mail.app and iCal (and anything else) to share, a central feeds service (ala the RSS Platform in Windows Vista, I presume) might mean we don’t have to manually subscribe to Podcasts in iTunes anymore if it could just query a central repository for music enclosures (and likewise for pictures in iPhoto).

Tonight, I read through Impulsive Highlighters, a blog full of leaked Leopard screenshots. Lots to appreciate on the evolutionary side of things. Particularly, I noticed this (screenshot from Impulsive Highlighters):

This kind of ‘info bar’ UI is very appealing indeed, and I would love to see it used to fix one of my pet-hates with OSX: Application installation.

Yes, you read that right. Installing Applications in OSX is so elegant and smooth it is near theraputic. Drag, drop, run. It’s a thing of pure UI beauty. Except, not everyone copes so well with drag-and-drop. Sure, the percentage of Mac users is higher by far (since they’re trained in a world where drag and drop actually works reliably) but I wouldn’t fancy telling my Gran to do that. And I would have loved for her to have a Mac rather than a Dell. Ditto my parents.

The use of D&D as a primary means of user interaction is odd generally. Normally it is in addition to something else, a means of intuitively bypassing button and click based interaction for those who want it. In all the recent discussion about drag-and-drop in web applications, it’s been emphasised a lot that you should not (nay, must not) use drag-and-drop in place of everything else. Your functionality must not depend on drag-and-drop since fundamentally it’s not accessible enough. Yet the glorious easy installation selling point of OSX breaks this rule (you can of course go Edit->Copy and then Paste into the destination, but I don’t consider that overly intuitive).

So, here’s a mock-up of what I’d like:

This ‘Copy to Applications’ button would be displayed at the top of any Finder window for any mounted Disk Image that contains an application. Not only does it make it very clear for less drag-and-drop trained users to install an application to their hard disc, it would make it even easier for existing users to install applications to the most common location.

Indeed, over the life of Mac OSX and since the replacement of the pinstriped iMacs many years ago, the decorative pinstripe backgrounds on toolbars and menus have slowly and subtly faded. In the case of the menu bar, replaced entirely with a snappy looking glossed over gradient.

Since looking forward to upcoming OSX releases is the most international of all sports it’s been noticeable that a number of people (non-specific) are crying out for the outright death of the pinstripes. I’m not one of them.

OK, I will say outright that the dominating pinstripes from, say, Jaguar do now look rather ghastly and have aged horribly but in Tiger things are subtle and I honestly rather like the current balance (certainly with the gloss menu bar to tone things down further).

But what happens when you take the stripes away? You’re left with grey. Blocks of grey. In fact, if you install Uno you can see for yourself. The loss of the detail makes menus in particular stand out as being flat and dull and is thoroughly inadequet. As indifferent as I am towards the Brushed Metal window style, the bland menus and toolbar backgrounds turn me off Uno right away.

Of course, Apple surely know this – they’re not exactly dunces when it comes to design (although they are persisting with those ghastly grey buttons from Mail.app and introducing them to at least Preview.app in Leopard too). But if you take the current, subtle pinstripes away, what do you swap them for? A gradient? That won’t get tired quick… not at all.

This weekend at @media I finally got to show off to Tantek some UI design I’d been doing for putting user-focused microformats discovery into web browsers. I’ve been sitting on the sketches for about six weeks due to time commitments at uni and general blogging laziness. For a while I was going to try implementing it myself. Excuses aside, I didn’t post it. This morning, Jon Hicks pretty much did. Oh how I laughedcried.

To my relief there are some quite important differences between my interpretation of this idea and Jon’s, so really it’s all worked out well as a motivating factor to finally get this posted! I recommend reading Jon’s post too.

So, this is a concept for putting Microformats ‘auto-discovery’ user interface in a web browser. Any web browser (although the sketches were original conceived as a Firefox extension). Most importantly, this UI is focused on providing functionality to users with no knowledge of a Microformat, nor any need to understand the underlying formats. By which I mean almost everyone who uses the Internet.

I’ve released the design rather than build it as I have no knowledge of writing Firefox extensions and it’s likely too complex to use as a first ‘teach-myself-XUL’ project. Plus, I’d never actually get around to doing it.

Presenting Microformats in Web Browsers

This is all based on the hCard and hCalendar microformats.

Discovery

The presence of hCalendar data is indicated with a calendar icon in the location bar, and hCard with a ‘contact card’ icon (similar to that used by address book applications on Windows and Mac OSX).

Note that we’re being consistent with feed discovery (which could of course be extended to treat hAtom as a first-class feed citizen too). Users are already being trained to look at the location bar for for additional page content.

Again, with this being designed for my Dad to use, the terminology used is ‘Calendar’ and ‘Contact’ not ‘microformat’.

Clicking the Calendar or Contact icon will invoke the corresponding interface (below).

Events

Events are listed in a simple window similar to the Download Manager interfaces of Firefox or Safari. They should be sorted by start date.

Events are summarised with three lines of information, in some order of importance: The event title, location and date are all displayed where available. In cases where some of that information is missing then a less important field could be displayed instead (such as the URL for the event, although the event title could equally double as a hyperlink to the event URL).

To the right of each event listing are three buttons. Working right-to-left, as the outermost button is the most important:

• “Add Event to Calendar”. This converts the hCalendar microformat into an ICS event file and opens it locally on the user’s machine, where an installed calendar application will handle it. This should probably be overridable to support Web-based calendars such as Google Calendar.
• “Add Event Location to Address Book”. Where the hCalendar location is represented by an hCard, the location can be converted into a vCard and opened on the local machine (invoking the default address book application)
• “View Map of Event Location”. Invokes a mapping service (such as Google or Yahoo! Maps) using information from the location field. In Firefox, this could be customisable using the native installed Mycroft/OpenSearch Search Providers. This particular icon could be a lot better!

Ideally the interface should also support drag and drop of each event’s icon onto the desktop or into other applications to create an iCal event file.

In the status bar of the Events window is a “Subscribe to Calendar” button, which should pass the current page to Technorati’s hCalendar pipe to create a subscribable iCalendar.

On the Mac this should open the Technorati URL with a webcal:// prefix, rather than http://. On other platforms it might be preferable just to present the iCalendar URL to allow copy and paste into the user’s calendar application (depending on what Windows Vista’s iCal clone expects).

hCalendar doesn’t facilitate logos for events, so a generic ‘Calendar Event’ icon is displayed. This should ideally be the system icon for .ics files. Potentially, a logo icon could be extracted from a location hCard (suboptimal) or perhaps from the favicon of the event website.

People & Places

As for Events, hCard Contacts are listed in a simple ‘download manager-esque’ window. Contacts should be sorted by name (the illustration isn’t sorted, err, whoops).

A special exception to this sorting is the hCard of the page author (contained in or containing ADDRESS elements), which is bumped to the top. It seems reasonable to predict that users will be most interested in the author’s hCard, rather than that of blog comment contributions or blogroll entries.

As for Event listings, buttons on the right hand side offer functionality to open a vCard with the default address book and open a map for the hCard’s street address (where present).

It could be useful to provide other buttons for contacts. hCards can embed information about telephone numbers and IM screen names which could be used to invoke other applications such as diallers, Skype or AIM. However, whilst I’d love to see that functionality I’m reluctant to clutter the example illustrations.

Icons next to contact names should use the logo property of the hCard (I think), but if that is absent a fallback method could load the user’s Gravatar or the favicon found at their URL.

And that is my idea for microformats in web browsers. Consider the lesson about publishing on time well and truly learned. Ahem.

This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 England & Wales License. In the event that you want to implement this and can’t meet the Share Alike requirement for commercial reasons, contact me. Lets see how far sharing can go for now though.

Updates

• There’s now a page dedicated to µF User Interface on the Microformats Wiki

I fall into the camp of people who’re, to be honest, a little under-excited about Vista. I use both Windows and Mac OSX in fairly equal part and whilst I can plenty appreciate that Vista is going to blow the socks of XP, that isn’t enough to make me go ‘Wow’.

I suspect that Vista’s eye candy is just fine, that two visually different but functionally identical implementations of Alt+Tab are all very well and that as a .NET developer the toys in the back-end will be great. But none of this excites me. At all. Perhaps that’s because the Mac has the user experience already sussed, perhaps Microsoft’s efforts are going in a different direction from me generally, but all I see when I look around the web for news about Vista fails to grab me.

What does interest me at the moment is the day-to-day user experience working with my computer. Things that (typically) the Mac does very well: Drag and Drop, Bluetooth, Unicode via keyboard shortcuts, consistent and clever UI for the character map and system-wide spell check. These are not glamorous features, but these are tools that I use. More than I use Dashboard or Konfabulator and more than I’m going to use Vista’s Sidebar, Gadgets and 5-star file ratings.

What’s the one feature of Vista I’ve seen that’s made me think ‘Ooh that’s really clever’? The per-application Volume Control. How fantastically cool and useful is that? Possibly the most unglamorous function of any operating system and Vista produces an inventive feature from it. Give the person who did that a medal.

But this leaves me thinking about the places that Windows really sucks. Somewhere, surely there must be someone improving Windows XP’s truly awful Bluetooth UI.

For example, I take a lot of photographs with my mobile phone (a Sony Ericsson K750i). I can select a batch of pictures in the phone’s file manager and hit ‘Send via Bluetooth’. To transfer them to the Mac I just pick my iBook from the list, the Mac prompts me to receive the files (and offers a check box to ‘Accept All’).

But, to receive the files on Windows XP I have to open a wizard first, then initiate the transfer from the phone. What’s more, it’s a wizard to receive just one file at a time. It’s an horrific example of underdevelopment. The result is that I barely use Bluetooth on XP.

This has a big impact on the way I work. When I transfer the pictures to the Mac, it’s far more convenient to send them directly into iPhoto than copy them over the network to use Picasa on XP. Bluetooth has become a huge point of entry for data onto my computer – more than CDs and memory cards – and XP really sucks at it.

Little things like this make a real difference to me day-to-day. I’d love to see a little light shed on what’s going to happen in Vista. For me, it’s these little things that will be the difference between upgrading my PC or buying a new iMac.