At the request of a few different people, I've zipped up and made available the source code for the microcontent viewer/Live Clipboard proof of concept I posted a few months ago. Everyone interested can find it here. Enjoy.
It makes me a happy boy to see dialogue occurring on the best way to share and syndicate rich data publicly on the Internet. I truly believe that when this bridge it crossed it will enable the next wave of Internet technology evolution/revolution, and I'm glad people are thinking in this direction so this happens sooner rather than later. I also think Live Clipboard will be a nice catalyst for the whole idea because it empowers microformats in such a dramatic way. All of this technology is still in its infancy, of course, but these are the types of conversations that need to happen between early adopters, developers, and entrepreneurs before it can go mainstream.
One thing that seems to keep coming up, and understandably so, is the idea of securing syndicated data. For example, if I wish to publish certain parts of my contact information such as my email address, but keep other parts private and secure, such as my mobile number, I can't very well publish a vcard out to the Internet. Even hiding certain chunks of it with stylesheets won't hide the content from aggregators, search engines, and people who know how to "View Source". It's simply not an effective security mechanism.
Related to this is the sticky question of whether the data should be embedded directly in the content (or page) itself, or if the content should simply contain a pointer to the data (in the form of a URI). The first approach is demonstrated in my little Microcontent Viewer example from a few weeks back, the second approach is demonstrated by i-Tags.
The concept of embedding data in content and how to secure it is a tough one, and I struggled with it for a long time. I wondered if the URI-only approach was correct so that it could actually be an application at the other end of the URI which would be able to ask the reader who he was and provide the appropriate subset of data. However, that raises all kinds of problems with user authentication and firewalls. For example, if I publish a blog post that contains a vcard which points to a URI inside the firewall, that vcard becomes useless to anyone on the outside, so what's the point.
Personally, I finally decided a few months back that a hybrid approach was needed: I would embed only the public data that anyone should be able to see into the content itself, but also provide a URI that can be used to retrieve the full set of data (or the subset that the reader has been allowed to see). It could also be used by the reader to refresh the embedded data when the URI endpoint is available and online. This is exactly the approach taken by my Microcontent Viewer example, although the refresh piece isn't hooked up.
I'm still pretty convinced that embedding public data in content is a good way to go. After I published my test post Technorati picked up the embedded microcontent and I was able to find it using their microformat search, and get pictures and all. See the results here. It actually added value to the content, which was very cool. Progress!
The URI endpoint part of this is much trickier, but is also much more interesting. It's the secret sauce that's going to really kickstart some wild revolutions in online technology. I believe that an open source application is needed to share, provision, and publish content at URI endpoint's, and that application is currently and secretly in the works but won't be released until it's ready. For securing data, it uses an ingenious solution thought up by M. David Peterson to securely publish URI endpoints, see his post here for the technical details.
The beauty of this hybrid solution is that you can have your cake and eat it too. Users who you don't even know exist can use the subset of your data that you make public, and public applications have data to work with but only that which you want the entire world to be able to see. The embedded microcontent portion enables applications like the Technorati microformat seach to pick up and use it. However, if somebody wants to get to know you better, they can send you a request in the form of an LLUP message and you're then able to personally decide if you want to allow more information out to that individual or not, and at what level.
There are so many more goodies that this will enable in addition to fresh data. You get to maintain an actual list of "trusted subscribers", and actually TELL them when you update or create content instead of waiting for them or their feed readers to find it. You'll be able to tell EXACTLY what people are doing with your data. You'll even have the ability to let THEM edit it, and tell you about it, at which point you'll be able to determine if you want to accept their changes or not. (I can't wait for the day when somebody I trust can update their contact info from one of my blog posts and it will update all of my other blog posts as well as Outlook, Gmail, and my Blackberry.) All the promises of push will be fulfilled when this domino falls.
Dion Hinchcliffe, a great writer and one of the few bloggers I make it a point to read on a regular basis, has done a wonderful job of outlining one of the primary barriers in front of this technology, which is the lack of a decentralized identity system. A decentralized identity system is vital before we can even think about securely sharing data. And while I certainly respect the efforts that are out there such as OpenID as SXIP, I think that the misguided efforts by companies like Microsoft and Google are going to derail any attempts to unify identity in the short term. I think the catalyst for change is going to be the point in time when people can see actual tangible benefits from an decen tralized identity system, in the form of new capabilities that such a system baked into core software can bring.
I've got some great big surprises in store in this area in the very near future, but I won't release anything until it's polished and ready. First impressions are pretty important, ya know ;)
It's the kind of thing you don't really think about when you're knee-deep in 
code, but Live Clipboard is really a new paradigm for the Web and it takes a while for people to adjust and digest everything, let alone use it effeciently. After I posted my embedded microcontent/viewer post, I started realizing from the feedback that people didn't really know what to do with it. This is an attempt to explain, in end-user terms, how to use Live Clipboard.
To use Live Clipboard you need two things: content to copy (the source), and somewhere to paste it (the destination). For this example I'm going to use the viewer I wrote layered on top of an HTML file with embedded microcontent as the source, and Ray Ozzie's Live Clipboard demo site as the destination. You can follow along in your own browser if you'd like.
Step 1: Copying Content
I'll be using http://www.xformats.org/MicroViewer/microContent.htm as the source. It's an HTML file that contains embedded microcontent, and links out to the viewer I wrote, which means it ends up looking like this:
The blue box on the right contains the content that was extracted from the embedded microformats. You can do other things with it such as map an address or make a call using Skype, but we're going to focus on the Live Clipboard button in the lower-left, which looks like a pair of scissors on an orange background: 
Copy Method 1: Selecting and using Ctrl+C or the Edit Menu
There are two ways to copy the content using Live Clipboard. The first, and what I assume most people will end up doing at first, is to click the icon, which selects the microcontent, and then either press Ctrl+C or go to the Edit menu in the browser and click Copy. This basically acts just like Windows. When you click the icon, the viewer will change the look of the box containing the microcontent to let you know that you can go ahead and copy the content using Ctrl+C or the Edit menu:
Once you use Ctrl+C or the Edit menu to copy the content, the microcontent gets stuffed into your operating system clipboard. You can even look at it by pasting it into Notepad or something, but it won't make a whole lot of sense--it's meant to be used by a Live Clipboard destination.
What's interesting is that although I think this behavior is the most intuitive, most new users don't seem to realize that you can do it. They all seem to end up using....
Copy Method 2: The Right-Click Context Menu
With this method, you use the same icon as before, but you right-click it, bringing up the browser context menu:
Clicking "Copy" on this menu will also copy the microcontent to the clipboard.
Step 2: The content's copied, now what?
Now that the microcontent is on the clipboard, we need to paste it somewhere. I'm going to use Microsoft's Live Clipboard demo site:
The list of boxes on the left are basically receptacles for storing microcontent. Scroll down until you find an empty one:
You have two options now for getting the microcontent you copied to the clipboard into this receptacle (by the way, we really need a name for these endpoints). The first option is to click the Live Clipboard icon to hightlight and then press Ctrl+V or use the Edit Menu to paste the content in. This is what the receptacle looks like when it's selected:
Or, you can right-click the Live Clipboard icon and click the Paste menu item, like this:
After you do either of those things, the microcontent that you copied out of the other site will show up in the receptacle and look like this:
That's it, you're done! You're now officially on the cutting edge of Web technology. Now go demand Live Clipboard integration from your vendors ;)
P.S. This is all developer technology preview-stage stuff, so you will probably notice some rough edges. For example, sometimes I have to close my browser and re-open Microsoft's Live Clipboard demo site before I can successfully paste in content. I'm sure this will be smoothed out in time, just giving you a heads-up.
P.P.S. There has been some discussion lately on the Live Clip mailing list about the best way to visually indicate to users what they can do with Live Clipboard. If anyone has any feedback in that area please share!
This post is a proof of concept--I've embedded microformatted content into the text of this post. If you run this page thru a microcontent viewer you should be able to see and use the microcontent. There aren't, to my knowledge, any viewers out there yet, so I ( this is my vcardJason Kolb jason.kolb@gmail.com 800 555 1212
) wrote a simple one that supports events and contacts (hcards and hevents). Try viewing this post using the microcontent viewer I wrote using this URL:
Go ahead and play with the viewer a little. Click the links, map an address, make a call with Skype, copy and paste contacts using Live Clipboard. (Anyone who's never used Live Clipboard before should read this other post for a step-by-step.) It's purely Javascript and CSS-based, which makes it very simple to plop on top of any AJAX application out there (including RSS readers). It's also a small piece of a larger project I'm working on, but I wanted to throw it out there because I see a lot of misunderstanding right now about the potential of microformats. Although I think it's very cool that search engines like Technorati are beginning to understand and aggregate microformatted content, that's only half the equation. The other half is that we need to allow PEOPLE to use microcontent as well. This post is an example of that capability. Viewing this post with a compatible viewer gives the reader the ability to not only read the text, but to do things with the content as well. (To my knowledge this is the only public text in existance right now with embedded microcontent, although I'd love to learn about some more examples!)
Admittedly, there aren't many fun things to do with microcontent yet. However, it's very enlightening the first time you move data around between applications using Live Clipboard. Try copying a contact out of this post and pasting it into Ray Ozzie's Live Clipboard demo site. Another site that supports Live Clipboard is M. David Peterson M. David Peterson m.david@xmlhacker.com 800 555 1212
's Global Clip demo (which is super cool because what you paste in gets stored in Amazon's S3 online storage service). The sites that support Live Clipboard are a little rough around the edges at the moment, but I would assume that things will start coming together nicely over the next six months.
Here's an example embedded event just for kicks: Web 2.0 Conference
. Just to give you an event to copy & paste using Live Clipboard.
To me, this is what microformats promise. They enable us to turn regular old content into rich media, with little to no effort on the part of content creators.
Now, let's have a little more fun ;) You can actually use the viewer I wrote to look at things other than this blog post. You can either hit the viewer directly using http://www.xformats.org/MicroViewer or you can append the URL to the query string to automatically load up a page like I did with the link to this post earlier. Go find some microformatted content and plug it in, here are some links to content that I found from poking around on http://www.microformats.org:
http:/ /www.crowley.nl/hcard.html - An example vCard
http://www.iowamilitaryveteransband.com/members/ - This one takes a while to parse, it's got quite a few contacts.
htt p://www.jasonkolb.com/about.html - My vCard.
You can also use http://microformats.org/code/hcard/creator to create your own vCard that can be embedded into text like I've done here.
Disclaimer: if it doesn't work or your computer bursts into flames or you break out in a rash or something, tell me about it--but I accept no blame in perpetuity for anything :) This isn't even beta software, this is like... whatever comes before alpha. Also, people are doing lots of weird stuff with Microformats such as embedding <script> tags in them, so you'll often find that although the cards will render, they will choke Live Clipboard if you attempt to paste them into another site. If you're technically minded, try pasting the contact into Notepad or something so you can fix it.
These links also aren't really examples of inline microcontent like this post is, unfortunately to my knowledge this is the first example of that on the Web. If anyone has any other examples I'd love to know about them.
If anyone's interested I'll post some more technical information about all this, but I'm still refactoring it for broader use in actual products. All of the code for this example is licensed under the Creative Commons Share-Alike license, so you're free to use and/or modify it if you wish. I'm still adding to it and refactoring it quite a bit; however, I got it to a stable point and I figured I'd see what people thought of as it stands now.
Oh and by the way, listen up Microsoft: we need an editor for this stuff. If you really want to leapfrog the competition, do us all a favor and build Live Clipboard and microformat support into the next version of Word and Outlook.
Thoughts?
1600 Pennsylvania AveWashington DC 20500 USA
350 Fifth AveNew York NY 10118 USA
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.
The Live Clipboard vision gives users the ability to transfer data without having to rely on software. It'll be the end of exporting and importing files from one program to another, or copying and pasting fragments of a record from one program to another.
The onus of keeping information secure will be almost entirely on the user, because he'll be able to share whatever information he has access to simply by copying say, an invoice, and pasting it into an email or instant message as microformatted HTML.
Here's how I see the market unfolding:
And something very cool will eventually happen where companies will be able to transfer data between each other using RSS (or ATOM) feeds filled with Microformatted content. Synchronizing two databases on two different networks will no longer be a chore, but a 30 minute exercise. Users will be able to email orders to their partners by copying and pasting them into an email (their partners would then hopefully be able to copy the order from the email and paste into their sales system).
Security will become an issue I'm sure, because this really places the onus of filtering what data is shared on the user himself. A whole slew of new issues will spring up around that, simply because data will be so much more accessible than it ever has been, and software will no longer be a roadblock in the process. Right now the only way to share data is via email, but the emails will also become much richer and more meaningful.
It will be an interesting time to be involved in Enterprise software, I'm sure.
M. David Peterson has posted a great technology demo that combines Live Clipboard and Amazon S3. Here's a link to the demo. In my personal opinion, this is a peek about a year into the future of the Web. Basically, the demo is a list of objects (just contacts and calendar events right now) that is persisted to Amazon S3 for storage. Think a blogroll, but not just for blogs. It actually contains data about different types of objects, and you can cut and paste those objects around in the list and back and forth from Microsoft's demo site.
Someday, a list will be a list of meaningful data, and sharing a list won't just be sharing links to the objects but the objects themselves. This is powerful stuff.
Imagine in a few years when this technology proliferates--the possibilities are just endless. You'll be able to copy meaningful data out of your applications (Web-based AND fat client) and use it in all of your other applications. Instead of those vCal emails that get sent out by travel sites, all you'll have to do is copy the event and paste it into Outlook. You'll be able to copy a contact from Outlook and paste it into your Webmail client. Your personal RSS feed won't contain just your blog posts, but also your contacts, events you attend, reviews you post, and just about everything else you're involved with.
I can't wait, the Internet is going to be SO much easier to use once the dust settles, standards are formalized, and this technology proliferates.
This is really cool. Ajaxian ran a story about a new capability built into the Dojo framework that provides persistent client-side storage. There's even a link to a demo app. Although it has some limited use because, frankly, I want my Web apps to work on every machine I use (yes I'm a geek I'm in front of at least 2 machines at all times), this opens up some cool possibilities.
It even does a pretty nifty trick of deciding the most appropriate storage mechanism for the client, with multiple options including cookies, flash, and IE-specific. I'm envisioning using this for Live Clipboard 2.0, in fact it could even work like the MS Office clipboard where you're able to hold more than one object/text chunk a time. Groovy.
IDEA: Could we keep a security token there?
I believe an extension is needed for Live Clipboard. Right now it only has the capability to copy & paste the information contained on the page it resides in. In Ray Ozzie's example, all of the contact and calendar information is embedded on the example page itself. However, there are two big problems with that:
There's a simple solution to this, however. The microformat needs to tell the clipboard what it contains, but not embed the information in the page itself. (Or, if it does, it should be bare bones info, and only information that rarely if ever changes.) Instead, the Microformat should tell the clipboard where to look for the master copy of the information--the URL where the fully fleshed out information can be obtained. This solves both of the problems, and creates a kind of "object authority" where the master copy is always fresh and authoritative.
This will require some further refinement of the microformat specs (keep an eye on xFormats.org for details) to include the location of the full object spec, but certainly nothing that can't be easily overcome.