I’ve been having an interesting conversation with Alex Faaborg on the UI for Microformats. The UI explorations that he’s done are interesting but there is a problem. Not all Microformat UI should be presented the same way. In fact a uniform UI may limit the places that a web-designer can use Microformats. Instead of making the browser responsible for figuring out the right placement of the UI allow the page author to determine where the controls belong and provide the architecture to make consistency easy. In fact Alex illustrates this point very well in this article. Users want Microformat UI controls in the browser content and they want to control what it looks like.
In HTML there is a longstanding tag called <input> the tag gets input from the user and presents standard buttons, controls, etc. I would propose a complimentary tag called <output>. This would allow a page author to designate a location on the page that can output data to an external application such as a calendar, contact, etc.
This will allow the page author to specify where these features are and how they work to create the best user experience for that specific page. If the web-page is the application then the page author needs the flexibility to control the user experience. This will really help the adoption of both Microformats as well as a forward thinking browsers that supports such a tag.
What could such a tag look like?
<Output for=ID3 type=contact action=addContact showIcon=true iconWidth=16 iconHeight=16 value=”Add this contact to your address book” />
An alternative could be an extension of the Anchor tag…
<A for=ID3 type=contact action=addContact > <img type=contact width=16 height=16> Add this contact to your address book </a>
The ‘for’ is similar to the label attribute ‘for’ and associates the action with the microformat data. The action would be a pre-defined set of recognized and supported Microformat actions. The showIcon allows the browser to display the standard icon for an application. Note that the page author doesn’t know what application is being used so privacy is preserved.
Some possible issues that Alex brought up…
Consistency?
We need consistency and this is important but it should be a guidline not a rule. (Like the RSS icon). The browser chrome should stay out of the way of applications. Maps.google.com should be able to present contacts differently from people.yahoo.com. The page designer should be able to promote/demote the importance of a microformat action. If we paint all UI with the same brush it may hinder adoption. We can encourage UI consistency by providing good default styles and icons. We can also provide a standard and consistent menu such as File->Export ->Contacts as a fall back. If we force a particular type of browser UI into the page we will loose the possibility for consistency across browsers.
Barrier to entry?
By adding a single tag we have a very low barrier to entry. Sites that want to add it can do so easily.
Compatibility?
Non-compatible browsers will drop tags that they don’t recognize so the above examples can be backward compatible. You could go a step further and do something like:
<Output ><tag A/><tag B/> <NoOutput><A href=”AlternativeLink”> Download this contact </a> </NoOutput></Output>
Then A & B are used by browsers that understand the concept of Output and the link is shown by legacy browsers. This is the same trick that was used for Frames & NoFrames.
Security?
I agree that we need to think through the security vectors to make sure that we’re not exposing any applications to web vulnerabilities. However ‘security’ should not dictate how the design should work. The key thing for Microformat UI security is that an application can’t be launched through script, it has to be through a user action. (Like the file browse dialog or an RSS subscription). Don’t make the same mistake as Vista. Say no to confirmation dialogs, users don’t understand these and they get complacent and always press yes.
One final thought… We need to think about how a website can act as a Microformat consumer (not just a provider.) For example a site like LinkedIn or Basecamp should be able to be both a provider of Microformat data as well as a consumer of it. I haven’t seen anything on website being able to register to recieve Microformat actions but this seems like the logical step for Microformat UI,