It has been an interesting few days, since I posted A Modest Proposal For More Microstructure: Twitter /Locations, in which I presented the idea of a new sort of syntax for Twitter (or microsyntax) to represent location. Instead of tweeting this
Just landed at SFO headed downtown ASAP
tweeple could instead post this
Just landed at /SFO headed downtown ASAP
The idea being to have a human- and machine-readable to indicate location. Longer locations involving multiple words would be set off with trailing '/' as well:
Working at /156 South Park, San Francisco CA/ this morning
This proposal has led to a great deal of feedback, ranging from 'Cool, let's build an app to try this out' to 'You've gotta be kidding' and everything in between.
Perhaps the most organized arguments against the 'geoslash' idea (as Ross Mayfield and the WhereCamp folks are now calling it) are those offered by Ralf Rottman, whose post is entitled No additional Twitter meta tags, please!, which gives you a pretty good feel for his position on the subject.
Rottman uses the term 'meta tag' to represent what I am calling microsyntax (formerly I called it microstructure, but that is a bit less specific). Meta tags in HTML are various sorts of information buried in specific HTML elements, and these are intended to be machine readable, and not generally to be inspected by people. My goal with /location is to insert a small bit of punctuation in the tweet, which is human readable as well as machine readable.
His primary argument against microsyntax is clutter, which, he says, is already causing readability issues with usernames, shortened URLs and hashtags that are already in wide use. My answer to that is that people are trying to make Twitter workable, and these conventions have arisen to serve a need. Despite what the Sunday supplements are saying, most Twitter messages are not 'just ate a pickle', but are more likely to be something like '@ross Check this out, and get back to me http://bit.ly/vv1zC #passwords'. People are getting things done, not contemplating their navels, and if that means slightly greater complexity and lumpiness in the twitter stream, so be it.
The rest of his argument is really a tirade against the Twitter architecture. He wants metadata pulled out of the text of Twitter messages and supported in an invisible exterior way by a new Twitter plumbing:
But there is another not so philosophical reason why we should not go further with any of these suggestions: Fundamentally hashtags, @usernames and Stowe’s newly suggested location tags are merely workarounds for limitations of Twitter’s API.
Twitter essentially provides a real-time messaging infrastructure. Not more and not less. Twitter’s attempts to provide additional added value beyond being a free large-scale message pipe have yet to prove successful. The IT folks at Twitter already seem to experience severe technical challenges when it comes to implementing higher value features like conversational tooling and openly admit that it’s getting more and more difficult to address these advanced needs given the large scale user base Twitter has grown to.
Concepts like location, language, keywords and identity are obvious candidates when thinking about messaging and communication in general. It is somewhat astonishing that the Twitter API does not yet provide any good means for third parties to leverage these aspects. Instead we have to use hashtags to mark keywords, might use slashes to tag location and maybe sooner or later somebody will suggest using curly braces to mark products and brands.
As Steve Jobs uses to say: There must be a better solution.
One alternative could be to wait for the folks at Twitter to enhance their API. Developers of Twitter clients could then access a tweet’s meta properties like language, keywords, location, brand and other structured information simply by parsing the JSON or XML returned by calls to Twitter’s REST interfaces. For various reasons I’d not put my money into this one. As Twitter Co-founder Biz Stone stated earlier this week, one way of turning Twitter into a profitable business could be to provide richer tooling.
Combine this with the fact that it will never be in Twitter’s best interest to become a truly open social platform (”open” as described here by Chris Messina) I would rather expext them to make it even more difficult for third parties to easily enhance Twitter based services. Their stupid 100 requests per hour limit is a clear expression of how they plan to keep in charge (though they might continue to claim that technical scalability reasons force them to keep it up).
I suggest that Ralf take these recommendation up with the nice folks at Twitter. In the mean time, bitheads like me will continue to offer up ways to encode intention or meaning into the twitter stream, for any number of reasons. In the case of /location, my goal was simply to make it easy for a relatively dumb Twitter appliance to keep track of users'' locations over time, based on the Twitter that exists today.
Other feedback:
Ross Mayfield and some folks at the WhereCamp this last weekend are working on an app to parse /location from tweets. More to follow on that front. I know there are other developments going on in that direction, too.
Recent Comments