All Things D, by Mike Isaac: “This was a big deal. Countless numbers of smaller start-ups rely on access to Twitter’s public-facing feed, using the tweets in their own businesses for any number of reasons. If the terms of access were to be altered significantly, it could impact the livelihoods of thousands. The company didn’t elaborate on what exactly those guidelines would be, and has said little else since. The key takeaway echoed in one repeated word: Consistency. Twitter’s future plans strove for consistency across the platform.”
I had started a post to talk about where I thought Twitter was headed, but there’s no need to finish it. Mike Isaac did a great job in his article, and can actually write. It’s better to stick with the pros.
I wonder where this is all headed, given the Delivering a consistent Twitter experience post June 29:
“Related to that, we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used.”
If cards are a future piece to the Twitter puzzle and they’re after a consistent user experience where does that leave third party client developers? Has Twitter made contact with them to share how they should proceed with their implementation of Twitter Cards?
The Ugly Option
I still believe there is a slight chance Twitter could pull the plug on all third party clients, but I hope not. This would give Twitter full control over all clients and allow them to kill off all their native clients and go straight for HTML in the browser.
This is, of course, a horrible idea. HTML on mobile is still disgusting, slow, and provides a horrible user experience. Why go that route?
Twitter could be a real standup citizen and provide third party clients with guidelines for the inclusion of Twitter Cards, and other options, in client applications. They could also provide an expected timeline for inclusion of these features and allow the clients to operate without the new feature until that date. When the date expires and the client doesn’t include the new feature implemented in a Twitter approved way, they’re cut off until they are compliant.