danlucraft /blog

Twitter Forgets to Abstract, Again

April 2010 • Daniel Lucraft

Lists are cool and Twitter’s new Annotations feature is a game-changer. But, as a programmer, there is one little niggle I have with both.

Both features enshrine special cases into the Twitter data model.

Lists

My following information looks like this:

{
  following: [@mithulucraft, @soundboy, ...]
  lists: [
    "ruby":  [@dhh, @Georgio_1999, ...],
    "funny": [@Alanucci, ...]
  ]
}

wait a minute, why not abstract this up a level:

{
  lists: [
    "following": [@mithulucraft, @soundboy, ...],
    "ruby":      [@dhh, @Georgio_1999, ...],
    "funny":     [@Alanucci, ...]
  ]
}

Consumers of the old API can always be redirected to the “following” list and they won’t notice any difference. Consumers of the new API only have one kind of thing to deal with. There would be Lists, and nothing else.

Instead we have two things to deal with. Lists, and another list-like thing that is not an actual List.

This has made Lists second-class citizens in most of the Twitter apps I use (including twitter.com), which means they haven’t been as useful as they might have been.

Annotations

Under the new system, a Tweet looks like this:

{
  date:   Fri 16th Apr 2010 21:37:45,
  author: @danlucraft,
  body:   "Finally got around to watching the Archeowhatsit presentation from 2008 
          by Giles Bowkett. WORTH IT."
  geo: London,
  annotations: [
    {namespace: "link", key: "49-61", value: "http://www.infoq.com/presentations/archaeopteryx-bowkett"},
    {namespace: "user", key: "75-88", value: "@gilesgoatboy"}
  ]
}

(That’s an example of an entire class of service - url shorteners - that annotations make obsolete by the way.)

Instead, we could have:

{
  annotations: [
    {namespace: "tweet", key: "date",   value: "Fri 16th Apr 2010 21:37:45"},
    {namespace: "tweet", key: "author", value: "@danlucraft"},
    {namespace: "tweet", key: "body",   value: "Finally got around to watching the Arch..."}
    {namespace: "tweet", key: "geo",    value: "London"},
    {namespace: "link",  key: "49-61",  value: "http://www.infoq.com/presentations/archaeopteryx-bowkett"},
    {namespace: "user",  key: "75-88",  value: "@gilesgoatboy"},
  ]
}

Again, consumers of the old API will only see the “tweet” namespaced stuff and won’t notice any difference. Consumers of the new API will only have one kind of thing to deal with.

Instead, a Tweet contains two kinds of things: pieces of data called ‘annotations’ that can contain anything, and also some other data too.

Irritating, but not important

I should say that although I find this annoying (and I guarantee any other programmer will as well), it’s not important.

Programmers spend a lot of their time looking for ways to turn 2 kinds of thing into 1 kind of thing, and when we are able to do this we call it “elegant”. It’s just a quirk we have.

It does make Lists a bit like second-class citizens, but annotations are going to be just as massively useful. People like me will just have a little bit more work to do.

The Platform

One more thing. Twitter is turning itself from a social network into a gigantic tuple-space pubsub platform that just happens to have a big social network implemented on top of it. Both of the above decisions grandfather the social network into the design of the platform.

In the short run that’s great for the social network but in the long run … will it restrict the platform?

blog comments powered by Disqus