Something I’ve been working on in my programming projects recently is ways to allow users to use their data from outside my service, and to take the data they have in services I create elsewhere.
In the new era portability is king. If you don’t allow users to use their data how they want, your service is utterly useless and doomed to failure.
Whoa there, you say, them’s some big bold words! If it sounds like I’m including the large portion of current generation products people are familiar with as the target of my wrath, you’re right on the money. Let’s take a look at a recent real life example, MobileMe.
MobileMe offers some excellent syncing tools for those of us with Macs and iPhones. Over-the-air (push!) syncing of contacts and calendars is a great tool, especially for those of us with a desktop, a laptop, an iPhone, and an iPod Touch all trying to stay perfectly in sync. However that’s exactly where the scope of the tool ends. Want to share contacts/calendars with someone else as “joint ownership”? Screwed! Can’t do it. So MobileMe loses one user/evangelist to Google, where I can choose to allow another user to collaboratively edit my calendar. MobileMe ends up in the trash heap because the data I give it can only be used in the ways that MobileMe wants me to use it, and I have different ideas.
Google also frustrates me though because I would very much like to set up a group of shared contacts between Bev and my accounts so we could maintain contact synchronization, but that’s not supported through them either. I have a huge store of data, and I can’t even grant another user ACCESS to it. This is full of fail.
Obviously one of the core problem with this is common language. There has to be a standard protocol that is used for each type of data in order for sharing to really work. For inter-service data (like sharing contacts with another user of the same system) there really is no excuse however.
There is another form of data usage to consider beyond just sharing. A good example of the type of thing I’m thinking of is WebHooks, but I’m not completely convinced on their implementation.
A current example of the concept would be posting? to an online forum that lets you “follow” the thread. When you post you can check the box for “email me when someone replies”. Now whenever someone posts something you get a notification. WebHooks is like that, except instead of providing a simple email notification it allows you to provide a URL and a notification is posted to that URL. The notification contains whetever data the application designer wants it to. This may seem like a power-user feature, but once the concept is widely accepted it allows you to let websites (and the datasets they contain) to interact with each other in fabulous new ways.
This starts with us, the application designers. And this is why I’m so hot and bothered about the idea. If I don’t design my own applications to allow the sort of data interactions that I want from other websites I use. Once again though, the problem is standards. How do you output the data? Do you create your own refspec for the specific website/application? Where do you draw the lines?
Once again, the problem is standards. There’s no reason why any user should have both MobileMe contacts and google contacts. Ideally either service should allow the user to use, not just “import”, contacts from the other.
We’re not there yet, and I understand how people scoff at this idea, but I’ll say it again. Data portability and access is king. If you don’t let your users get to the data they’ve entrusted to you and use it in the ways that they want to use it, they’re going to abandon you.
Here’s something depressing for you to consider:
What’s another name for services/programs with good data portability? Infrastructure. There will always be services built on top of infrastructure that don’t have data portable (even if such services want data portability) due to the mechanics of the marketplace (limited time, desire to corner a niche, etc.).
@nordsieck
Yes, true. But at least if the infrastructure supports it it becomes possible for app developers to be able to easier build interoperable apps.
My theory/hope is that the market will demand this capability as soon as people realize how much they actually want it. 🙂