"With the looming rise of the clipboard to transport XML, disguised as a text and using Microformats, the use of the clipboard to transfer data from one place to another is just going to explode. And by data, I mean full records including contacts, events, reviews, and eventually I'm sure, orders, invoices, quotes, and products."
He goes on to predict some of the key milestones that might on the way to mRc reaching a tipping point.
To add, some obvious candidates for mRc inclusion:
- Travel sites (BA.com, Orbtiz, etc, saving travel booking info into calendars - see Danny's take on this)
- Event booking sites (TicketMaster, etc - movie, theatre bookings info into calendar)
- Corporate sites (microsoft.com - event registration info, hq local office address)
- See examples in the wild
- Social networking sites (LinkedIn - copy and paste contact info into contacts)
- Corporate sites (microsoft.com - hq, local office address into contacts)
- See examples in the wild
There are quite a few that still don't 'get' the following, so at the risk of telling you something you already know, I just want to make sure your really 'get' what the excitement about mRc is all about:
mRc = Live data wiring
The microformats + RSS + clipboard (mRc) combo isn't just about copy and pasting static structured data into microformat-aware webpages and clients (though this on its own would pretty powerful stuff). The RSS piece brings with it the magic of 'liveness' to the data - the really simple magic of subscription. The point being that if the original data source changes, it changes at the destination (the subscriber). mRc makes dynamic data links - hence the 'Live' Clipboard name.
So for example, say I copy and pasted the Microsoft HQ address into my contacts app (either web-based or local client)...if the HQ address changed on the source webpage (where I copied it from) then when I next opened the record in my contacts I would then see the updated contact info. (Something to point out before you do here - if the original webpage is deleted the reading software should be designed so it doesn't break: it should use a 'last good' version of the dataset).
Granted, this example may not occur too often - Microsoft's Redmond address won't change for a while - but even here you can see the great value in using a simple and open data exchange format that all apps can standardize upon. Now, hCard isn't just for organizations, it's a people contact information format too...and people change their home street addresses, email addresses and cell numbers regularly enough to make the mRc-enabled scenario really
So I say unto you - go and microformat stuff! ('cause it's going to happen anyway).