Twitter is too complex
Twitter is often described as simple. And it is, compared to services like Facebook and Last.fm. Simplicity is usually a Good Thing in a web service. The simpler the service the easier it is to build, maintain and grow. Potential users understand the service quicker, and they ask fewer support questions. Investors will get the idea quicker, too. The efforts of the team are more focused, so they're likely to make a better service. If your users want more features, that's not a problem either. The web is designed to be good at linking to other external services which can provide them.
Despite the compliments, I don't think Twitter is simple enough. As an example, let's consider the process of making Twitter friends:
There's one main friend-making operation in Twitter - 'following'. If I follow you I receive your messages. if I 'unfollow' you I stop receiving them. Seems pretty simple? Well, because it works both ways this one operation still creates 4 states that our relationship can be in (no relationship, I follow you/you don't follow me, you follow me/I don't follow you, and finally we both follow each other), and 8 ways that we can move between those states. With care, that much is possible to explain to the user, as well as to engineer in a simply and scalable way. It would also be possible to build a simple API, allowing other developers to easily add data, and value, to your service.
But Twitter does not stop there. They've allowed two further operations. If you don't like the look of me, then you can 'block' me, which means I don't receive any more messages about you. You can also choose to protect your messages, which means that I only see your messages if you 'approve' me. Those seem like sensible features, and they are common elsewhere.
The problem is that those two new operations have doubled the complexity of the system. They introduced at least 3 new states and 10 new ways of moving between states. (Twitter does not describe exactly how the system works in their documents, and I lose the ability to count exactly without spending hours creating and playing with test accounts). Every one of those new states and transitions will create some confused users, support calls, and rack up engineering hours. Developers using the API will either keep their applications very simple, or encounter unexpected errors and headaches.
I'll bet that the return on investment for these extra features is poor:
Few users protect their messages, and arguably those people would be better off on Facebook or similar services with strong privacy features. Users with protected updates are probably worth less to Twitter too, because there will be restrictions on how their data can be used.
'Blocking' seems essential, but I'd argue that a separate 'report spam' button and the existing 'unfollow' button are just as good. Worst of all, once these features have been added it is very hard to remove them.
As a regular user, and also as an occasional API user, I hope that developers of the next generation of web services keep their systems even simpler. It's better for everyone that way.
Tagged: Media
Posted at 21:49 GMT, 27th October 2008.
Last changed at 21:57 GMT, 27th October 2008.
6 Comments
Add a new comment.
Nice to see you posting again.
Since Twitter decoupled accepting a follower to a protected feed from following them back, I think they've done a pretty good job at making those features independent.
It's a little unfair to take the combinatorial explosion of possible options between them, so long as the system really can be decomposed into different pieces.
I may be missing what you mean by 'ways to move between them' but as I see it for the basic four states, there are still only really two options to change state: A follows B and A unfollows B. You can parameterise A and B with any user, but that's still just two operations.
I'm sceptical of the value of 'private' feeds, since twitter has had a few examples of failing to uphold that contract, the latest via the search page. I'm pretty sure I've still got a method to snarf others' private feeds, if I can entice one of their logged-in followers to a page of my construction. One day I'll write the full exploit and report it to them a third time. My proof-of-concept worked just fine a year or so ago.
I also haven't grasped the value of blocking followers, since spammers could always consume the public feed for that user anyway. For private feeds it has a role, but presumably there's a separate 'unapprove' option of some kind. As a public user, I don't think I should be offered 'block' links, since I cannot see what that really stops someone doing.
You're dead right that once you start promising this stuff, you're slightly stuck with the choice. The lesson there for upcoming services is probably to promise carefully so they can really deliver on those promises. I'm still shocked that more folk don't revolt every time there is some kind of privacy leak in the various 'privlishing' systems (Facebook et al).
Actually, I was wrong. The most recent privacy slip from Twitter was some XML-based jiggery-pokery last week. I reported the search cock-up to them nearly four weeks ago.
Ah, well.
@ashok Thanks for your comments, and agreed that there are also broader difficulties in claiming to offer privacy.
I'm not going to claim to have the Twitter state and transition count exactly right. The system is sufficiently complex that it would take a while to figure that out. For this reason, I've been conservative, and not counted every possible combination, only the ones I am sure exist. The other states that definitely exist are 'pending' (I asked to follow a protected user, they have not accepted) and 'blocked' (a user won't let me communicate with them).
I suppose that a user or developer might be able to think of pending and blocked separately from the main follow system (decompose), but does that make things much easier to handle? Have you not just moved from one complex system to three simpler systems?
That would be exactly what you've done, and I'm pretty convinced that's a benefit.
I suppose a good test of whether you can really treat some of those extra features as really non-interfering would be if you could happily proceed ignoring that they exist.
I think that for blocking, for many purposes, you can ignore that it is there. I'm sure there will be some extra error messages or cases, but a reasonably defensive program would be fine.
For privacy, on the other hand, that trait seeps into nearly every other aspect of things, and means you require to authenticate as a suitable user in order to get almost anything useful done regarding the 'private' user. That's much more tightly coupled.
I'm with you that services should think carefully about the essential complexity they require of their user/developers, which is mainly what you're talking about here. I just don't mind quite a bit of optional complexity, if it supports some reasonable user-need.
I fear the greater complexity with using Twitter's API is in how to handle the really hard to test things around reliability. You can code defensively, but on several occasions I've got very strange error messages when Twitter is in some tricky state as they try and solve their really hard problems. The hardest to track down was when they changed the API rate limit but over the message format I was using only with a very cryptic error message getting as far as my code ('r' if I recall correctly).
I was prompted to write this because I found I could not ignore either blocking users or pending friend requests during a recent project. Initially I thought I could, but the states and transitions I mentioned in the original post needed to be taken into account to not cause difficulty with my app.
I agree that poor definition of the various error states is also a problem. Many of these cryptic error states are generated as a result of protected and blocked features. Twitter currently seems to give a plain text description of the problem (except where they just time out (too common recently, or send a 500). It would be great if they defined some more more rigourous error states, perhaps with code numbers. I noticed last week that this is done nicely in the new Netflix API
Also, optional complexity seems like a good idea, but I wonder how often you can truly separate it from the core features for everyone involved (investor, user, API user, developer, designer, ops)?
It certainly requires very careful thought.
Add a new comment.