Platforms and data: or, why Google+ needs Hootsuite
We’re quickly approaching Google+‘s first birthday, and the search giant’s social media platform has found a core audience, but it has never caught on to the extent that Google hoped or the tech media hyped early on. That core group of tech enthusiasts has certainly put it to good use, with voices like Tim O’Reilly finding an even broader audience and a medium that suits him well.
For most of the population, though, Google+ was a novelty that never went anywhere. Of all my friends, only about three use the service with any regularity (and by regularity, I don’t mean checking-Facebook-obsessively regularity; I mean a couple times a week). There are a number of reasons for this, I suspect – the slightly strange middle ground the service strikes between Twitter and Facebook, the fact that Facebook is already deeply embedded in most people’s lives and switching costs are concomitantly high, the way it rolled out with limited (albeit cool) features. But there’s another reason I suspect is a huge part of Google+’s failure to catch on outside of that core demographic.
One of the great strengths of both Twitter and Facebook – especially Twitter – is that it makes it easy for other platforms to retrieve and create content on the network outside the network. This is why the early years of Twitter saw such a plethora of tools to access the network, from Tweetie to TweetDeck to HootSuite and a thousand others in between. Especially in a time when Twitter itself wasn’t particular user-friendly, this meant outside developers could take the same data streams and present them in much more user-friendly ways. A lot of the innovations that are now central to Twitter itself came out of this external developer community (just as many of the conventions that drive Twitter conversation arose from the community of users – the ubiquitous “retweet” being the most prominent example).
Google+ doesn’t have this. Neither does Facebook, of course, at least to the same extent – but Facebook still makes it easy to pull in the News Feed… and Google+ doesn’t have Facebook’s lock-in of 900 million users. So it is to Google+’s very great detriment that it does not let external apps have easy access to its data.
The simple truth is: I would be far more likely to use Google+ if I could integrate it with my HootSuite or TweetDeck apps on Android, rather than having to open the platform-specific application. (I almost never open the Facebook app, and I don’t remember the last time I actually accessed the official Twitter client for Android – maybe never.) users are accustomed to being able to get and create content in a place and way that’s convenient to them. Google, I’m sure, has a reason for locking down its access the way it has, but the cost for Google+ has been high. Without that pre-existing user base (as in the case of Facebook) or an easily accessible API (as in the case of Twitter), all it has to bank on is tech enthusiasts’ enthusiasm.
That’s great, as far as it goes, but it won’t get you any pull outside of that area, and the truth is that tech enthusiasts already like Google and many of them already gave Google+ most of the information it can now get from “social analytics” in their other interactions with the search giant. If Google+ wants to grow outside of that niche – if it wants to be a genuine social hub (and it does: it’s just good for business) – it needs to make its data open and easily accessible. If it lets me get at Google+ data in my streams on TweetDeck, it will grow. If it doesn’t, it will always be stuck in tech geek land.
There’s a lesson here for smaller developers, too. Google+ can sort of get away with this, because Google was already sufficiently large as to be able to get some leverage just by having a well-designed interface and banking on its own reputation. You and I don’t have that latter factor going for us, so a decent interface isn’t going to do the trick. If you’re going to build a web app and you want it to catch on, you need to provide a way for users to get at the data. (Optimally, you want that data to be accessible in as raw and unfiltered way as possible, as I’ve written before.) This can’t be a future feature; it needs to be a priority from day one as you’re developing. What will your API look like? How will you allow your users to create value on your platform, using your data? The more you open it up, the more uses people will find for your service, and the more they’ll share it with others, and accordingly the more powerful it will be.
Open platforms with accessible APIs are the key to the data side of successful web application development. Data, it turns out, is the currency of an information economy. There are other necessary components in other aspects of application development, but if you don’t get data right it won’t matter how pretty your interface is; you are doomed to languish in obscurity. If you get data right, though, you might just have a chance of your data going somewhere interesting.