The application was designed to send automated tweets on Gemma’s behalf from her personal Twitter account giving updates of her progress to those following.

Mainly the tweets would report her current location for the purposes of spectators waiting ahead, others would be sent at intervals of a mile or so to report pace and ongoing form.

Similar to the mechanism for fetching Instagram images at predetermined locations on the course, the application contained a list of agreed points at which to tweet.

These were at landmarks and certain spectator spots too, but also at course milestones — the first mile complete, halfway complete, one mile to go etc, as well as the start and finish.

The application monitored the elapsed distance and updated accordingly, grabbing the latest time and statistics from the RunKeeper data, as well as geolocating the tweet with the latest set of GPS coordinates.

Since Twitter deprecated support of Basic Auth, applications much authenticate users with OAuth to gain write access.

This means rather than handing over your username and password to applications and trust (hope) that they’re friendly — as used to be the only way — OAuth allows applications to request access on your behalf without users ever parting with precious login credentials. You simple give, or deny, permission.

Using TwitterOAuth

Twitter offer a number of links to OAuth libraries for various languages to make the this job a lot easier. There are many Twitter specific OAuth libraries in particular, purposely tailored for the API.

I picked up PHP-based TwitterOAuth by Abraham Williams, which gets you up and running very rapidly.

The OAuth flow is documented at length, but essentially performs three major tasks:

• Obtains access from Twitter to make requests on behalf of a user
• Directs a user to Twitter in order to authenticate their account
• Gains authorisation from the user to make requests on their behalf

This is achieved with a cycle of exchanging authenticating tokens between application and Twitter to verify permission. TwitterOAuth particularly creates a session object in your application and rebuilds itself with each token exchange to remain contained in a single class instance.

In a very abridged manner, something like the following:

// Build TwitterOAuth object with client credentials
$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET);
// Get temporary credentials to allow application to make requests and set callback
$request_token = $connection->getRequestToken(OAUTH_CALLBACK);

This initial call verifies your application has access the Twitter API, basically that it’s registered and good to go. Twitter returns two tokens, if successful, that we store:

$_SESSION['oauth_token'] = $request_token['oauth_token'];
$_SESSION['oauth_token_secret'] = $request_token['oauth_token_secret'];

Then the application sends the user to Twitter to authorise it’s access, using a URL generated with the token received above:

$authoriseURL = $connection->getAuthorizeURL($request_token['oauth_token']);
header(‘Location: ‘ . $authoriseURL);

On successful authorisation Twitter will return the user to your callback URL (set above) with a verification token. TwitterOAuth now rebuilds for the first time with the OAuth tokens in our session and uses the new verification token to get an a new access token which will grant us user account access:

// Create TwitterOAuth object with application tokens
$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $_SESSION['oauth_token'], $_SESSION['oauth_token_secret']);

// Request access tokens from Twitter on behalf of current user with verifier
$access_token = $connection->getAccessToken($_REQUEST['oauth_verifier']);

This final request gets us two OAuth tokens specific to the current user, allowing us to make requests on their behalf, with which TwitterOAuth rebuilds again:

// Rebuild TwitterOAuth object with user granted tokens
$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $access_token['oauth_token'], $access_token['oauth_token_secret']);

// Test that everything is working
$connection->get(‘account/verify_credentials’);

The dance made a hell of a lot easier with a library such as this.

Usually applications store these tokens final two tokens, the user generated oauth_token and oauth_token_secret, which saves the need to authorise the user again.

Storing these details (in a session or database) means that a username and password need not be saved. The tokens are good until the user revokes access, no sensitive information is ever released to the application, all the user ever gives is their permission.

With access tokens stored, the connection to Twitter is a lot simpler — just create the TwitterOAuth object with those user-generated codes as in the very last step, without any of the redirecting to and from Twitter.com. Of course, those tokens could only have ever been obtained by carrying out the full process to begin with.

Beats Per Mile is a single-user case application, so Gemma only had to authenticate the application once and then we hard-coded them into the scripts.

Tweet Away

With access granted the application was free to send out updates, based on the run data we were collecting and posting it directly.

As mentioned, locations translated into distances and that’s when we tweeted.

At mile twenty, it looked back at the mile splits so far and reported which were the fastest:

Relying on the total reported distance alone was flawed. There was a slight hiccup when RunKeeper lost GPS coverage under Blackfriars tunnel and in an attempt to compensate found the nearest location to be the other side of the Thames.

This caused a problem by adding extra distance to her total, so some of the latter tweets (“one mile to go”, for example) posted a little prematurely.

It was more of a problem for Gemma when running, the app announcing in her ear that she’d run further than she had, disheartened to see mile markers on the course thought to have already passed.

This is also why the total distance on the site clocks up to 27.65 miles, the race was long enough as it is!

The final touch to was to drop them on the map, alongside the Instagram images.

It reminded me of the ‘replies kerfuffle‘ earlier this year and Twitter’s reactive decision to review their technical decisions as a result of the amount of negative feedback they gained so quickly, their adaptability should be applauded. Biz admits they learned a lot.

What I’m getting to is that although Twitter has been near revolutionary, that now even though it’s such an important social tool – it’s still very young. Not in the sense of naivety (nor am I questioning their success), more that there is still a huge amount of potential in Twitter that we are eagerly awaiting to see come to fruition.

Here I want to talk about some of the things that I want to see, some of the things that I think are still lacking, though recognising some of the obstacles in seeing them fulfilled.

For me, the notion of conversations (as in actual conversations) and topic threads are pretty much non-existent and obviously missing. I mean ‘actual’ conversations as in direct correspondence between parties, rather than the more ‘global conversation’ reference that’s loosely thrown around when one wishes to sound informed lately.

Replies, Threads and Conversations

The function of ‘replies’ and ‘mentions’ have seen a lot of work on the Twitter platform, see their blog archives for the changes to-and-fro, but in my opinion they are still very limited.

When the ‘small settings change‘ took place in May, it turned out to be considered far larger than the heads at Twitter had anticipated. The intention was to clean up what was seen to be undesirable and confusing, though the result is arguably as vague. If you type ‘@someone’ into the status box and tweet then everyone following you will receive it, but if you click the ‘reply to’ button (which automatically puts ‘@someone’ in the update box for you) then only those following that ‘someone’ will see it. The reply button create a response message – manually typing it does not, apparently then it’s a mention. Correct me if I’m wrong.

Anyway since those changes, reply tweets now link to the original messages (facilitated by clicking the reply button on that tweet, no less). So now when viewing a tweet, the ‘in reply to [someone]‘ is actually a hyperlink to the status update to which the user has replied.

This connection though, is only one way. And that’s the main crux of everything I’m going to say here.

The reply is aware of the original tweet, but the original tweet does not know that it has been replied to.

This isn’t so much of a big thing in a simple two-tweet case of ‘question and answer’ (maybe), but this is what stops users and applications from easily following conversations that are taking place.

For example, look at the following illustration of a conversation over four tweets:

The messages read A through to D, chronologically, with each tweet replying directly to the previous. Without having witnessed these tweets being sent, the only way to follow them is essentially backwards. Each reply has a link to it’s original tweet, so starting with D, you can click through C, B and A to reveal the point of origin.

This is the problem. Tweets have no forward links to their replies.

In the above case:

1. Tweet B is aware of tweet A (though A is unaware of B).
2. Tweet C is aware of tweet B (though again, B is unaware of C).
3. Tweet C is unaware of tweet A, even though it is linked to tweet B which is aware of tweet A.
4. And so on, the coupling continues with D (and E and F, etc).

 
Without creating links in the forward direction of the conversation, structuring and viewing threads like this is almost impossible without some serious archive mining.

Regardless of whether users wanted these changes to happen or not, I don’t think they solved the problem they set out to anyway. They were put in place to clean up timelines, removing conversational tweets just like these because seeing without context they’re almost always irrelevant, having been written in 140 characters. But now, if someone was really interested as to the answer of tweet A but they didn’t follow @birdsigh (or any replier), then they would never know it had even been answered, not only because they don’t get @birdsigh‘s tweets but because they wouldn’t see tweet C either anymore.

If tweets had references to those that reply to it, anybody could see responses from everybody.

True, conscientious users often retweet replies that they’ve received if they are of value, but this can look a bit weird – seeing a number of usernames (including their own) then the message, like so (see the duplication of @aral):

So here’s another problem that Twitter are already on the heels of answering – with the new retweet functionality Biz mocked up, looking far cleaner and a lot smoother – no need to paraphrase or condense tweets to fit in n amount of usernames who deserve props.

I mentioned the archive mining – Twitter’s Search API has something almost there. If one of your results is a reply, there’s a ‘Show conversation’ button which expands to show nearby (?) tweets between the two participants. It shows the thread, yes, but it’s not that reliable – it can include tweets that weren’t direct replies to the others, rather mentions that were chronologically in between. And none of that is in the main API anyway.

Visualising conversation

That’s another thing – there’s no single place or any really decent way that I’ve seen to visualise this kind of information right now. It would be nice if the ‘in reply to’ link didn’t need a page change to see the related tweet.

Some of the desktop AIR applications try to solve this problem, for example, DestroyTwitter has a nice dialogue box – but only shows pairs of tweets, so you still have to click through:

TweetDeck has a similar view to the Search page’s conversations, showing the latest tweets between two participants, filtered to those mentioning or replying to the other – so again it does show correspondence, but it’s uninformed – you can’t select a thread and show only that and here too you see unrelated and old tweets also.

I’ve not seen any application that shows conversations involving more than two participants.

It’s interesting that phase one of ‘Project Retweet’ introduces a ‘retweet’ button, something that’s been around in the desktop apps for a long time (even if on their part it’s a crude copy-and-paste with the additional ‘RT’ prefix added). Like Biz said, some of the best features are emergent – so it wouldn’t be so surprising if, seeing how desktop applications are already attempting to visualise threads like this, they might one day materialise on Twitter.com as a fully fledged feature.

What’s to come?

The Twitter API documentation now has some timeline methods labelled as ‘Coming Soon’, those for the new retweeting API. One of those is the statuses/retweets_of_me method, said to ‘return the 20 most recent tweets of the authenticated user that have been retweeted by others’, (here).

Woop! That does mean forward linkages right?

If tweets can be tagged to inform that they have been retweeted, surely its somewhere possible to also inform that they’ve been replied to?

Back to visualisations, it’s be great if Twitter had some pages similar to these to show retweets and conversations (respectively):

Okay, it’s easy to see one improvement and make an assumption that it can be applied ‘exactly the same way’ elsewhere. As as developer I know that and get tired of hearing those kinds of requests

But it’s good to hear that these improvements are but ‘phase one’ of what’s to come. Maybe all of this has been recognised, in store – maybe already in development! Who knows. I’m sure I’m not alone in wanting something like this.

I mentioned the idea of threads with more than two participants. Immediately my idyllic conversation view above falls apart right here if you want to see a whole topic of multiple threads on one screen.

I guess you could check for any replies to a given tweet and any replies to those replies exponentially, presumably listing them all chronologically, but you’d miss out on the direct correspondence between individual users.

That kind of non-linearity is another great thing about Twitter, you don’t really get that anywhere else. Take for example correspondence on blog posts – if someone has something to say in response to a post then they can comment, but if in reply to that comment the person wants to write a second lengthier response, is the comments section the correct place to do it? Or would say, a post on their own blog ‘in response to’ be more appropriate – because that’s on their domain, under their name and heading?

Then there’s a weird loss of connection though, that post doesn’t appear in-line with the original post (other than a pingback, maybe) and users are confused where the topic continues.

That said, the ability to reply to multiple tweets also isn’t possible, only to reply to a single tweet and mention another user within that message to ensure they receive it.

I look forward to seeing the new retweeting functionality come into effect. Hopefully the change will be well received.

Thinking about the negative feedback the changes to replies received, I recall when Twitter stopped providing their SMS service to UK members – back then I was gutted but now that they’re back, I don’t use them anyway. I’ve turned device updates off. Things are different now, there weren’t as many desktop applications (and those weren’t even half as useful as today’s) and my way of thinking about the people I follow and those that follow me is different now too, my behaviour has changed.

The way I use Twitter has changed and will no doubt continue to do so as the platform evolves. Though I’d be very happy to see anything like what I’ve written here turn up (somehow) on Twitter eventually, I think it would change change the way we use it even more.

Update (02.09.09): Since writing this I’ve been pointed to two more applications that attempt to visualise conversation threads.

The first is Tweetie for Mac, that not only shows more than two tweets in sequence, but updates from multiple users:

  
The second is Tweader, a web based tool declaring an outright ‘new way to view Twitter conversations’, clearly also in recognition of the need for one. Tweader requires an ID of a reply update and (as above) constructs the conversation backwards by retrieving each original tweet.

Both of these do the job as best they can, but are still subject to the limitations of Twitter’s API.

For example, with Tweetie you must click a reply tweet, you can’t click a tweet and see the conversation that followed – the forward links are still absent.

Same with Tweader – try this and this.

Now although it’s the Twitter API that doesn’t offer this kind of linking, these tools are standalone applications so there’s nothing to stop them from storing their own form of descriptive data internally to allow conversations to be pieced together in such a way.

For example, upon receiving a reply tweet, one could store the ID against the original tweet ID (within their own infrastructure) so if a query is made upon the original, it’s responses can be found.

But as I’ve said, what I would like is for Twitter to support threads with a formalised API call – say with a method whereby one can submit the ID of any tweet (that is part of a conversation) and get a full node list of all tweets connected to that it, either in response to or those that came before it.

If you’re unfamiliar with OAuth, it’s an open protocol standard for user authentication. It works by allowing a user of one platform to grant a secondary platform access to their information (stored by the first platform) without sharing their login credentials and only exposing data they choose.

When a user visits a ‘consuming platform’ (the secondary application, that is) it passes a request to the native platform, the ‘service provider’, which returns a login request for the user to complete. The user then logs in to the native platform, proceeds to inform the platform to grant access to their data when the secondary application asks for it – and is then returned to that consuming platform, ‘logged in’ and ready to go.

The crucial problem with Twitter’s API is that, currently, to access password protected services, for example the ability to publish tweets, this is not the mechanism facilitating the data access. The method they use instead is seriously flawed, and dangerous.

Right now, a website or desktop application such as TweetDeck or Twitpic, simply asks for your login details with a regular login prompt. I think from that point onwards, there is a huge amount of misunderstanding to what is actually going on.

Users are not logging in to Twitter at this point, instead they are just telling the third-party application what their password is. Thereafter, the application uses that password as it chooses.

Instead of telling Twitter that you’d like a certain application to access your data, you are instead freely handing over your password to the application, you hope in confidence, that it won’t be stored, sold or misused thereafter.

Incredibly, this has gone on for a very long time. It seems the general majority of Twitter users have come to accept handing out their password to completely unknown sources. True, those aware of the dangers or generally security-wary tend only to use a select few services, but there are so many applications built on Twitter’s platform and a lot of them offer very niche, almost ‘throwaway’ services, that I can’t believe the ease and almost disdain with which so many hand out their login credentials without concern.

OK – it’s not like it’s your giving away your online banking details, but I can’t imagine this happening with any other type of account – social media or otherwise – email, Facebook or any other website, if they offered an open platform for these kind of applications to be built upon.

It’s become as increasingly accepted as the request has become more common. The problem with there being so many applications, especially the ‘disposable’ kind, is that users can forget when and where they have given their details to whom.

Say a user tries a new application but it seems not to work, it will be easily forgotten – perhaps put down to teething problems of the app or maybe it’s just not a very good app and “..nevermind”, they might not have been that interested anyway. By this point, if it was purely an attempt to capture your details, it’s too late.

Admittedly, and thankfully, I’ve never heard of anything so blatant and I hope if anything so obvious came around that the Twitter community would raise awareness and Twitter would respond accordingly.

But of course, the real targets for these vulnerabilities are the users who aren’t aware of the danger and aren’t expecting to have to look out for fishy, or phishy, sites – and the problem is informing those people.

If you’re reading this blog – that being a Web development blog and you’ve sat this far reading a post about user authentication – chances are you’re Web-savvy and you’re exactly not the type of person I’m talking about. You’re probably also not the kind of person who reuses passwords, but you also know that’s not uncommon.

In a scenario where a password is breached, if the email account that you’ve registered with Twitter uses the same password as the password you’ve just lost to the phishing attack, there would be no question that an attacker wouldn’t try the same password with every other account you’re receiving email from and connected to.

Then that becomes a serious breach.

But like I say, I think I’m preaching to the choir – and maybe being a bit harsh about people’s common sense.

Twitter and OAuth

Anyway I wanted to talk about OAuth. Twitter’s implementation is described on their wiki page for ‘Sign in with Twitter’, it performs accordingly:

• If the user is logged into Twitter.com and has already approved the calling application, the user will be immediately authenticated and returned to the callback URL.
   
• If the user is not logged into Twitter.com and has already approved the calling application, the user will be prompted to login to Twitter.com then will be immediately authenticated and returned to the callback URL.
   
• If the user is logged into Twitter.com and has not already approved the calling application, the OAuth authorisation prompt will be presented. Authorising users will then be redirected to the callback URL.
   
• If the user is not logged into Twitter.com and has not already approved the calling application, the user will be prompted to login to Twitter.com then will be presented the authorisation prompt before redirecting back to the callback URL.
   

You may have already seen it in action if you’ve used Kevin Rose’s new startup WeFollow, the ‘user powered Twitter directory’. You can see which applications (if any) you’ve granted access to in your account settings at http://twitter.com/account/connections.

Flickr also uses OAuth, you may have seen it there if you’ve tried uploading images with a third-party application.

Aside from being more secure as a technical solution, Twitter’s adoption of OAuth could have a very positive domino effect on similar and future applications. In fact, it’s been predicted that it’ll ‘pave the way’ for a whole host of new apps and more mash-ups to come – presumably using both Twitter’s data or for new platforms to be built upon. I imagine this prediction sees a point where users are familiar with the authentication process, confident that their data can be accessed securely and within their control.

As I said in my post about ‘Sign in with Twitter’ – Twitter is an incredible tool and is becoming ever more powerful and recognised as such. Although it’s not like it’s popularity won’t increase anyway, but if some people’s qualms and easy criticisms of Twitter, of which security always scores highly, are solved by these kind of platform advances, there will be no denying it as a leader, rather than a contender, in the social Web landscape.

It must be said though, OAuth isn’t infallible. Only two weeks ago, Twitter took down their OAuth support in response to the uncovering of a vulnerability, though they weren’t the only ones affected.

And then there’s phishing..

I mentioned the phishing attacks that Twitter suffered in January – thirty-three ‘high-profile’ Twitter accounts were phished and hacked. It saw a good effort on Twitter’s part for reacting quickly and fixing the problems, only two days prior they had released a notification to be aware of such scams.

During this time, Twitter was a great source for debate and argument over how to resolve its own issues.

I follow a lot of developers and platform evangelists including Alex Payne, Twitter’s API Lead, as he battled through the security breach. Another is Aral Balkan and between the two of them they voiced some fair criticisms (1, 2, 3) and argued out a lot of issues (1, 2).

As Alex says, OAuth does not prevent phishing, Twitter are aware of this. The very premise of phishing, that of dressing a trap as a legitimate and trusted source, can be extended to OAuth implementations, too – but it does make it easier to handle and by using OAuth, instead of Basic HTTP Auth, builds user trust along the way.

Up until now, Basic Auth has been a large part of Twitter’s API success – OAuth is an additional high hurdle for new developers. Twitter admit, they’ll give at least 6 months lead time before making any policy changes and they’ve no plans in the near term to require OAuth.

Alex did a good job of pointing out helpful resources and blog posts for those joining the debate. One was Jon Crosby’s post about the phishing attacks, which, as he says, is a great explanation of the correlation of OAuth to phishing attacks – which is to say, essentially none. It’s short post but clearly outlines the difference between authentication and authorisation – and in Alex posting it, shows Twitter’s awareness of the problem and understanding of what OAuth is and is not.

Another was Lachlan Hardy’s post about phishing (via), which extends Jeremy Keith’s proposed ‘password anti-pattern’. Keith thinks that accessing data by requesting login credentials is unacceptable, a cheap execution of a bad design practice. But interestingly he goes on to talk about the moral and ethical problems that developers experience – that although users will willingly give out their passwords and Basic Auth is an easier process to implement, as well as being a lower barrier of entry for users (again, look at Twitter’s success with it), we actually have a duty not to deceive them into thinking that it is acceptable behaviour.

Keith also talks about the pressure of the client, their need to add value to their applications ‘even when we know that the long-term effect is corrosive’ – but when I read that, posted from Alex remember, and having read his thoughts on security from his own blog, I wonder if Alex is hinting at something about Twitter outside of his control..

He is the only Twitter employee I follow so I tend to think of him the representative, but probably should think of them separately. Aral’s post about the phishing scam points the blame squarely at ‘Twitter’, but only in the last paragraph does he say so ‘stop blaming application developers’ – and at that point I realise the devs at Twitter are just trying to do their jobs.

Actually, I’ve just noticed Marshall Kirkpatrick’s article ‘How the OAuth Security Battle Was Won, Open Web Style‘ at ReadWriteWeb, it talks about the down time of OAuth last month. It’s a pretty good read, reporting that the lead developers of the providers were all aware of the vulnerability as it went down, but quickly and effectively worked together to resolve the problem before really going public and risk inviting attacks.

As Marshall says, if OAuth was software, a fix could be implemented and pushed out to everyone who was using it – but it’s not, it’s ‘out in the wild’ and no one party is in charge of it – it’s real victory that they all cooperated so quickly and so well to neutralise the threat.

Then in March, Yahoo! announced their service sign-on, called Yahoo! Updates.

Now, this week, Twitter have announced their connection service, called ‘Sign in with Twitter‘. It too gives you a secure authenticated access to your information and contacts, in exactly the same way the others do – except this time, it’s Twitter.

You might ask if we have three, do we need a fourth? Have you ever used any of the other three?

But don’t dismiss it, or think it Twitter are jumping on to any kind of bandwagon, Twitter’s implementation is fundamentally different to the others – and it could cause quite a stir.

The problem with the other services (ultimately the problem with the platforms) is, more than often not, they are completely closed and non-portable. Although you can sign-in to a third-party site and access your data, there’s a lot of limitation to what you can retrieve and publish. These popular social networks have grown and amassed huge amounts of members and data which they horde and keep to themselves. I’m not talking about privacy, I’m referring to data portability.

The infrastructures are like locked-in silos of information and each built differently, because, either, they never considered that you’d want to make your data portable or they didn’t then want (or see value) in you moving your data anywhere else. The services they’ve created to ‘connect’ to your data are also proprietary methods – custom built to channel in and out of those silos. Each of those services too, are singularities, they won’t work with each other.

Twitter though, have come up with a solution that adheres to agreed upon standards, specifically, by using OAuth to facilitate it’s connection. Technically, it’s significantly different, but in practice, you can expect it to do everything the others can do.

The community’s thoughts

Yahoo’s Eran Hammer-Lahav (a frequent contributor to OAuth) has written a good post discussing his thoughts, he says it’s ‘Open done right’ – no proprietary ‘special sauce’ clouds interoperability as happens with Facebook Connect. I think he’s right.

He looks at what happened when Facebook Connect was introduced, that they essentially offered third-party sites two key features: the ability to use existing Facebook accounts for their own needs, and access Facebook social data to enhance the site. The value of Facebook Connect is to save sites the need to build their own social layer. Twitter though, is not about yet another layer, but doing more with that you’ve already got.

Marshall Kirkpatrick also wrote about the announcement, his metaphor for the other ‘connection’ services best describes how they function – ‘it’s letting sites borrow the data – not setting data free’.

But then he talks about Twitter ‘as a platform’, and I think this is where things get interesting. He says:

Twitter is a fundamentally different beast.

All social networking services these days want to be “a platform” – but it’s really true for Twitter. From desktop apps to social connection analysis programs, to services that will Twitter through your account when a baby monitoring garment feels a kick in utero – there’s countless technologies being built on top of Twitter.”

He’s right. Twitter apps do pretty much anything and everything you can think of on top of Twitter, not just the primary use of sending and receiving tweets. I love all the OAuth and open standards adoption – but that’s because I’m a developer, but thinking about Twitter as a platform makes me wonder what kind of effect this will have on the users, how it could effect the climate, even landcape, of social media if, already being great, Twitter is given some real power. 

People have long questioned Twitter’s future – it’s business model, how it can be monetised, those things are important – but where can it otherwise go and how can it expand? Does it need to ‘expand’? It’s service is great it doesn’t need to start spouting needless extras and I don’t think it will. But in widening it’s connectivity, it’s adaptability, I think could change our perception of Twitter – it’s longevity and road map, the way we use it and think of ourselves using it.

My Thoughts

Irrelevant of Richard Madeley or Oprah Winfrey’s evangelism, Twitter is an undeniable success.

When Facebook reworked and redesigned their feed and messaging model, I almost couldn’t believe it. What was the ‘status’ updates, basically IS Twitter now, and that’s it’s backbone. It’s Twitter’s messaging model, it asks ‘What’s on your mind?’.

I’m probably not the only one who thought this, I’d guess any complaints about this being a bit of a blatant rip-off were bogged down by all the negativity about the interface redesign.

I think Facebook realised that Twitter has become a real rival. I think (and I guess Facebook also think) that as people become more web-savvy and literate to these sociable websites, they want to cleanse.

The great appeal of Twitter for me was, ingeniously, they took a tiny part of Facebook (this is how I saw it two years ago anyway) and made it their complete function – simple, short updates. Snippets of personal insight or creative wisdom, it didn’t matter really, what was important was it ignored the fuss and noise of whatever else Facebook had flying around it’s own ecology (and this was before Facebook applications came around) and took a bold single straight route through the middle of it.

Looking back, a lot of Facebook’s early adoption could be attributed to people growing restless with the noise and fuss of MySpace at the time – Facebook then was a clean and more structured an option.

I remember Twitter was almost ridiculed for basing it’s whole premise on such a minute part of Facebook’s huge machine. Now look at the turnaround.

Now people are growing up out of Web 2.0 craze. A lot went on, there was a lot of ‘buzz’, but a lot of progress was made in connecting things. People now are far more connected, but perhaps they’re over-connected, struggling from what Joseph Smarr calls ‘social media fatigue’. People they have multiple accounts in a ton of dispersed and unconnected sites around the web – true, each unique and successful for it’s own achievements – but it can’t go on.

Twitter for me is streamlined, cleansed, publishing. Whether talking about what I’m doing or finding out information from people or about topics that I follow, the 140 character limit constrains these utterances to be concise and straight-to-the-point pieces of information. The ‘@’ replies and hashtags are brilliant mechanisms conceived to create connections between people and objects where there is almost no space to do so.

I use my blog to write longer discourse, I use my Twitter to link to it. Likewise with the music I listen to, I can tweet Spotify URIs. I link to Last.fm events and anything particularly good I’ve found (and probably bookmarked with Delicious) I’ll tweet that out too.

Twitter for me is like a central nervous system for my online activities. I won’t say ‘backbone’ – because it’s not that heavy. Specifically a nervous system in the way it intricately connects my online life, spindling and extending out links, almost to itself be like a lifestream in micro.

Recently, I saw Dave Winer‘s ‘Continuous Bootstrap‘ which although is admittedly a bit of fun, describes the succession of platforms deemed social media ‘leaders’ (see the full post here).

What I initially noticed is that he aligns successful platforms – blogging, podcasting – with a single application: Twitter. It doesn’t matter whether he is actually suggesting that Twitter alone is as successful as any single publishing form, but it did make me wonder if Twitter, rather than being the current ‘holder of the baton’, will actually be the spawn for whatever kind of Web-wide platform does become popular next.

If the real Data Portability revolution is going to kick in, if it’s on the cusp of starting right now and everything will truly become networked and connected – would you rather it was your Twitter connections and voice that formed that basis for you or your Facebook profile?

I know I’d much rather read explore the connections I’ve made through Twitter. The kind of information I’d get back from the type of people who’d connect in this way would be far more relevant from my pool of Twitter connections rather than the old school friends and family members (notoriously) who’ve added me on Facebook, the kind that just add you for the sake of it.

If Web 3.0 (or whatever you want to call it) is coming soon, I’d rather detox. Twitter is slimmer and still feels fresh to start it out with. For me, Facebook feels far too heavy now, out of date and messy. Maybe I’m being unfair and I feel that way because I’ve fallen out of touch with it and now I visit less frequently, but all the negativity hasn’t done it any favours – and those complaints aren’t unfounded.

But if these platforms are successful, what will that actually be like? The demo sites Google provides are good for functional demonstrations but little else. There’s a complete list of sites that use Facebook Connect up on their dev wiki – there’s Joost, Netvibes and TechCrunch, but no-one with such a diverse and active user base like Twitter.

Then on Monday came on the news that Twitter chose to Connect with Google’s service. It’s strange that there wasn’t more made of the announcement, considering what could come of it.

Twitter hardly said much about it at all on their blog, Google covered it in more depth but also provided the first real recognisable use case for an integrated site. Now whenever you join a ‘Friend Connected’ site, you can use your Twitter profile to join their service. From there, you can see of a combination of your followers and those who you follow that are already on the site and connect with them there too. You can tweet about your find from the connected website’s portal.

Getting a big site like Twitter on board will really kick Friend Connect up a gear, undoubtedly it’ll receive a massive increase in attention. But it’s not like Facebook Connect is by any means down or out – it’s so early. If anything, the introduction of these services to such widely used web apps as an almost unblinkingly ‘standard’ feature (this will eventually boil down to a simple ‘Connect’ button) could positively change users’ perceptions of them to being just commonplace. I’m sure that’s the ultimate intention, but right now it’ll work in favour for any such service, be it Facebook Connect or any other.

It’ll be a while before we see any real difference in the reception or growth of implementation for either service, whether by then we have a preferred leader or not.

I’m interested to see how Facebook will respond in aiming to get as big a site as Twitter integrated with Connect. Prior to the Twitter inclusion, I felt that Google’s Friend Connect came across almost like a developer’s toolkit – like a set of ready-made widgets to enhance onto your site, boosted by the capability to network centrally. But now I’ve seen it in action, Facebook have a undeniable rival product.

It should be said of course that Twitter hasn’t really chosen Google over Facebook. Biz Stone wrote that there was hardly any effort required on Twitter’s part - Google maybe just got in there first.

It’s in the same post he goes on to say that Facebook Connect integration is already in development. Twitter officially announced integration with MySpace and the Data Availability initiative seven months ago – they’re embracing everything they can, good on ‘em.

In my last post I wrote about my disappointment with Twitter’s cancellation of outgoing SMS updates. I received a comment from my brother, raising an interesting question:

Some good points, bro.

What I can’t understand is why the major networks haven’t started a joint initiative that allows broadcast conversations like Twitter had over SMS. Users could send broadcast texts for the price of a single text (given that it must cost the network the tiniest fraction of 10p to send a message) to a group of up to their friends. I reckon it’d be a good way to increase SMS usage.

I suppose the reason they haven’t is that all of this will be changing over the next few years as people email better integrated into their phones. With the mobile phone networks just be happy to take money for data usage instead of SMS.

I must say I agree, the migration of voice calls to VoIP too, is as (if not more) inevitable in the long run as mobile phones become even more seamlessly integrated as ubiquitous computers.

But a ReadWriteWeb article today about the launch of another new ‘pay-to-tweet’ service from 3jam, suggests possibly the best solution to fill the Twitter SMS-void, they believe, because they already offer a service that does almost exactly that.

‘Supertext’ is group text messaging from the web on an credited account basis. But as Sarah Perez points out, 3jam already operate on a large scale and with huge volumes of SMS, so surely they should be in a great place to to negotiate a good, i.e. cheap, deal.

Could it be so ‘good’ that it’s worth paying for a previously free service? Maybe. As she asks, is there enough worldwide demand for Twitter via SMS for any of these pay-for-Twitter services to make it?

When Twitter introduced a limit of 250 international device updates per month last November, I could deal with it – I myself not afflicted with what Mike Butcher diagnoses as ‘Twitarrhoea’ – and could see the reasoning. Twitter support concedes the issue to expense and cost effectiveness, presumably the volume of international traffic can still be handled stably, I guess they just can’t strike the right deal with UK providers. Michael Arrington reports that cost to be $1,000 per UK user, per year – a staggering figure.

But Butcher also questions two interesting outcomes. Whether:

“UK users may start unsubscribing from people who tweet incessantly.”
“Or they will cut down the number of Twitterers they follow.”

Whilst I find the first almost motivating, that a community moves to prune and better itself, solving to enrich a collective exchange, the latter troubles me – that an established, relied on service (albeit reluctantly) makes changes to their business model, directly effecting, by way of forced change, our social behaviour online – clipping our activity and way of interaction.

I’d be interested to see how, or even whether, the behaviour of Twitter users and usage changes with geo-location. I am part of a community of Twitterers of around 15 who each closely follow and are followed by each other, internally. We’re very aware that we believe our use of Twitter to be quite different from most others – or at least it was in the very beginning when we first joined. For us, far from a micro-blogging platform, it is a mechanism almost purely for group social communication. Although due to our careers, sparks of debate are often tech-centered – it’s by and large far more recreational than at all serious.

I’m not alone in expressing my feelings, and it’s not pretty. Hopefully the effects of this change will be prolonged and result in either a celebrated reversion or at least some kind of solution – like the Facebook group earnestly campaigning to cut Twitter a decent deal, rather than opportunists gaining from the downtime.