28 Dec 2009, 7:40 p.m.

Mobile-Friendly Short URLs with Wag.gd

A few weeks ago I quietly launched Wag.gd, which is what I like to think of as a mobile-friendly URL shortening service. It's "mobile-friendly" in the sense that the URLs which it generates are designed to be exceptionally convenient to type on a standard mobile handset keypad. It's time to introduce the service to the wider world, and look in a bit more depth at what I've tried to achieve with the site and how I've gone about it.

Wag.gd screenshot

Through my work at PlayPhone, I spend a lot of time typing fiddly, lengthy URLs into mobile browsers, quite often via DeviceAnywhere, which complicates things yet further. There are a plethora of URL-shortening services out there, but I've found them to be only marginally more convenient. Sure, the URLs are shorter, but with that shortness comes an increase in the amount of context- or case-switching one has to do to type them in.

So I created Wag.gd, primarily to scratch my own itch, but also with the hope that it might be of some use to others.

Besides being as short as possible, the URLs it generates have a few features which should aid mobile-friendliness:

  • Only the characters in the set {a,d,g,j,m,p,t,w} are used, so no key has to be tapped more than once just to type one letter
  • That also means no context-switching between, upper- and lower-case, or between alphanumeric and symbols, both of which are painful on most handsets
  • URLs work as both <identifier>.wag.gd as well as the more conventional wag.gd/<identifier>, since while typing a dot is usually very easy, typing a slash can be quite cumbersome
  • No tap-and-wait, i.e. no two consecutive characters in the URLs should be on the same key

That final bullet point is actually a little bit of a lie: in order to increase the URL space the site has to work with, in some cases tap-and-wait will occur. However, the URL generation algorithm penalises it, and where it does happen, there should be a pay-off in terms of shorter URL length. I've had to make arbitrary decisions as to how many taps equals a pause; I think it's currently two-to-one.

So all in all, the URLs seem to me to be pretty convenient, and I've at least saved myself some time already.

I've since noticed that a lot of handsets "helpfully" prepopulate browser address boxes with http://www_, meaning that you have to delete the www before typing in a Wag.gd URL, so I might add support for www.<identifier>.wag.gd URLs in due course. Any further suggestions for usability are of course most welcome.

As a final note, I'm not unaware that by adding yet more short URLs to the Internet ecosystem, I'm contributing to one of one of the worst scourges to hit the Web since its creation. That's why I'll return at some point in the new year with some thoughts on the etiquette of using, or not using, short URLs.

Posted by Simon at 01:53:00 PM
29 Dec 2009, 12:52 p.m.

Carl

awesome.

Is there an api endpoint? there are quite a few twitter clients that let you specify custom shorteners. There doesn't appear to be a standard approach but http://developer.atebits.com/twe... describes how tr.im and bit.ly do it.

14 May 2010, 9:17 p.m.

Simon [ADMIN]

Hi Carl -

Apologies for the sluggish response, my thoughts have just returned to this as I've been using Wag.gd a lot myself recently. As, it seems, have others.

There is no API as it stands. I'm not sure there ever will be, as I kind of fear that could lead to indiscriminate, automated use of the service, which I just can't support: I have a limited number of URLs and a limited amount of capacity. The service supports a specific need and I've never suggested it to be appropriate for general purpose URL-shortening.

Plus, in general, people should think hard before they link to a third-party short URL rather than a real one. APIs don't help to remind them of that responsibility.