Social Media

6th August
2010
written by feicipet

I’m a regular Twitter user, albeit a somewhat reluctant one. It’s an excellent way of keeping up with people I’m interested in. Non-geeks find it extremely simple to use and this can be seen in the fact that a growing percentage of political figures in Malaysia are on Twitter, at various activity levels.

The problem I have with Twitter is that it’s just not scalable in some aspects. I find it horrendously difficult to track down a coherent conversation trail between 2 parties. For example, when I see an interesting tweet rebutting someone in rather strong language, the busybodycurious side of me would immediately try to track down what transpired before that tweet. More often than not, this is more of a chore than necessary and I just give up after a couple clicks.

It’s not that Twitter doesn’t have mechanisms to keep a coherent trail of tweets related to each other. When you “reply to” a tweet, be default, Twitter clients are supposed to add metadata stating that this tweet is “in reply to” another one. When viewed using a decent client, the user would be able to select an option to view the whole conversation preceding a particular tweet and find out the history of that tweet.

However, this is poorly implemented in most of the Twitter clients I’ve tried out, and I shall demonstrate how and why. Now, I have not been testing every single Twitter client under the sun, I lack the logistics to accomplish that. My experience in Twitter clients have thus far been restricted to the Twitter website, Chromed Bird, Gwibber and ChoqoK on the desktop. On my Android phone, I’ve tried out Touiteur, Twicca, Tweetcaster, the official Twitter for Android client, Seesmic and Twidroyd.


Replies

One of the worst offenders in breaking the trail of conversation is Twitter itself. Twitter has this funny dogmatic insistence that replies must begin with the handle of the person that you’re replying to. On the Twitter website, if you click on “Reply” to a person’s tweet, you will be shown a form with the person’s handle pre-populated. Just append your reply in the form and your tweet will be shown as a reply to the original tweet. However, if you remove the handle or type anything in front of the handle, your tweet will be shown as a fresh new tweet. Why? The mind boggles. However I modify the contents of my tweet, I am still replying to it. That’s the context of my tweet. The form should not affect that. Other Twitter clients, such as Chromed Bird and Touiteur, are more tolerant of this. I can modify my tweet as I wish and the “reply to” metadata will still be submitted to Twitter’s servers as I wished it to. This is one of the reasons why I avoid using official Twitter clients as much as possible.


Retweets

Retweeting is another aspect of Twitter that bugs me. For those who do not know, there are 2 styles of retweets in existence: the old and the new. The old style of retweeting consisted of quoting the entire original tweet prepended with the characters “RT”. Some time last year, Twitter rolled out their new retweet feature, where a retweet is simply the original tweet forwarded to your followers with your metadata attached (“retweeted by XXX”).

There was some amount of debate regarding which style is better but Twitter is sticking to their guns so far. A fair number of Twitter users still prefer the old style, mostly because they like the option of being able to add on their own comments to the tweet. As such, old style RTs are still available in nearly all Twitter clients save the official ones issued by Twitter.

However, as far as I know, not one single client appends “reply to” metadata when executing an old style retweet. “Why is this needed?”, you may ask. Well, in the scenario where users add on their comments to the retweet, it may breach the 140 character limit, thus forcing some creative editing to abbreviate the original tweet. Sometimes, the edit results in a severely mangled version of it such that the original meaning may be lost even. When this happens, it would be useful to be able refer back to the original tweet in a convenient fashion. Having the “reply to” metadata attached to the retweet will help a lot in this case. It just helps users form that coherent trail of tweets right back to the source. I firmly believe a large percentage of flame wars on Twitter occur due to people jumping into a debate and interpreting tweets out of context simply because they found it too difficult to read the entire conversation preceding it.

Right now, I’m still a reluctant Twitter user. I would much prefer to use Google Buzz, which is much more conducive for discussions, but the reality is that most of the people I want to follow use Twitter, and as such, I must too. I just wish Twitter and its clients would do more to help us make sense of whatever we’re reading.

5th August
2010
written by feicipet

What’s the most interesting aspect of reading a blog post or news article? Sure, the article itself may be interesting, but if you’re anything like me, the comments section is where the action’s at. Feedback, comments, corrections, outright flames and the wars that follow it; these are the things that make the “social” in social media.

Recognizing the fact, startups all over have been setup to facilitate these discussions. Reddit and Digg are examples of websites that focus only on facilitating discussion of online articles. Disqus attempts to be an outsourced discussion engine designed to host the discussions while alleviating the need for the original website to do so. While not specifically targeted towards this end Google Buzz is another avenue for surfers to share an interesting URL with their friends and start a discussion around the article.

And there lies the problem: discussions are scattered throughout the web. Most of the time, it’s probable that the original authors of the article don’t even know such discussion exists. I, for one, am not too keen on running around trying to track down all the discussions circling what I’ve wrote. Alright, let me correct that. I’m very interested in reading the discussion, I’m just not too keen on the running around bit. It gets old, after a while.

It would be very convenient if there’s a way to aggregate these discussions together into one place, for example the URL where the article was originally posted. Technically, it seems possible. I think it’s already established that the most suitable format for pushing threads of information is via content syndication feeds. RSS or Atom feeds, to be specific. I know that Google uses Atom feeds in their Buzz API, where 3rd party applications can use the API to interact with the Buzz engine and content contained within. So, in theory, if parties such as Buzz, Digg and Reddit play nice, a blog may be able to pull in a feed of discussion from each of these sites, merge them and sort them in order to present an aggregated feed of all the discussion that has taken place on the article.

How does the blog know if discussions have been happening on other site, though? If the blog owner is required to manually hunt down these discussions, it would still be a time-consuming task. TrackBack is a framework that allows source blogs to be informed when another blog mentions one of the articles in the source blog. If we can piggyback on the TrackBack specification to add on metadata that gives enough information on how to pull the discussion feed, that would effectively automate the whole discovery process of discussions.

Obviously, this suggestion may be counter-productive to Reddit and Digg, which relies on eyeballs on their own site to monetize their efforts. However, they have to remember that they do not have original source content. They rely on 3rd party content to generate the eyeballs on their own sites. I think it’s fair enough that they allow some reciprocal exchange of data in exchange for the content that owners contribute.