I’ve started using Twitter quite regularly. It has become a major part of my online life, and allows me to have social interactions that I would normally miss when working or studying on my own. I currently use the Twitterific client on my Macs, and the Tweetie client on my iPod Touch (I still don’t have an iPhone!!!).
As it currently stands, the Twitter API doesn’t support any kind of “Read/Unread” data for your incoming tweets. This omission keeps the API lean, simple, and unambiguous. It also prevents shoddy clients from inadvertently messing with your account data. On the other hand, it is responsible for the largest frustration in my overall Twitter experience.
Let’s say I spend a day coding at home on my Mac Pro, and I read a few hundred tweets. As I read them, I mark them as Read within Twitterific by clicking on them, or by selecting “Mark All Tweets as Read” in the Twitterific Dock Icon’s contextual menu. The next day, I go to university with my iPod Touch or my MacBook. I open up Tweetie, or Twitterific, and I have a choice - do I adopt a “Twitter Inbox Zero”, kamikaze approach to reading my tweets, skipping straight to the latest ones, or do I read through them all until I reach the first (and therefore oldest) Unread tweets?
Obviously it would make the whole experience a lot nicer if Tweetie knew what I’d read in Twitterific the day before.
There are two different ways that Twitter could extend their API to solve this problem:
Add a Read/Unread status flag for each tweet.
Add a “Last Read” field that contains the ID of the last read tweet.
There are pros and cons for each approach, and there are situations where client apps could implement either one poorly, but the second option has one obvious use-case scenario that makes it a bad choice:
Imagine that you had 200 new unread tweets, and you (or your client app) accidentally marked the most recent one as Read. If the “Last Read” approach was being used, the other 199 unread tweets would become relegated to the “Read List” due to this single careless mistake. Using the other approach (having a Read/Unread status per tweet), there are far less ways that you (or your client app) could bork your Twitter status data.
If a Twitter client app developer decided that they couldn’t come up with a satisfactory way of implementing the UI for Read/Unread statuses (or they were just lazy), they could safely ignore the Read/Unread data, and things would work exactly as they do now.
The only possible downside is that Twitter’s back-end infrastructure may be so heavily engineered around the current data and usage model that adding any new features involving more regular writing of data would lead to performance issues. Since I don’t know how their API back-end is architected, I can’t say how big a deal this would be. Depending on how things are connected in the back room at the Twitterplex, it could mean that significant work would be required to get Read/Unread status flags implemented, or it could mean that it is relatively trivial.
In 2009, Everything Syncs!
It seems somewhat quaint that in the age of freely available synced email, synced news feeds and synced files, I have to spend a few minutes manually “syncing” my Twitter clients every time I switch devices. If Twitter want their service to be all it can be, they need to work to remove any sources of friction in the user experience. High on their list of priorities should be adding Read/Unread statuses to their API, giving a seamless experience to those of us that use multiple devices.
Here’s hoping that in 12 months time, I’ll be able to open up any Twitter client and have it jump straight to where I last left off, no matter what client or device I am using.