One of the things that bothers me about Twitter is the endless wrapping of links in tweets in their own url shortener. Many people will say there is the benefit of making sure only “safe” links are enabled, but mostly it is a data gathering activity. Sadly, even t.co links get wrapped in new t.co links which makes the whole thing a bit silly. However, the problem is not that links get wrapped and shortened, even as annoying as it is, the problem is that it is needed at all.
MG Siegler had a short post about a week ago regarding the issue with link shortening. In that post, he highlights a tweet from Sean Parker:
The need for link shortening is idiotic,@jack — links should be meta-data attachments to each tweet, not part of 140 char limit
Yep, another person bitching about links and the 140 character limit. However, this is Sean Parker who should be listened to, and his point is quite valid. A few days ago, Colin Walker talked about the problem, and reminded us of annotations:
We were granted a quick peek at the potential for client app developers to add metadata via “Twannotations” but then it all went quiet, why? We have the staple of location data attached to tweets but this seems to be about as far as Twitter has gone.
Functionality has instead been included via the website (auto-detecting certain image and video services to include items in the media pane)…
Why has some functionality been built into the website and not the metadata in the API? Much of what Twitter does seems to be constrained by the 140 character limit and their integration with SMS. That was interesting in the early days when smartphones and tablets barely existed. SMS was the main way to integrate with mobile phones. Now, we have various native apps for phones and tablets.
But the main tweet function has not changed. We never saw the implementation of annotations, but the API has a lot of information available. Why not break from the SMS origin and start providing a different interface for different devices? Oh, wait, they already have different clients for the different platforms and devices. So, why not split the functionality instead of going with the lowest common denominator?
Think of the differences that Twitter already provides. The iPhone has a different interface than the website. The iPad looks different than either of those interfaces, and Android phones are yet another interface. There is also a mobile optimized website if you are not using a native app. Lastly, there are the API calls that many third party developers use. Those APIs have a ton of information attached to a single tweet, not just the 140 character message.
So, why not make an official break from the SMS roots and start adding metadata to tweets. Otherwise, they are just restricting themselves unnecessarily. I understand that part of the power of Twitter is in its minimalism, but they refuse to grow the product because of those original constraints. I am not talking about changing the length of a tweet or even changing the ability to post from SMS. I am only talking about making media and links metadata or attachments to a tweet, just like they exist in the APIs. My concern is that they are not allowing themselves to grow due to some old implementation hassles.
What if they followed the same tenets as many other web applications and started deprecating old technology, lik IE6? Everyone applauded the move by various sites because trying to have a site look and act OK in IE6 was almost as difficult as re-implementing the entire site. So is it time for Twitter to cut the SMS cord?
The argument is going to go on and on – on the one hand we have the obvious benefits of advancing the site in accordance with the available technology but then we have the desire to not alienate those in the developing world where smartphones are not prevalent or restrict those who have gotten used to specific ways of working.
When Dick Costolo is saying that Twitter want to unify the experience it does make you wonder if they will be aiming for the lowest common denominator or if they will be using a core experience and then tailoring additional functionality to the method of access employed.
LikeLike
My thinking was that SMS is a very limited platform, so you can provide a subset of functionality there. Obviously SMS will miss the metadata, but that is no reason to not provide it in other places. Costolo has to focus on revenue, but it just feels like they are limiting themselves by not moving forward. And where are the annotations???
LikeLike
Not sure what the structure of data fields in Twitter’s API would look like if URLs were to be moved out of the 140 character field. With L.L SLDs becoming popular (as IDNs) on top of the existing shift to LL/NN SLDs, the maximum number of new data fields needed to accommodate links would not be insignificant even if total field length was capped at an equivalent of 140 characters.
Please correct me if I’m wrong, but it seems as if there is more of a revenue driver behind the current arrangement than a legacy technical issue. Twitter is now in a position to monetize analytics, which it could not do if it shed its wrapper system.
The debate over lengthening OMB text fields was drifting towards a breach in the 140 limit under some ‘all in’ dent expansion. The question was settled somewhat in the direction of what is proposed above, with an ‘attachment’ allowed to supplement each dent. Broader federation issues aside, have you noticed any disruptions in Twitter as a result of those changes?
A rough guess would be that conversions (as CTRs) would be higher under Twitter’s existing system than what we’re seeing in OMBs, and that link utilization in Twitter would also be greater — thanks both to the automated nature of the shorter and cultural factors that eschew shortening in denting. In summary, the experience for users and revenue for Twitter is higher under the existing arrangement than it would be under the revisions proposed above.
LikeLike
While I started by complaining about url wrapping, I can understand the reasoning beyond spam control. I am a big fan of the analytics you can gather, and the added value that can come from the knowledge gained from those analytics.
I can understand the revenue argument up to a point. If you are focused solely on the advertising revenue (promoted accounts/tweets/trends included), then I would agree that there is no benefit to changing what exists. But what if you wanted to look outside of advertising for revenue? Subscriptions to a “pro” account where you can see all of the metadata like urls, media location and other things would be interesting, but that is not possible right now. I have not done market research so I cannot be sure what revenue opportunities they could be missing.
LikeLike
I was at a Twitter Developer Teatime event in London last week and I asked them what happened to annotations.
Their answer was that last summer, when they were working towards annotations, they had to divert resources to deal with the load from the World Cup, and it never found it’s way back onto the priority list. It is something they would still like to do, but it’s not on the current roadmap.
LikeLike
Part of me is concerned by this, it was a high priority at one time and now it can’t get onto the priority list. I understand the drive towards stability and revenue, but it makes you wonder what goes on in those offices and what they are working on that we don’t know about.
LikeLike
[…] Twitter Should Cut The SMS Cord […]
LikeLike