I generally like TweetDeck as a Twitter client, despite the occasional usability challenges of AIR applications. I love having multiple columns to monitor conference hashtags and important (or silly) keywords. Lately, network problems have affected how I use TweetDeck to communicate and it puts a spotlight on a bit of bad user interface (UI) design that otherwise wouldn’t be noticeable.
As an Internet-aware desktop application, TweetDeck makes a lot of simultaneous asynchronous calls to social media web services to get data: your Twitter timeline, @ replies, direct messages, Farmv^H^H^H^H^HFacebook, etc. After making a request, the program doesn’t sit and wait for each request to come back from the server before displaying things it has already received. This somewhat complex idea is critical to a good user experience – the UI becomes much more responsive to the user.
Lately Twitter seems to be having problems serving up user profile images; my timeline loads, but the photos of the people I follow don’t appear until quite some time later (see right).
I suppose this could be a problem in TweetDeck, but my guess is that the Twitter API is throttling (slowing down) profile picture requests to shunt resources to service other requests. Load shifting is common in hosted services, and I for one would rather Twitter prioritize updates from users in Japan, Libya or Wisconsin over serving my ugly mug around the world.
Here’s where TweetDeck botches it: the reply and retweet buttons are grouped as part of the element that displays tweet-sender’s pic. The buttons aren’t available until after the photo loads. Sometimes it takes up to ten minutes. It’s really frustrating to not be able to reply in real time during a conversation without retyping screen names or Re-Tweets by hand. The object of good UI design is to save the user from doing things like that. I might as well use a command-line Twitter client. 
I finally found a workaround by digging around in TweetDeck’s preferences – the Heads-Up Display (HUD). To reply to an update before the photo has loaded, you can select the update with the mouse and hit the spacebar to bring up the HUD (see left).
All the goodies are right there. If you change your mind about replying, hit Esc to close the HUD.
It’s almost certainly possible to have the buttons always be present – hovering over the empty space where the photo would be – if you design for it. These sorts of issues almost always come to light once systems go into production. If I may adapt von Moltke: No software design survives contact with the intended user. Every service call can fail. It’s really hard to predict interactions between multiple asynchronous service call failures, but I think this one could have been caught during development.
I’m using TweetDeck 0.37.5 on OS X as I write this. I look forward to the day when this blog post is irrelevant.