UPDATE 2013: Problem (mostly) solved today. Multiple rounds of shortening still tend to garble the original url address.
In software development you’ll – unfortunately – sooner or later end up having to compromise between usability and functionality. These compromises are often a result of either financial, time or technological constraints. However, the wonderful thing with software is that you can always improve, add and modify after the fact.
Services like jaiku and twitter enables you to let the world know every novel, quaint or painfully inane activity that you are up to at any time, through almost every thinkable mode of communication, save semaphores and smoke signals. One mode being sending and receiving updates per SMS via your mobile phone. A standard SMS text message is limited to 160 characters. As twitter and Jaiku also supports the sending and receiving updates via SMS, they have implemented the limitation set by this lowest common denominator. For instance twitter even keeps 20 characters for itself and you get to play with a remaining 140 characters per update.
I’ll leave it to others to ponder the consequences on the language and communication – if any. I wanted to bring the attention to a usability issue brought about by this technological constraint, not start a discussion about the evolution or devolution of language and communication, although interesting in itself.
To be able to post links (URLs) to pages on the Internet in their updates on twitter and Jaiku, people are using additional services like urlTea and tinyurl to help reduce the numbers of characters to transmit the address, but leaving it functional. Those services take a potentially long address like ‘https://www.cia.gov/library/publications/the-world-factbook/ index.html’ and truncate it to ‘http://tinyurl.com/2b2kg9’, leaving more characters to write a personal message to go with the link with. However, any identity or clue as to where that address may lead has now been removed. (Not to mention the additional burden the use of those additional services places on the poor user. I’ll leave that discussion for later posts.)
I’ve illustrated how this looks when using the web interface of twitter below:
Notice that there are no clues in that address as to what to expect when you click on it. The clever twitterer might suggest that if you’ve been following Chris Pirillo for a little while you’d expect the link to be leading to one of his web casts on his site, but then again there is no information in that address to tell you at a glance what to expect. You can’t know if it’s linking to the story you already read two weeks ago, if it’s self promotion if it’s linking to a site you know and trust – it could even link to an address that would get you in trouble at work.
Enter ‘The Gulf of Evaluation’:
“Does the system provide a physical representation that can be directly perceived and that is directly interpretable in terms of the intention and expectations of the person?The Gulf of Evaluation reflects the amount of effort that the person must exert to interpret the physical state of the system and to determine how well the expectations and intentions have been met. The gulf is small when the system provides information its state in a form that is easy to get, is easy to interpret, and matches the way the person thinks about the system.” – Donald Norman in ‘The Design of Everyday Things‘, Doubleday 1990.
I’ll argue that the gulf of evaluation is light years wide in the case in question. I’d like to have some transparency please. Show me a proper address!
Of course it could be argued that some users of the mentioned services would actually support the extra layer of obscurity afforded by the use of nameless addresses – that it actually generates more traffic from people clicking blindly than it would if people could see the real address and source. I do not have a firm opinion about that, however.
There are of course ways to alleviate for this unfortunate loss of information, letting us know where we’re going before wasting our time or getting fired (if using Jaiku and/or twitter hasn’t already gotten you fired) by clicking on the wrong links anywhere but the SMS’. I’ll propose two modes of improvement. One involves internal changes to the services themselves, and the other external additions with no need for involvement from the Jaiku or twitter development team. They both have advantages and disadvantages.
I’ll start with the blatantly obvious one; Jaiku and twitter should look up the truncated addresses before they are rendered and parse them. That is to say a truncated address would be shown in full when using all web based interfaces. Why on earth should we be limited and constrained to the lowest common denominator on the web? We can have gazillions of characters! Heck, keep the limit to 140 characters displayed on the web , just like the current solution, but show those URLs in full in addition to those 140 characters. However this would require the time and attention from the official development teams that are probably already preoccupied with other challenges, fixes and policies.
The second and almost as obvious one would be to develop a plug in for e.g. Firefox that would identify addresses from services like tinyurl and urlTEA, look them up and show the complete address in the status bar below left and as a tool tip when hovering with the pointer over the link. I’ve illustrated how this may look below:
The two immediate advantages of this solution would be that it require no commitment from an internal development team and that it would work with any web page, not only with the content coming out from twitter or Jaiku.
Here’s a another perspective on URL shortenings from Jeff Atwood of codinghorror.com