The Ultimate Mobile Transcoder

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, 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.‘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., and are 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:

You can use:

  • 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 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
  • 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 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 actually suggests that you use the shorthand notation “[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 (or and enter 1ep27”? If I have to explain all that I’d rather just say “”

QpynFor their transcoder, 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, 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.

There’s a similar problem when using a mobile full web browser like Opera Mini which can handle most web sites without the need for a transcoder. The combination of Opera’s transcoding proxy and it’s Java ME client render sites far better than even the best transcoders. When I run Shifd in Opera Mini all my URL’s are transcoded. I tried to work around this issue by using the full version of ShifD in Mini, the page did load but my notes, links and places were missing. ShifD’s elegant web interface uses some complex JavaScript that was apparently too much for Opera to handle. links created with the mobile option also displayed transcoded in Opera Mini. Mowser does provide a link to the original untranscoded content at the bottom of every page but it would be nice not to have to go through the unnecessary page load of transcoded content in the first place.

shifDQpyn 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 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.

3 thoughts on “The Ultimate Mobile Transcoder

  1. Great post !
    yes I agree with that, the transcoder is a real need and at MobiTMS we try to offer it directly in Social Network via applications such as “TMS search” in Facebook

  2. Thanks for the review, Dennis!

    Gotta a lot of great stuff coming soon; looking forward to more coverage! ;)

    One comment: Mark and I were just talking about how we’ve heard that the same common wisdom of smartphones disrupting our services… for jeez, I can’t even remember… since we started in 2001.

    The reality is, our usage map shows these devices have the biggest growth line right now. (Seems to go against conventional wisdom.) However, I think the future for all devices will to have a tri-fold approach to browsing: a robust client browser (BB, Opera, etc), an optimization service (Skweezer), and a back-end server/gateway combination for network optimization (Openwave, FlashNetworks). This will give the user, the publisher, and the network operator the greatest flexibility moving forward.

  3. Hey Dennis,
    Great writeup, and as always, thanks for the support. You’ve pegged exactly one of the discussions that Russ and I have been having:

    “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 or emailing links and clippings to become a power adjunct to the browser.”

    For the way that Mowser (and most other folks) mobilize the logic to figure out if a request is from a mobile or not is separate from the adaption engine that actually spits out that page. This is one of those areas where I wish we could leapfrog a few generations of technology and make the edge devices smarter. If we could just give end users a way to opt into adapting content by default or getting the full version we wouldn’t have to keep making subjective decisions on the server side about what’s a mobile browser and what isn’t, and replicating the same mobile detection logic all over the place.

    There’s got to be a more elegant way to solve the problem of detecting and adapting for lower capability devices. While the iphone has shown what’s possible, reality is there are lots of phones out there already that can’t yet get the full web. If Opera Mini keeps rolling along the way it has been, that might change sooner rather than later. But even at 100k downloads a day, even that could leave a pretty long window open.

Comments are closed.