Is there anything simpler than a tweet? One hundred and forty characters of text … what could be easier? However, the rules for third-party developers who integrate with Twitter have just gotten more complex, and I count at least 32 separate requirements for apps that incorporate tweets.
And, if I’m not mistaken, Twitter’s guidelines have a lot of do-as-I-say, not as-I-do.
On March 21, 2006, Twitter cofounder Jack Dorsey posted the first-ever tweet: 24 characters, including spaces. Timestamp, source, and author.
All simple and easy — the marked difference from Facebook or other social networks that offered multiple options, full media, and unlimited status update lengths. And that very difference was a big piece of Twitter’s brand story and attraction to users.
Much of that simplicity has disappeared as Twitter has evolved into a personalized news network — the interest graph rather than the social graph — and incorporated images, video, and short previews of links in expanded tweets for favored partners.
In short, this has happened as Twitter has become more publisher than utility, and as Twitter gets all grown up into a corporation that needs to (shockers) generate revenue.
But with Twitter’s recently announced API changes, developers who integrate with Twitter and incorporate tweets into their apps no longer have display guidelines. They have display rules, and that means that there will soon be at least 32 Laws of the Tweet that developers need to obey … or risk losing their access to the Twitter API and the Twitter ecosystem.
Here they are:
- Tweeter’s name must be displayed
- Tweeter’s username must be displayed
- Tweeter’s avatar must be shown
- The username must always be displayed with the “@” symbol
- Tweet text must be shown on a line below the author’s name and username
- Tweet text must not be altered or modified in any way
- Any mentions of other Twitter users using “@” must link to those profiles
- Any hashtags must link to Twitter search for that tag
- Any links must use the API URL field
- Any links must use the Twitter shortener t.co
- Reply …
- Retweet …
- and Favorite action icons must be visible for the user …
- and the relevant actions must be enabled via API or Twitters web intents technology
- No additional social or third party actions may be attached to a tweet
- The tweet timestamp must always be visible
- The tweet timestamp must always be linked to the tweet permalink on Twitter.com
- The branding must clearly be Twitter’s
- The Twitter logo or follow button for the tweet author must always be displayed in the top right corner
- Any pics or images must be displayed as part of the tweet …
- and link back to the Tweet permalink
- Images may not be detached from the tweet and displayed separately
- The user’s name and Twitter username must be displayed on one line
- The user’s icon must be to the left of the name and tweet text
- Timestamps should be in the top right corner
- Use a short-form timestamp in …
- seconds if the tweet is less than a minute old …
- minutes if the tweet is less than an hour old …
- hours if the tweet is less than 24 hours old
- Use a date and month timestamp if the tweet is more than 24 hours old
- If the tweet is a retweet, the name of the retweeter and the retweeter icon must be displayed under the tweet
- No third-party content can be mixed in with Tweet content
This is the example tweet that Twitter included with the list of requirements, which seems to obey them:
Of course, here’s the official Twitter app on iPhone, directly from Twitter. I’ll leave it as an exercise to the reader to determine whether or not tweets shown in Twitter’s own app follow the rules:
There’s a good reason why they don’t: Tweets that include all the voluminous information that Twitter is requiring developers to display will simply not be as simple, as clean, as readable … in short, as user-friendly as the Tweets shown just above in Twitter’s iPhone app.
Ergo: Third-party developer’s apps will not be as good as Twitter’s.
I should be clear: Twitter is under no obligation to make life easy or lucrative for developers. The company can do as it pleases and when it pleases, and it is only accountable to its investors and the law. Specifically, it can require different things from developers than it offers to users via its own apps.
However, when developers cannot easily and quickly build products of utility, beauty, and simplicity on a software platform, they can and often do choose to abandon that platform. As one developer replied to my initial post about the Twitter development guidelines:
Screw you, Twitter. You just saved me some development time, because I’m not going to suck up to a service that will arbitrarily waste it.
That’s something for Twitter to think hard about as the company continues to monetize. No platform that is not good for developers is likely to succeed in the long term.
The guidelines (they will be rules when the API reaches version 1.1) are not presented as above but grouped for easier reading. I’ve separated some that seem to be different specific actions required by developers, but kept others together that seemed too trivial to separate.
VB’s research team is studying web-personalization... Chime in here, and we’ll share the results.