All posts tagged ‘open web’

File Under: APIs, Web Services

It’s Time to Build a Twitter-Free Twitter

Image: Twitter.

Twitter dropped a bombshell on third-party application developers last Friday — the social network built on the backs of third-party developers and clever, innovative clients has decided it no longer needs them.

Twitter’s blog post is short on specific details, but the gist of it is that Twitter is tightening up its API access for third-party developers. The company has long viewed third-party apps as unnecessary and previously warned developers not to “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” But thus far it hasn’t enforced that guideline. Now it seems it will.

In a post on the Twitter developer blog titled Delivering a consistent Twitter experience, Michael Sippey, Twitter’s director of product, seems to say that the company wants its official clients — and only its clients — to be the way people use Twitter. Instead of building clients that pull out of Twitter, the company wants developers to “build into Twitter.” In other words, kiss your Tweetbot, Twicca or Hibari goodbye and get ready for some embedded widgets instead of good ol’ tweets.

Much digital ink was spilled over the weekend denouncing Twitter’s policy change or lamenting the potential loss of alternative Twitter clients. Of course Twitter is in charge of Twitter and when you use its service — or build apps on its API — you must suffer its whims.

But Twitter’s decision to start enforcing its API restrictions “more thoroughly” could end up a great thing if it inspires developers to take the essence of what makes Twitter great — succinct, timely messages to and from your friends — and free it from Twitter the company.

An independent and decentralized equivalent to Twitter is certainly not a new idea. The basic building blocks you’d need to build such a system have been with us for many years — a combination RSS, OPML and perhaps PubSubHubbub would cover of most of it — but until now there hasn’t been widespread client developer support for such a system. After all, why go to all the trouble of building a decentralized network on top of open web standards when using the Twitter API is so much easier?

Twitter’s third-party developers now have the answer to that question — because you can’t be locked out of the open web.

Developer Brent Simmons, perhaps best known for creating the Mac-based RSS reading app NetNewsWire, has a basic outline of how Twitter app developers could band together and make something that not only sidesteps Twitter’s coming API restrictions, but the service itself.

“The interesting (to geeks like us) part,” writes Simmons on his blog, is “what system that works like Twitter could exist without a company behind it?”

Simmons then proceeds to break Twitter down to its essentials: “under the hood, following somebody is really just subscribing to a feed of their statuses. Posting is really just updating a feed of your own statuses. So you standardize on a feed format. RSS would work great, of course, and there’s a ton of RSS reading and writing code out there already.”

Instead of Twitter clients, what you’d really be building is a real-time RSS client. That’s not a far-fetched idea. Dave Winer, the forefather of blogging and creator of RSS, has been building one for years. (He’s also been telling everyone to build a distributed Twitter-like publishing system for years.)

Simmons doesn’t address it directly, but it’s worth noting that building such a system doesn’t preclude using Twitter. It’s not either/or, it can be both. In this scenario you’d write a post in a client like Tweetbot and Tweetbot could automatically send it Twitter and to your own feed. Start with both and then a migration away from Twitter would be smoother. Those that want to dump Twitter immediately could do so, but still keep posting to anyone with a client that supports the open structure. Then, if Twitter really does cut out third-party apps completely, the infrastructure necessary to support an open alternative is already up and running.

Simmons has more details for developers on his blog and in a follow-up post that delves more into the logistical complexities, but the basic message to developers is simple: Twitter’s changes means you need to find a better network for your clients to use.

The better network is the one that’s always been there — the web. The advantage for app developers feeling threatened by Twitter’s API changes is obvious. As Simmons writes, “there’s a practical reason to use the open web: your app can’t be shut down.”

The question is, if there were an open alternative would disgruntled Twitter users embrace it? The main argument against any alternative is the so-called network effect: Everyone I know is on Twitter; why would I go somewhere else? But not too long ago no one used Twitter and everyone used Myspace. Everyone used Friendster. Everyone use AOL. People change; networks move. A distributed version of Twitter sans Twitter might well be the web to Twitter’s AOL, but there’s one certainty: We’ll never know until we build it.

File Under: Web Basics

The iPad 3 and the Future of the Web

Apple is expected to announce the third version of the iPad tomorrow. It’s easy to mock the excess enthusiasm the tech community has for new Apple gadgets — Wow! Look, it’s a new computer!

At the same time it’s just as easy to see why that enthusiasm exists — Apple can be counted on to push the boundaries of how we use computers and how we use the web.

As developers, pushing the boundaries makes for exciting times. Difficult times too. Times that challenge our current models of what the web is and what the web might become.

Apple has already pushed the web in several new directions by popularizing touch-based devices and in the process redefining our behaviors, habits and expectations.

Taking away the mouse forced developers to rethink many things we previously took for granted — of course I can use a drop down menu that activates when a mouse rolls over it, how could that possibly not work? Well, now you know. That was only one small change and suddenly web developers had to pivot, best practices had to change.

What will all the new changes coming this year mean for the web? No one knows yet, but the web today is feeling less like a thing that lives in your browser and more like something that exists in the space between things. The web of tomorrow will be less visible and more powerful — the thing that pulls everything together and makes it work even when the web isn’t something you access directly on every device.

A while back Brad Frost told developers to “get your content ready to go anywhere because it’s going to go everywhere.” This has been happening for a while now with RSS and APIs that push and pull content to places often far removed from the “webpage” where it was originally published. Expect this to continue and to become even more common as we navigate between different devices, platforms and technologies. Android apps can’t run on iOS. Windows Metro won’t integrate with a Spark tablet. Something has to link the device silos together.

The web has already become a way to link information across otherwise disconnected apps. Take Marco Arment’s Instapaper, for example. Instapaper saves webpages for offline reading and syncs them between iOS devices and Kindles. Is Instapaper a web app? Is it an iOS app? Is it a Kindle service? It’s all of these things.

Even when platform-native apps are the access point, the web remains the key element in the equation. This will likely be the future of the web — less visible, less obvious, less about the browser, but essential for connecting everything together.

That doesn’t mean that the browser will go away. The browser will likely continue to exist for some time as a fallback. We will still need a device and platform agnostic way to access the web as long as devices remain silos. If iOS went away and Amazon stopped making Kindles, you could still read your Instapaper articles on any device with a browser. The opposite isn’t true — take away the web and the Instapaper apps would be isolated, with no way to connect them.

The web is bigger than the browser already and it will continue to expand into new areas. What’s going to happen when the web is on your television? How will the web need to change when the screen is much larger and further away? How will the web need to change if we want to interact with it by voice commands? Very soon Android devices are going to be in your car dashboard. Eventually your car itself will have an API. Your car could talk to, for example, your car dealer, logging in, making an appointment for a repair it’s just become aware of. It might then use another API to push the appointment on to your calendar app, which then might use the Siri voice API to ask what time works best for you, scanning your other appointments and offering suggestions.

Where in that scenario is the web as we think of it today? It’s just a series of APIs talking to each other. There is no web as we know it. And yet the web is still there, invisibly making it all possible. There’s a reason, after all, that we call it a web — it’s what binds everything else together. It no longer matters if what you’re after ends up displayed on a feature phone via Opera Mobile or inside the Instapaper app running on the latest and greatest iPad. The web is already everywhere.

Photo: Benoit/Flickr