Is Twitter a conduit for Tweets or the whole platform?

I’ve been writing and talking about the possible changes at Twitter which will pull RT’s out of tweets and into the Twitter API, read the post below this one.

The guys at Twitter are being really great and asking me for my thoughts, so here’s a copy of the email I just sent to Ryan Sarver (Platform Product Manager) and Jeremy LaTrasse (Operations). Please chip in with your own thoughts.

—————————-

Hi Ryan,
I described the issue in my blog post linked below and here again;
http://www.davidbanes.com/2009/09/18/project-retweet-is-twitter-breaking-re-tweeting-for-some-of-us/
But briefly, there will be many third party solutions, both public facing and ‘internal’ company systems that have been built on Twitter expecting the ‘extended’ command structure, that is RT, # etc to be in the message body.
Moving these features to the formal API works well for direct connect apps like TweetDeck and Tweetie for example but will break others especially those like tweet.im where they proxy Twitter for people using XMPP clients.
Cleartext could fix this by updating our generic XMPP client side application and our cloud based gateways (that convert XMPP<>Twitter) to handle the new API’s but in doing so we’d be blocking all our customers using generic XMPP software (like Psi), unless we let them RT and we translate that to an API call, not good.
In summary, from an engineering and usability point of view I can see that this is the way to go for Twitter, just as email has a ‘reply-to’ header that users don’t see.  But from the point of all those who have invested to deliver products and services expecting RT and # etc to be in the tweet body, at best it’ll cost them a significant amount of time and money to ‘re-tool’ at worse it completely breaks their product or service.
I suppose it comes down to product strategy, is Twitter going to remain the preferred conduit for ‘raw’ tweets and leave the extended command syntax to the creative people in the community, or is Twitter going to continually pull new and innovative syntax into the API and ask third party solution providers like TweetDeck, Tweet.im, Tweetie and Cleartext to continually re-engineer?
So, my point is that I’d like to feel comfortable that you guys are taking this into consideration before making this change, after all it’s third party solution providers that help drive the tweets to Twitter and we have to manage our product life cycles as well.
best regards,
David.
PS – I’m going to post this to my blog to see if I can get some comments going.

Hi Ryan,

I described the issue in my blog post linked below and here again;

http://www.davidbanes.com/2009/09/18/project-retweet-is-twitter-breaking-re-tweeting-for-some-of-us/

But briefly, there will be many third party solutions, both public facing and ‘internal’ company systems that have been built on Twitter expecting the ‘extended’ command structure, that is RT, # etc to be in the message body.

Moving these features to the formal API works well for direct connect apps like TweetDeck and Tweetie for example but will break others especially those like tweet.im where they proxy Twitter for people using XMPP clients.

Cleartext could fix this by updating our generic XMPP client side application and our cloud based gateways (that convert XMPP<>Twitter) to handle the new API’s but in doing so we’d be blocking all our customers using generic XMPP software (like Psi), unless we let them RT and we translate that to an API call, not good.

In summary, from an engineering and usability point of view I can see that this is the way to go for Twitter, just as email has a ‘reply-to’ header that users don’t see.  But from the point of all those who have invested to deliver products and services expecting RT and # etc to be in the tweet body, at best it’ll cost them a significant amount of time and money to ‘re-tool’ at worse it completely breaks their product or service.

I suppose it comes down to product strategy, is Twitter going to remain the preferred conduit for ‘raw’ tweets and leave the extended command syntax to the creative people in the community, or is Twitter going to continually pull new and innovative syntax into the API and ask third party solution providers like TweetDeck, Tweet.im, Tweetie and Cleartext to continually re-engineer?

So, my point is that I’d like to feel comfortable that you guys are taking this into consideration before making this change, after all it’s third party solution providers that help drive the tweets to Twitter and we have to manage our product life cycles as well.

best regards,

David.

PS – I’m going to post this to my blog to see if I can get some comments going.

————————

This entry was posted in Blogging. Bookmark the permalink.

One Response to Is Twitter a conduit for Tweets or the whole platform?

  1. David Banes says:

    This reply from the guys at Twitter.

    “David,

    Thanks for the follow up and I hear your point. We feel strongly that the new Retweet API / functionality will have a net benefit effect on the ecosystem as a whole. Overall most of the app partners we have talked to feel that the delta to integrate it has been trivial and the value has eclipsed the work required.

    To talk to your higher level question about raw tweets — we are definitely keen on adding more context around tweets as is seen with the Geolocation and Retweet launches. I would also posit that by including this metadata with the tweet we empower the ecosystem to be more creative as the data has more signal to work with. From a pure content transformation standpoint there may be more work, but we are servicing myriad of uses that go beyond just that.

    Hope that makes sense and I welcome your feedback.

    Best, Ryan”

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>