This morning i was shocked to see tweets of people i don't follow. Turns out it's half as bad as it initially looked and the reason is an API change from twitter.
For whatever reason, Twitter seems to have rolled out an api change before Twitter Clients have implemented the necessary changes to deal with them.
The changes are concerning retweets. There's a new way retweets are handeled in a users timeline XML. Twitter is effectively stripping out the RT parts of the tweet text (making them invisible to the user) and includes them as meta data into the XML:
<retweet_details> <retweeting_user> ... </retweeting_user> <retweet_count>1</retweet_count> <retweet_id type="integer">4043457594</retweet_id> <retweeted_at type="datetime">2009-09-17T01:15:32+00:00</retweeted_at> </retweet_details>
Today, there's only few Twitter-Clients which already support this new XML and this is where the problem starts. As the RT part of a tweet is now effectively hidden to anyone not supporting the new XML format, a retweet might be displayed as if it is a message from someone you do not follow (if someone you follow retweets someone you don't).
TwittelatorPro 3.2 already supports the new format and indicates the retweet (RT) in the upper right corner of a tweet
Twitterrific (3.2 Mac) doesn't support the new API and thus it looks as if i received a tweet from Trisha which i do not follow. Shock and awe!
Update 1: These changes are clearly documented on the twitter API site, but contrary to the documentation, the changes affected friends_timeline.xml (at least for me) also and not only the new home_timeline.xml!
Update 2: It is possible, that i misinterpreted this and twitter didn't accidentally roll out any changes to friends_timeline. It may well be, that Andrew Stone (he retweeted Trisha as seen in the screenshots above and i am following him) was simply testing the new features using the statuses/retweet API call.
But still, even if he did, the RT shouldn't have arrived in my friends_timeline (in that new format).
That is why other services use versioned APIs and don't bend live APIs at will!
On September 10th, i promised on twitter to eventualy come up with a mockup of a better, more usable way of managing iPhone apps in itunes.
My point is, that i believe in the current itunes 9 implementation, Apple simply transferred the iPhone's quirky way to manage home screens onto the Mac and substituted the finger with a mouse. Not taking into account the benefits of a much larger screen size on the Mac (or – god beware – a PC).
I am making use of the much bigger screen estate by placing the home screens side by side and by using a so called Dropzone where one can park icons to move them across screens (just like you park stuff on your desktop) which might not be visible and need to be scrolled to.
What is not implemented is multi-selects, reordering of home screens and sorting of apps (which is also needed e.g. sort by most used), as this is beyond the scope of my little experiment.
This is a functional concept and not intended to show off my graphical skills.
Big thanks to jQuery for making it possible to sketch up such a simulation in almost no time!