The Twitter Client Wars

Everyone working in any position related to web design in the 90s remembers the browser wars. Individual companies rushed to add new features to their web browser, and encouraged developers to help the marketing through the use of ‘works with’ buttons.

Most of these extensions were poorly thought through, and even where there was agreement on the syntax there were differences in implementation. The humble image tag was the first casualty, let’s not even start on ‘marquee’ or ’embed’, and even today developers are having to put in workarounds for Internet Explorer 6, and the different implementations of the border box model.

The winner was never the end user, just like the battle was never about them: it was about killing competition. Even today users are faced with sites that work differently depending upon the browser in use, the plug-ins they have installed, and the operating system they choose (or are required) to use.

There are signs of a similar war brewing in a different communications medium that more of us are using daily: Twitter, which alone has more users today than the entire Internet had during the browser wars.

Twitter restricts messages to 140 characters, which may be sufficient to document bowel movements but makes sharing complex URLs difficult. Services such as bit.ly have proven useful there, but others have opened with the more insidious intent to remove the 140 character limitation entirely. What’s worse is that the Twitter clients are starting to use these by default for new users; Tweetdeck has deck.ly, Plume uses tl.gd, and others emerge frequently.

The proportion of tweeters using the web site itself still massively overshadows those using Twitter clients, and I would be very surprised if Twitter integrated its site into ‘long tweet’ services in the same way it works with image services and URL shorteners. But in terms of sheer numbers, there is a risk that more people will use software with integrated message shorteners.

When that happens, the race will be on: which client can extend the Twitter API to a point well past the state that Twitter itself wishes it to be extended? Will some clients be forced to implement features that others have, simply to remain on equal footing? Will they start to add new features themselves to pull away from the rest of the pack?

Quite simply, are we facing the first Twitter Client wars?