Application Autodiscovery
Chances are, when you’re out and about surfing the Web, you’re bumping into semantically-enhanced content.* In some cases, you see the benefits; in others, your experience doesn’t change. This fact is one of the great side effects of the Semantic Web movement: if you participate in enhancing your content, none of your users suffer, and some (hopefully many) are pleasantly rewarded.
With this approach in mind, I’d like to propose a solution that fits within this vein: a standardized means for publishers (i.e. anyone producing Web content) to expose their Application offerings to users.
Applications are all the rage now. Facebook kicked off the trend, Apple came in with killer iPhone Apps, and Yahoo!, Google, MySpace, and others all have App offerings, too. As such, many publishers have Apps in many flavors (i.e. platforms), but may not actively promote them around their site. Or, if they do, they don’t all consistently feature and talk about Apps in a manner that helps users know where to go to find out if their favorite site offers an App.
This problem, though, isn’t unique to Apps. It was a similar problem for RSS feeds when they emerged several years back. And the solution proposed then (and since implemented) would seem to work equally well for Apps: provide an autodiscovery tag for Apps in an HTML document’s head element. Once folks begin adding App Autodiscovery tags to their pages, browser makers (such as Firefox, WebKit, Opera, Internet Explorer, and others) and other software vendors (such as Yahoo! Toolbar, Apple’s iPhone version of Safari, etc.) can look at how they’d like to visualize such information (if at all). (This type of solution has been extended to content other than RSS, such as FOAF and Sitemaps.)
An example of how App Autodiscovery tags could be visualized in a browser.
Why do this? There are a number of reasons:
- A common standard for App autodiscovery will allow browser and software vendors to develop innovative means of exposing related App content;
- App Autodiscovery won’t negatively impact users or browsers that don’t understand the tag; it will just be ignored.
- App Autodiscovery is easy to integrate;
To prove the last point, the code for such an effort is simple:
<link rel="alternate" type="app/facebook" title="The New York Times News Quiz" href="http://apps.facebook.com/nytquiz" />
The type attribute could be populated with any series of attribute values (which would need to become normalized and approved MIME types), such as:
- app/opensocial
- app/facebook
- app/yap
- app/iphone
Additional title and href values would define the App’s unique name and location, which could tell a user where to use/install the Application in the appropriate App platform.
So, with this thinking in place, App Autodiscovery code could begin to be integrated into sites today in the following fashion (using my friend and colleague Matt Lock’s App: Minsa):
<html>
<head>
<title>...</title>
<link rel="alternate" type="app/yap"
title="Minsa"
href="http://apps.yahoo.com/-6lOOCT7a" />
</head>
<body>
<!-- the web page's contents -->
</body>
</html>
Adding this one line of code (per app per platform) within your website’s head element can make relevant App discovery much easier for people in the places they already have an interest (i.e. the places they visit). What do others think? Let me know if you know of alternate/better solutions to address this issue.
* For those unsure of what I’m referring to, the Semantic Web is an effort to provide structure and additional information around content on the Web. Why? Because most content on the Web is understandable to its readers, but not to computers. As such, you can discern that an article online is talking about an event (like a concert at a certain place at a certain time), but your calendar software can’t recognize it as such. Therefore, you need to manually “rebuild” such event info in your calendar, which breaks its relationship to the online article; if the article was updated, you wouldn’t know, and your calendar would be out of date. These disconnects happen all over the Web today, but could be significantly reduced via concerted efforts by publishers to enhance their Web content with semantic markup (which in turn would open their content up to many inventive possibilities that are today exceedingly difficult).
For more information about the Semantic Web, check out the W3C’s efforts (as well as the community-driven Microformats efforts) to see how content on today’s Web pages can be enhanced to support this model.
Laurie said,
January 2, 2009 @ 11:57 am
What a clever idea. Let’s get on that.
Laurie said,
January 2, 2009 @ 12:03 pm
Oh, but for the love of god not a “gear” icon. We’ve used that for so many other goddamn things already.
Also, how would it work on the front page of Yahoo, for instance, where we offer 15-20 separate types of app? (Flickr alone has apps for about 5 platforms I can name, Mobile has another 3, Mail another 4 or 5…) Just throw ’em all in there?
Micah said,
January 2, 2009 @ 2:27 pm
Thanks, Laurie… re: how to show all the Apps for Yahoo.com, my hunch is initially you’d just link the more generic Apps from the homepage (such as Yahoo!’s OneConnect App on the iPhone). If a user then went to Yahoo! Sports, you’d begin to bubble up a set of Fantasy Sports and Scoreboard Apps, whereas a user on OMG would be presented with a set of Celebrity Sightings Apps. In the long term, though, it would seem RSS, FOAF, Apps, and others would benefit from a similar Autodiscovery link for their appropriate “catalogs.” Then, a user could truly see all RSS feeds available from Yahoo!, or all the Apps built by Google, etc.
Re: the gear icon, it is only there to show what’s possible. Just like Safari, Firefox, and IE all show different icons for RSS, I’d assume they’d do something unique to their browsers for Apps (and any other Autodiscovery mechanisms). I’m not partial to the gear.
Scott Gatz said,
January 3, 2009 @ 8:59 am
A really simple and great idea. I worry a bit about too many app links in the header, but publishers can just choose to highlight what they want..
You should talk to firefox and IE. Make it happen!