A bunch of new mobile web related services have got me thinking about mobile transcoders and how web services can enhance the mobile experience. The new services are ShifD, Qpyn, Tapp.it and esyURL all of which combine a web to mobile transcoding proxy with some other service; content synchronization in the case of ShifD, URL shortening for the others.
Tinyurl.com's free URL shortening service has been around since 2002 but has recently gained new popularity thanks to Twitter and the 160 character limit of SMS. The problem comes when the recipient of a Twit on a dumb phone tries to open a URL, tiny or not. In many cases the link will open a full web site causing the browser to error out, lockup or display something unusable.
esyUrl.com, Qpyn.com and Tapp.it are tinyurl.com clones which optionally invoke a transcoder to mobilize their targets. All three services work more or less the same way. You go to a PC web site and enter a long url that you want shortened. So if you have a long url that want to share like this one to a New York Times story: www.nytimes.com/2008/02/27/business/27leonhardt.html?_r=1&hp&oref=slogin
You can use:
- Tapp.it where you specify if you want your short URL to point directly to a site or to a mobile transcoded version. That's OK if you're sending the link to a phone, which Tapp.it facilitates with a Send To Phone option, but not so good for sharing the link on Twitter where you have no idea what kind of browser will be used to open it. The Tappit short URL for the Times story is tapp.it/dpajpmpj
- esyURL which creates a single link that goes to a landing page where the user gets the choice of visiting the original link target or a mobile transcoded version. The Times URL becomes esyurl.com/5wr using esyURL.
- Qpyn goes a step further and uses browser detection to automatically invoke the transcoder only if a mobile browser is detected. The Qpyn shortened URL to the Times aricle is qpyn.com/go/?1ep27. Qpyn actually suggests that you use the shorthand notation "qpyn.com[1ep27]" or "Q[1ep27]" when sharing links rather than the full URL. I can't see anyone doing that unless Qpyn becomes as well known as Twitter itself. Who would have any idea that "Q[1ep27]" means "Go to qpyn.com (or qpyn.mobi) and enter 1ep27"? If I have to explain all that I'd rather just say "http://qpyn.com/go/?1ep27"
For their transcoder, Tapp.it and esyURL use Mowser, probably the best current transcoder. Qpyn uses a white label transcoder which seems pretty good too, at least it meets my basic test of transcoder quality - it splits long pages and resizes images.
ShifD, which was developed at a Yahoo Hack Day, by a couple of the New York Times' web developers, syncs notes, bookmarks and locations between all your PCs and phones. You key or paste text, addresses or URLs into a web, desktop, mobile web or SMS interface. ShifD stores your data on the web and makes it instantly and simultaneously available everywhere. Notes and addresses are just text and display as is on both web and mobile. The mobile version of Shifd opens URLs with Mowser. There's a lot more to the ShifD story which has it's been extensively covered on the web already. See: Engadget, Beet.TV, Russell Beattie for more on ShifD
All four services work more or less as advertised but playing with them got me to thinking about what they and the underlying transcoders did right and how they could be improved. Take the case of a URL which already delivers mobile content and works fine on my handset. I don't really want it transcoded which would degrade and possibly break the mobile site. But that's actually what happens with Qpyn, links to mobile sites are transcoded. In my limited testing with a few sites none of them broke but most were less attractive than they were in their original format. ShifD, Tapp.it and esyURL are using Mowser as their transcoder and one of the great things about Mowser is that it detects when a site is sending mobile content and passes it through untranscoded - very cool. Google's GWT transcoder does the same thing but other transcoders including Skweezer and Novarra do not.
Qpyn seemed to do the right thing, it detected Opera Mini as a web browser and linked to non-transcoded content. I though that was pretty good except that Qpyn also decided that my Motorola i855's Openwave browser could handle non-transcoded content, causing the browser to hang trying to load the full version of the NYT story. Qpyn did send trandscoded content to the Obigo browser on a Sanyo A920, so it does work, but the Qpyn browser detection code seems to needs a little tweaking if it thinks Openwave V7 is a full-web browser!
esyURL avoids the issue by asking the user whether they want the site transcoded or not. A simple and effective solution but a little too manual to be optimal.
What I'd like to see is a service that negotiates between browser capabilities and web page size and complexity to only transcode when it's really needed. A universal content negotiation and optimization service. Ideally the negotiation could be build into the transcoder. Just as Mowser recognizes and doesn't transcode mobile content, my ultimate transcoder would also recognize that the requesting browser doesn't need it's services and gracefully step out of the way. The ultimate transcoding engine could be enhanced with other services like bookmarking, posting to Digg and del.icio.us or emailing links and clippings to become a power adjunct to the browser.
Transcoders have a bad reputation in mobile web development circles thanks to the abusive practices of so called "carrier grade" products like Novarra, Openwave's Open Web and Bytemobile which transcode all content, including mobile web sites, and break content delivery services by stripping the user-agent and other headers. But opt-in transcoders like Mowser, Google GWT and Skweezer serve the useful purpose of making almost all of the web available on the brain-dead built-in browsers still found on the majority of phones. I hear a lot of sentiment that the need for transcoding will go away soon as the iPhone effect forces carriers and manufactures to include full web browsers with all phones to compete with Apple. I agree in principle but don't see the transition being complete in the US and Europe for another 4 or 5 years. Even Opera Mini, which is a great full web browser, can't be installed on the majority of US phones either, because like all Verizon and Alltel feature phones, they don't support Java, or are crippled to block or degrade Opera like T-Mobile US and ATT branded phones. In the developing world where very basic and second hand phones are the norm, the need for transcoders will last a lot longer.