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.

A perspective on my writing

A little something for a Friday afternoon. With thanks to Ashok and wordle.net

The new iPhone - good, not great

I'll be buying an iPhone on July 11th. With 3G, GPS and lower pricing this is now a very attractive product. Apple's ability to make browsing and maps work smoothly on a mobile device is unrivalled now, and I expect I'll still own a leading product at the end of the 18-month contract.

However, there are two significant annoyances that temper my enthusiasm for the iPhone.

Mobile Me, a new data silo

Push updates to mail, calender and address book are helpful, but the world has moved on from desktop apps. It is not very helpful to sync with the data that sits on my computer, because that is going to be more out of date than the stuff on my iPhone. And no, a new set of web apps from Apple does not help, however nice they are. Like many people, I've already chosen apps on the web that look after my data. I use Gmail/Google calendar, Remember the Milk and occasionally Flickr. So do lots of other people, and I share stuff with them. When the iPhone was originally announced, Google and Yahoo were a big part of the party, but there has been no mention of integrating their products with Mobile Me.

I live in hope that Apple will offer great integration with a wide range of web applications. That way they could extend the Mobile Me market to people like me, and probably even bring onboard some new iPhone users.

No background tasks = much worse device for media

3G is of limited use for watching video. A decent iPhone video is at 512kbits - a rate not reliably available over 3G. The EDGE terms and conditions (at least in the U.K.) explicitly forbid audio and video use, so I would not be surprised if some kind of contractual limit was applied to audio or video unlimited 3G bundles too. Therefore, the iPhone should be downloading media in the background via WiFi (and 3g if possible) whenever it has coverage. This would allow me to leave home with a device synced from home WiFi with the audio and video content I might want to consume today. If I pass WiFi at lunchtime I can top up, maybe just with a few news clips that are integrated into the news application, or maybe with a show that has just been released.

I am enthusiastic about the new notification services that Apple announced. They are a hepful extra feature for many applications, but are not enough for audi and video. Notifications allow a developer to push a message to an iPhone, essentially "new stuff available" in various forms, but the user will have to open the application and wait while the 'stuff' downloads. That is fine for an instant messenger client that is downloading text, but useless for audio and video. Webware also pointed out that Apple could do worrying things with the notification data that flows through them.

The announcement was pretty misleading on this point. They explained the perils of allowing applications to run in the background - essentially that they can eat resource that could be needed to complete the current task. That is an important consideration if the current task is an incoming call. During the announcement, the assembled Mac developers had a good laugh at the Windows Mobile solution. It seems that Microsoft allows the mobile user to control resource usage via a series of geeky charts and tables. Of course this won't be included on the iPhone any time soon, but it's not the only way to run background tasks either. For example, Google Android allows background tasks, and has a sophisticated system to ensure that the phone call app can always take the lead when required. It is complex for the developer, but simple for the user. I have heard it works well.

The logic for including proper background process handling seems strong. I hope Apple are working on it.

Freesat most popular with older viewers?

Catching up on feeds, I noticed this interesting post from Hitwise about the trend in viewers to the Freesat website. Freesat is a subscription-free U.K. satellite offer, launched by broadcasters the BBC and ITV.

For me, the most interesting analysis is that: "Freesat appeals to an older audience: 43% of visitors to its website last week were aged 55 and over, compared with just 20% for Sky."

If the platform demographic is consistent with this early web data (clearly far from certain), this is bad news for broadcasters. Freesat's unique selling point is subscription-free HD. Most new technologies appeal to a younger demographic, a group that is typically hard to reach, and often captured/intermediated by players like Sky.

Broadcasters will have hoped that Freesat would improve their connection with young audiences. Instead, it appears to be striking a chord with their existing heartland.

Thinking about Data Portability Business Models

I've been following the Data Portability initiative with interest. There is lots to read on their site, and the sites of many participants. (As you should expect, the debate is pretty portable across sites).

I think about data portability in terms of a simple use-case:

I'm a user on a photo site, and I want to edit my photos. I can configure the photo site to launch a web photo-editor of my choice, and pass the photo to the site. I can edit the photo, then pass it back to the photo-sharing site. Neither site was aware of the other in advance. They just supported a common way of passing data about.

(This is not my idea, but I can't find the website where I first read it…)

It is like a supercharged version of the way that plugins work in desktop software. A very exciting development from a technology and user perspective, but also exciting in terms of industry development.

Taking a macro view, this kind of interaction is bound to increase competition, which means better services for users. As an illustration, I'm struck by the strong support of Strands for Data Portability. Strands are well resourced by start-up standards, with some very experienced engineers and scientists working there. It seems that most of the effort goes into a serious recommendation generation technology, which has every chance of being world-leading. They have a consumer-facing product for recommending music (and music videos), and a newer financial recommendation product. In music, at least, they look like an also-ran compared to the market leader, last.fm. That is a shame because their underlying recommendation engine is probably better.

Data Portability offers the prospect of picking software components in the same way that you pick products at a supermarket. I can choose the last.fm music community, but log in with a Google account and use the Strands recommendation engine. Or I can just stick to Google brand for everything, if that's how I like to do things.

It might sound great for users, technologists and macro-economists, but we're not very far along, and there are many obstacles to overcome. I reckon this world will come eventually, and quicker than we think, because the Internet is fundamentally a competitive place, with barriers to entry much lower, and speed of innovation much higher, than in most physical industries.

So, the question: Where is the money?

The Data Portability group have some initial thoughts, but it is still early days. One of the main participants has a specific interest in broadcast, which looks interesting. Social Times also has an interesting perspective.

I don't have a firm answer to the question, but it is important to us at Meta Broadcast to understand what might happen, so I'm spending a fair amount of time trying to figure it out. I plan to blog my thoughts and join in the discussion.

This is where I got to so far:

The business of running a 'social network' (user accounts and some very important information like links to friends and demographics) is likely to be critical to on-line advertising networks such as Google, Microsoft. Possibly Facebook can also join this gang, if Mark Zuckerberg stops doing things in a careless way. There are likely to be strong economies of scale in this business because ad buyers like to go to one place to buy large audiences. It's no place for a start-up, unless they have a market-shaking idea AND lots of cash.

As for other apps? I wonder how far the supermarket analogy can take us? In a supermarket we choose on distribution, brand, price, perceived quality, and perceived convenience. You can build a nice business if you own a good brand, which you build through a mix of good communication and doing a good job. That suggests that someone with a big brand can market multiple components to consumers. The Internet equivalent of Nestle - a safe but basic choice for lots of products.

What about a niche brand? I'm a huge fan of Tunnock's, a Scottish biscuit brand. They're very successful, and all about their Victorian working-class roots. There will be space for niche brands too. But, just like Tunnock's, a niche brand will need to get good distribution. I wonder whether that will get cheaper or more expensive? Niche Internet brands will also need to ensure compatibility with the consumer's other choices. That is a problem that Tunnock's don't really have. Maybe this is a place where incumbents will be able to trip up newcomers?

Brand clearly won't be the only helpful asset. Some data will also remain a competitive advantage. If you have a nice enough brand you can attract people to give you privileged access to their data, which you can carefully use to build the competitiveness of your service without causing privacy concerns. How far you can go is another big question.

Data Portability could make a massive difference to the way that Internet businesses create value, and bring real benefits to users. Now is the time for businesses to think carefully about how it might affect them.

I'm looking forward to talking to some smart people about this stuff during the next months, and reporting back here. Do let me know what you think.

UPDATE: There's a fair bit of criticism at the moment about the ratio of discussion to action among members of the Data Portability group. I'm inclined to agree that more implementation should come before detailed discussion (that is certainly the approach we are taking with URIplay). However, the principles behind Data Portability are important, and the practical effects are likely to be felt sooner rather than later in some application areas.