Metro Display / Twitter Display Updates & Response to Twitter’s Developer Announcement

Today, I’m releasing a minor update to Metro Display and Twitter Display. For Metro Display, it will now properly display twitpic/yfrog images if the links were shortened by t.co. For both displays, they will now properly link mentions/hashtags/URLs if they appear more than once in the tweet. They can both be downloaded from the usual location. You may need to delete your current versions of the displays before installing the new versions.

I also wanted to say a few words in response to Twitter’s developer message that they sent out last week. I made Trowl a year and a half ago as a way to forward tweets to the iPhone in a very customizable way. Even today, Trowl gives you more fine-grained control than any other client – although, the official Twitter for iPhone app comes close. Since then, Trowl has grown into a respectable (albeit minimalist) Twitter client in its own right. I use it as my primary lens into my Twitter timeline, and I know a few of you do as well. While it is by no means a successful client in terms of number of users, I’m proud of what the client is and how much people have enjoyed using it.

Twitter made it clear last week that they don’t want more third-party clients. They feel they’ve figured out the best way to display a tweet, and they want that to be consistent. At this point, Twitter is trying to push the communication and data mining aspects of the service. While I understand their need for a consistent brand, it does put a damper on innovation and experimentation.

In developing Trowl, I made sure that every feature I added met Twitter’s criteria as much as possible. Because of that, I like to think that Trowl is one of the more “pure” implementations of the Twitter API. So, I’m not afraid that Trowl will get shut down any time soon. (Although, if Twitter ever finds out about “Twitter Display”, I know they’ll force me to rename it.) Still, Twitter is being rather quiet about what a “proper” Twitter client should be and what it should contain – probably because they want to discourage client development in the first place.

So, development using the Twitter API at this point is like stepping on eggshells. Not exactly a fun proposition. I plan to keep tinkering with Trowl – I really want to get the streaming API working, if for no other reason than my own learning experience – but beyond that, I have no firm plans for what to do with Trowl. Since I use it as my own client, I’ll make mandatory changes and bug fixes as Twitter’s API evolves, but the addition of features remains uncertain at this point. But I will keep developing it, as long as I’m allowed to.

Thank you, everyone, for your support and suggestions. I look forward to improving Trowl and keeping it as one of the best “Twitter for Growl” implementations available. I hope that’s good enough to keep Twitter Inc happy.

Tagged , , , ,

Leave a Reply

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