Do you want your service to keep state for you? Comparing the Twitter and Facebook APIs
I love the Twitter for iPad application and how Loren et al have built an experience that feels right in your hands. There is one bug though that can drive me crazy, and that is the fact that the unread state of direct messages is broken. It feels like 99% of the time I will open up the application and the last 20 messages will have unread:true, even though I know I have read those messages. The bug is particularly irksome because it is so in your face. The messages tab is highlighted as though there are no items even though I know there is nothing new for me (and I just need to go through again and mark them all as read? ugh).
It made me wonder how Twitter was handling the state of direct messages. In creating Facebook for webOS we built out FB messaging, and the state was handled for us. The Facebook design has the notion of threading baked in (as apposed to email for example) and is as follows:
- A user has multiple mailbox folders (default messages, sent, updates)
- A folder has multiple threads
- A thread has multiple messages.
So, where is the unread flag kept? You may think that it is at the message level… after all, it is a message that is either read or not. However, the thread actually controls the flag for Facebook. This means that in a conversation there is basically an int count that shows you how many messages are unread. If zero, then all messages in the thread are read. There are trade offs on having the unread flag be a count and not a flag on the message layer, but the high level point is the core platform is keeping track of what a user has done. Whether you go through the website, or any application that speaks the Facebook API, as long as your application doesn’t cache too aggressively, you will have a good result. The key becomes: as the platform developer you very much understand that the service is the master, and you need to be smart about caching data to give your users a responsive interface, but make sure to sync on the data to make sure it is accurate.
The Twitter API on the other hand doesn’t appear to keep any unread state for messages. Echofon is a cross platform client that showcases its support for syncing this kind of data. It is a nice feature for them to be able to differentiate on, but man….. it sucks that they have to write it!
I hope that Twitter starts to own the state so we aren’t in the current situation of no one really knowing my state, and it has been interesting to see the different state of affairs, and have you thinking about what the platform should be doing, and what should be left to the clients of said platform.
October 11th, 2010 at 5:00 pm
Also something for Twitter competitors/alternatives to differentiate on as well.
October 11th, 2010 at 5:13 pm
In the meantime, it seems like your problem could be mitigated if they added an easily-accessible “Mark all as read” action on Twitter for iPhone/iPad.
October 11th, 2010 at 5:27 pm
I’ve been complaining about this for a while, its not an issue of the client having a “mark all as read” button. My issue is that I have: a phone, an iPad, iPod Touch, laptop & desktop. Why should they all notify me all the time.
Example. I’m working on my Desktop all day, reading (with growl) my timeline all day. Then I switch over to my laptop, now I have 300 growl notifications going off when I login. Its a repeat, now add the ipod, ipad and phone in. It gets really annoying to be notified of all these messages that “have been read” all day. But if the API had state, it wouldn’t show them all as unread juat because I opened my phone.
October 11th, 2010 at 6:04 pm
I definitely prefer that state to be managed by the service. One of my pet peeves about iTunes is that it doesn’t maintain state across all the systems that I use to access my library. I would have much preferred a real cloud service addition to iTunes than the Ping rubbish.
October 11th, 2010 at 8:38 pm
Andrew,
Absolutely. Good UI can hide all kinds of sins.
D
October 12th, 2010 at 4:40 am
This is similar to how I have to manage read/unread messages, @reply and @dm’s in Birdwatch for WebOS (http://developer.palm.com/appredirect/?packageid=co.uk.leedjones.birdwatch), storing the highest IS for read messages both of public and private type. The problem with this is that its device dependant and susceptible to device errors (such as failing to read the cookie etc). Would be nice for it to be managed via the API.