Category Archives: Reprint

Twitter’s Token Rush

One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with your Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.

Cachet

It’s common to observe in retrospect that a popular band, television show, clothing style, or even a country has outlived its popularity. We internet hipsters refer to this as jumping the shark, in homage to the popular American television series “Happy Days.”

It’s less common to know when some focus of celebrity is at a precise peak of popularity, poised for a sad, gradual decline into the the oblivion of historical footnotes. I didn’t predict Friendster’s demise until it was obvious, in spite of increasingly poor page-load performance that made it impossible for me, as a fan of the site, to visit it as often as I might have liked. When MySpace was at its peak, it seemed as inevitable as Facebook or Twitter is today. Of course you have a MySpace page, otherwise you don’t exist! When I first got involved in blogging, it was on LiveJournal. Where else would you host a blog?

Relevance on the social internet is fleeting. Facebook, Twitter, Tumblr, WordPress, and Google all know this. They’re among the vanguard for the moment, enjoying the same notoriety that MySpace, LiveJournal and Friendster once cherished.

I’m not enough of a business genius to claim, even in retrospect, to know why each of these former social-internet giants fell. But I am enough of a smart-ass to propose that in every case it was a case of a company losing its way. A company loses its way by diverging from the path its customers expect it to follow. For companies like Friendster and MySpace, that happened arguably by standing still while the needs of customers shifted. In other cases, the customer’s sights are in one direction while the company envisions something completely different.

I have often wondered why some people like Facebook while other people like Twitter, and yet other people seem to favor them equally. I should come out and admit now that I “like” both services, but when it comes down to it, I devote the vast majority of my attention to Twitter. I’m not sure I completely “get” Facebook.

That’s a lie.

I get Facebook, but from where I sit, the selling point for Facebook is to be in touch with all the mundane, everyday things that your friends and family have to share. I love my friends and family, and I do love to keep in touch with their mundane activities. But that’s just it, isn’t it? Facebook is for the mundane. Love it or hate it, and sometimes there is an awful lot to love, Facebook is not in the business of providing a venue for punchy, thought-provoking, elevated banter.

That’s where Twitter comes in. The reason I spend the vast majority of my time reading and interacting with friends, acquaintances, and strangers on Twitter, is because the expectation of quality is high. Twitter, like blogging before it, has been broadly ridiculed as being about “what I ate for breakfast.” But in practice, that’s just not the case. The 140-character limit, and certain cultural expectations among the users I interact with, means that cutting humor, philosophical insight, and up-to-the-minute gossip and news, are to be expected. In short? Twitter has cachet.

Among the reasons for Twitter’s cachet is its distance from the tactics of other social networks. While Facebook relishes in trashing up your timeline with mindless games, polls, and other nonsense that distract from the core content of your followers, Twitter has remained relatively pure. I usually connect to Twitter with a desktop or mobile client, but even when I visit the web site, I’m mostly looking at a long list of things people said. And nothing else.

Twitter’s cachet has earned a lot of goodwill, but also a lot of skepticism about how it intends to sustain itself going forward. From day one, it seems, people have criticized the company for its lack of an obvious business model. Now it seems poised to answer that criticism with a vengeance. It has already locked out former partners such as Facebook and Tumblr, and is cracking down unilaterally on 3rd party apps that aim to offer first-class, full-service interfaces to the service.

As Dan Frommer explained in his Understanding Twitter post, Twitter is in a position where, to keep doing what it’s doing, it needs to hunker down and make money. Fast. Recently its actions have revealed that the way it intends to do that is by 1. Owning the core Twitter user experience and 2. Monetizing the ownership of that experience through ads or other means.

The problem with cachet is it’s easy to maintain when you’re giving, but much harder to maintain while you’re begging. Twitter’s new emphasis on earning money will quiet the criticisms of those who mocked them for lacking a business plan. But for customers who were attracted to the service because of its simplicity, for its elevated tone, or for the apparent disregard for the vulgarities of earning money, forfeiting that precious cachet may be the worst business plan of all.

Target The Forward Fringe

Marco Arment quipped on Twitter that web designers need to take HiDPI displays seriously, and adapt their designs to look great on them.

The short-sighted reactions he received revolve mostly around simple mathematical analysis: because HiDPI displays represent a relatively tiny percentage of all users, it is not worth a designer’s time to cater to that niche group.

I confess that after the iPad 3 was released, I paid little attention to adapting my site to support HiDPI. But when Apple announced the Retina MacBook Pro at WWDC, revamping all of my apps and my web site jumped to the top of my list of priorities. My apps are shaping up nicely. My site? Let’s just say it’s still on the top of my list.

Why? Because HiDPI customers may be a fringe group, but they are a forward-facing fringe. They represent the users of the future, and the more we cater to them now, the more deeply embedded our products and designs will be in their culture. The future culture. The same arguments apply to aggressively embracing newer web browsers standards, and the latest technologies in platform operating systems such as iOS and Mac OS X.

It doesn’t hurt that the forward fringe tends to be rich and influential, compared to other niche audiences. When some backward-compatibility quack notices that your site renders poorly on IE5, they may scream it from the rooftops, but it won’t make a serious dent in your sales or reputation.

In contrast, when a Retina early-adopter discovers how beautiful your site and software look on their fancy computer, they’ll be that much more likely to open their wallet again. When John Gruber or Jason Kottke happens upon your beautifully designed, HiDPI site, he’ll be that much more likely to spread the news about your forward-thinking design to their friends and readers.

Target the forward fringe.