Chase posted a ridiculous screenshot of “share this post” buttons. You know how some blog posts end with a little icon inviting you to “Digg this” post, or to bookmark it with Del.icio.us? Chase found a blog that provides buttons for some twenty-three different bookmarking, link-sharing, and other Web 2.0 services. (It reminds me a little of Jason Kottke’s Metadazzle overfizzle.)
I can understand how displaying these buttons can be in the karma-whoring interests of bloggers. Being easily Digg-able helps your chances of being Digged. The same goes for being easily Furl-able, and so on down the line to the more obscure forms of popularity: Scuttle-ishness, DZone-hood, Fleck-itude, and so forth. You might have some readers using Jim-Bob’s Bookmark Service, so why not add a Jim-Bob-This button? The trouble is that the Jim-Bob Bookmark users don’t use SquidShare, and vice-versa. Each individual reader might care about one or three of the buttons, but not the rest.
The problem, however, would be easy to fix with a bookmark button standard. A simple three-step dance among bloggers, bookmark services, and browsers would allow readers to see those and only those bookmarking buttons of interest to them. Here’s a quick sketch of how it would work.
In step one, bloggers would add a bit of metadata to their blog posts. Each entry displayed on a page would include a little bit of extra data indicating the permalink of the entry. This would be easy to automate with blog software.
In step two, users would tell their browsers what their favorite bookmark services are. This would involve a Firefox plugin; I’m sorry that it would be harder to do in IE, but if you’re using IE, your browser sucks. The telling mechanism could be almost completely automated. Once you had the plugin installed, it could be configured to recognize “add this bookmarking service” buttons from the appropriate bookmarking service sites. All the sites would need to do would be to create a small XML payload of their own telling the plugin what the format of their bookmarking buttons was: an icon, a name, and instructions for consing up a URL from the metadata supplied by bloggers.
In step three, browsers would recognize the bookmarklet metadata and automagically replace with with the appropriate button for the user’s bookmark service of choice. If you’ve told your browser that you’re a Digg and SquidShare user, you see Digg and SquidShare buttons. If you’re a Jim-Bob Bookmark fan, you see a Jim-Bob Bookmark button.
The great thing about such a system, in addition to the decrease in screen clutter, is that bloggers wouldn’t need to know about each and every bookmarking service out there. Merely by exposing a little data in a standard format, they would enable any bookmarking service, present or future, to interoperate with their posts. It’s a more Semantic-Web-y way of doing things, and it better respects modularity.
What about the users who haven’t installed the plugin, you may ask? Aha! I have an answer for you. (Surprise, surprise.) It’s okay to leave the current button soup in place. Just wrap it in another piece of metadata that tells the browser where to find the current welter of buttons. Users who don’t have the plugin just see the existing mess. But for users who do, the plugin hides the mess of buttons at the same time as it displays the specific buttons the user wants to see.
This staging strategy makes the plugin the essential piece of technology. Once the plugin exists, it creates a de facto standard. Bloggers code their pages to match what the plugin expects; so do bookmarking services. Neither bloggers nor bookmarking services need to abandon their current techniques; they can just add support for the plugin. It might or might not catch on like wildfire, but I don’t see it doing any harm.
Any coders out there interested in cleaning up some Web 2.0 litter?