One of my favourite features of web-aware calendaring software (be that desktop or online) is the ability to subscribe to a calendar. Rather than importing the data once, the calendar software will store the URI of the calendar data and periodically update from the source. The frequency of the updates can be set based on the subject matter, usually anything from minutes to months.
Rather than just importing the data once and forgetting it, the subscription pattern embraces the fact that your source of data knows more about that data than you do (else you’d not be importing it), and that the data may change at some point. If your data source is more a more authoritative source for that data than you, why presume that they wouldn’t always have more up-to-date information than you?
Subscription is already commonplace with calendars and of course RSS feeds, where it’s been proven to work well and to be easily understandable. So the next step is to apply it to all other areas where data importing is common. Social network portability (which according to Tantek is all my fault) is a an area where subscription should be applied liberally. If a user points to a source of authority for their social networking information, an app should presume to subscribe to that source, giving the user the option to opt-out of subscription and make it a one-time import if they choose. (For example, if I were to decide to stop using Twitter and migrate to Pownce, an import would be useful, but Pownce would become more authoritative from that point forward as I began to use it primarily.)
This is a really important Web 2.0ish concept for web app developers and users alike to understand and embrace. For an app to truly be native to a web of data it needs to understand that it does not become a peer in the authority of that data simply by importing it. The data source is still more authoritative, and will likely continue to be so. Therefore, it’s not enough to import and forget. You have to keep checking back. Consider everything to be a feed.
Comments
I think opt-in import is actually a better option than subscription for many social network portability cases. I would rather see a list of my friends on Facebook with a checkbox next to each one so I can select which ones join me on network X. Subscription still has a role to play – it would be nice if network X could tell me when friends from Facebook created accounts on network X so I can decide if I want to friend them on network X – but having everything happen automatically ignores some of the subtleties of online relationships.
I don’t think subscription has to preclude choice, by any means. I’m talking more about the concept of continually revalidating the data held against its origin rather than changing how the user may chose to implement or interact with that data. I don’t think subscript changes that at all.
For a while I’ve wanted to offer this on Dopplr. I’ve been doing a little more work on it today and have created working proof-of-concept code using our Facebook/Twitter/Flickr/Gmail importer. It’s even more relevant now the Google Contacts API means that I can store a password-free token for re-checking your address book periodically.
Screenshot at http://flickr.com/photos/mbiddulph/2368894694/
I think you’ve got something there Drew!
The difficulty is in services like the Facebooks of this world opening up to this kind of idea and at the same time, have start-ups push these concepts into reality. In many ways the shift is in the expectation of the users. When you log into Facebook, you see your data there – as you’d expect it to be. If you logged into Facebook that was also polling the subscriptions with other data sources and one of them was down or unavailable, non-technical users could understandably be confused.
It’s trying to anticipate how non-technical people can work with these concepts which is as much of a challenge as the technical implementation, I think.
Just my 2p…
Especially my OPML. I want the ability to use the same OPML in multiple application. To be able to update my OPML in one place and have view the changed results in multiple applications. Oh Internet Gods, please make it so.
My problem with just suggesting subscription over import is that as subscriptions become more complex (I have accounts at Facebook, twitter, myspace and more) then each of these tools will have to subscribe to each other to get regular updates (an exponentially increasing traffic pattern) OR I have to pick a service that represents a canonical contact list. Neither of those do I think are ready for users to just pick up and start using.
That being said the latter seems like the most likely end candidate for how to solve the problems of import without an unmaintainable subscription scenario.
~ Anders