How Twitter works

Perhaps I’ve got this entirely wrong. And if so, set me straight, here.

But I’ve been analysing Twitter – what it is, why it works, what makes it unique. It’s just the way my brain likes to do things.

And I broke it down like this. There are two principal things going on here:

1 – the maintenance of a user registration system. This allows users to sign up, create a profile, set a contact email, control visibility to others, follow/unfollow others, manage direct messages, block other users, and generally perform a whole suite of tasks that (in my simple world) can be described as:

user profile administration

…and once you’ve played ball in setting up a user profile, you are allowed access to:

The Main Event…

2 – a vast, completely freeform soup of tweets. Literally billions of <=140 character messages that have a couple of little code characters tucked into them: ‘@’ and ‘#’. Both let you (or to be more accurate, your client application*) parse** the soup in ways that make sense to you.

e.g.1. select all the messages beginning ‘@yourname’ and you have your ‘@replies’.

e.g.2. select all messages containing ‘@yourname’ and you have ‘mentions’

[Twitter has buggered around splendidly between terminology over ‘replies’ and ‘mentions’, but these just mask some very simple concepts.]

e.g.3. select all messages containing ‘#hashtag’ and you get a nice user-customised feed relating to a particular hashtag topic… and joy of joys, any user can create a hashtag on a whim, and see where it gets to.

e.g.4. select all messages originating from a particular user, and you have their Twitter feed.

And. That’s. Just. About. It.

What makes it so special is the purity of that soup. Ideally it should be unadulterated – served from the tureen neat so that your particular client application (however you’ve set it up) can season your bowl of soup as you desire.

Your client application may carry out these functions in different ways. It may even restrict you from seeing certain ingredients. But the point, as the #fixreplies issue has shown, is that the USP was Twitter’s completely open approach to offering the soup for seasoning.

Once you cut out all the carrots (to push the analogy just one more time) and removed all ‘half-conversations’ – go and read #fixreplies links if you need more detail – you’ve adulterated the recipe and created something different.

I see tonight that Twitter’s blog says there are tech issues that led them to make the #fixreplies change. I don’t buy that. If Twitter operates as it does in my head, and described above, that soup doesn’t need processing – it’s the sum of billions of short character strings. It’s how various client applications operate that generate technical issues, for each client, if any…

So #fixreplies is a big issue. It mucks about with what was a completely open approach to freeform, user-generated messaging. The old cliché: “you get out what you put in” was never more true than of Twitter. Although personally, I find the Rizla strapline: “it’s what you make of it” more accurate.

Let’s hear it for keeping it open, pure, interpretable, subvertible, hannibal, cannibal, mandible. But that all begs the question of where the business model lies.

I welcome your thoughts…

🙂

*this could arguably be seen as the third part of the Twitter mix. As well as user admin and a big bowl of tweet soup, you need to be able to access and process the soup. That’s where clients come in. Twitter has its own client applications, web and mobile (and they’re pretty basic) but the Twitter masterstroke was an open API (application program interface) that allowed any other chancer to write software to process the soup as its users desired. I’d argue that Twitter’s job is to run the user admin and the API and leave everything else to evolve organically.

**to parse – for those not familiar with the word, my definition is: to interpret a bit of information (due to its formatting or context) in a particular way that makes more sense than just reading it literally.