1ft Startup

I’ve been recenly lucky enough to author a rather large WAP system for a news agency. I’ve done my share of mobile development before, but never as a start-to-finish WAP project, and never for the launch of a site that already exists as a success on the standard desktop web, so it’s been a great opportunity to compare the two worlds. Below are some thoughts and observations.

Here’s what to expect from launching a WAP site:

• Far lower traffic than a desktop site. The mobile web still hasn’t caught on anywhere near the web. One business note: If you’re in a company that ties business resources to revenues and customer reach, this can make your life occasionally tricky.
• Far higher CP/M on ads. Ad revenue is extraordinarily high on mobile, orders of magnitude above the web. This is in large part because the click-through rate is also astronomically high. Why? I have a couple guesses:
• People using the mobile web are really just looking for something to distract themselves. While they may be deeply involved in looking for a specific thing or know exactly where they’re already headed on the desktop web, mobile users are more likely to be killing time until their number comes up at the DMV.
• People don’t know how to use their mobile browsers. I honestly suspect that a good amount of ad click-through traffic is a mistake. I think that this holds true for desktop as well as mobile, but it’s certainly easier to get confused on a phone and hit Select instead of Down on a 5-way pad (and the ad is, of course, right on top and already highlighted).
• Users will always make most use of the top portion of your site, and decrease their use linearly farther down the page. This sounds obvious, most well-designed WAP sites really are designed as narrow vertical strips with the important stuff on top — but I was a little struck by just how precisely users followed this rule. We tracked user clicks on our site, and the number of clicks on each link decreased in almost exactly the order in which the links flowed down the page, regardless of the link’s relevancy (I’d like to dream that we ordered everything from most relevant to least, but I know it’s just not quite true).
• When people do search on mobile (rarely), they’re even more often searching for porn. This fact of animal life is certainly true “in real life” on the desktop too, but it seems rather more prominent here. And people do search for a lot of porn. Definitely set up a Google sitemap for your mobile site and keep track of what people are looking for to get to your site. Australian ICT Minister Helen Coonhan recently called the mobile web a “Pipeline for perversion.” That’s probably overboard, but she has one thing right: Mobiles are a more personal device than desktop computers, and people may be prone to do more personal things with them.
• Being “on-portal” is awesome for traffic, but it makes you subject to the carrier’s whims. This sometimes means that you need to put a link back to their portal on the bottom of the page, or make other concessions about naming, and it almost always means no ads. If you are allowed to show ads (or if you can eventually talk them into it), expect the carriers to demand that you share around 45% of the ad revenue with them. Gangsters!
• There are a lot of phones out there, and everyone has one of them. Expect a really, really, really long tail. Out of 1000 hits, maybe 150 will be from the most popular device, 100 from the next one down, and the rest will all be 15-20 hits each all the way to infinity. This means that when you fix that bug that affects a single handset, you’re probably only improving life for a fraction of a percent of your user base. ugh.

If the internet is, as they say, a series of tubes, then a web site is a delicious milkshake. Over the last decade or so, tubes that people suck information through have become big enough that web developers provide thick, cold, jaw-droppingly rich milkshakes by the cowful. Life is great.

Now, trying to view a web page on your phone is like trying to drink a milkshake through a coffee stirrer. It’s very slow, and after a long time you’ll finally get a taste, or you’ll get nothing at all. Most people will give up even before they even find out.

The mobile web today sucks. The technology has been so bad for so long that users have given up on it. And it’s not only end users, but webmasters, and the fancypants design companies that sell web development, who have also seen the state of the industry circa about 2 years ago and thrown in the towel.

The truth of the matter is it doesn’t have to be this way. There’s a bit of self-fulfilling prophecy in here: Webmasters think that mobile sucks, so they don’t try to make it not suck. Users try a page or two, experience the absolute horror of an un-adapted page, and never try again. How can we turn this self-loathing, destructive rut around*?

Companies like Google are trying to proactively correct the negligence of others by rewriting 500k broadband web sites into 2k, mobile-friendly pages on the fly. This is a neat idea but only really a stopgap to try to stop scaring users away from the technology. It’s not a real solution.

The only true way to unstick ourselves and get people onto mobile browsing is for us webmasters to provide a truly mobile-friendly site. More about what makes a good mobile site some other time; The first and most important thing we really must do is detect the nature of the incoming visitors and handle them appropriately. Below is a simple way that you can start building mobile support for your site.

Here’s the technical part: If you’ve got a fairly static site, an easy way to do this is to check the HTTP ‘accept’ header to see if a browser is specifically looking for wap content. If you’re running Apache, you can redirect users to another tree by adding something like this to your httpd.conf:

## Redirect all wap traffic to xhtml subdirectory.
RewriteEngine on
RewriteCond %{HTTP_ACCEPT} application/vnd.wap.
RewriteRule ^/(.*) /xhtml/$1

There are a couple caveats to this approach. First, this doesn’t handle WML-only devices. Second, this does not detect all handsets — some handsets think, foolishly, that they are all-powerful, and ask for “*/*” (every content type). To handle these (relatively few) handsets, you’ll really need to identify their User-Agent headers specifically.

Technically, this is the easiest way I know how to solve most of the problem in one broad stroke. If someone else knows something that would work better, I’d love to hear about it!

You can do this immediately and come back later to improve it — boring > aggravating: Even a static page or five, a placeholder, a cut-down slice of your functionality, to let users know that you haven’t forgotten about them, well, that’s a huge step in the right direction away from crashing every visitor’s phone.

* A brief pause for hypocrisy: theoreticlabs.com (or multitap-friendlier tlbs.us) does not have much available under its mobile site. Stay tuned, this will most certainly change! I’m not just saying that.

Hello,

I’m a terrible blogger. I don’t have very strong opinions, especially about whether I’m right. I don’t have any really truly amazing ideas right now. I misuse parentheses (frequently). My sentences are too short (or too long) and I have as much evocative prose in my whole body as William Faulkner had in his left small toe. And he didn’t even write with his small toes. I’m probably not the right person to be doing this at all, actually.

However, I am keen on sharing some things I’m learning and have learned over the last few years, if mostly as a notekeeping mechanism for myself. I hope they’re useful to someone else, even if they’re just used as strawman examples of ridiculously misassigned conclusions, or as affirmations of the obvious. By the way, dear audience of almost zero — if they are useful or totally wrong, I’d love to hear about it!

So, I’m a programmer. I started writing software when I was about 8 years old, playing with GW-BASIC on an 8088. I moved on eventually to Pascal, then 80×86 Assembly, and that’s where I really fell in love with programming. Assembly is so simple that you could memorize the entire instruction set, the number of bytes each instruction took, how many clock cycles it ran in, everything! Working on a system with very very limited memory and computing power, it’s a goldmine to be armed with this information. The simplicity of the language allowed for a lot of very clever tricks. The best place to see this in action then, and even today, is on the demo scene. Beautiful stuff.

Fast forward to today, and some of us are still thinking about the same confined area. I’m writing software for cell phones — basically the 386s of the present day. Sadly, our circuits aren’t laid as bare as they were in the early 90s: We can’t find clever ways to manipulate the call stack or try guessing commands on undocumented processor ports; we’ve been cornered into layers of abstraction to protect us from a fragmented market — No ASM, but rather tools and sensible APIs like BREW and, even worse, J2ME. Even so, it’s great fun to push the limits of these devices.

Something to consider very soon may be — when phones become sufficiently powerful, where will we go to push the edges of computing? Watches? Computerized earrings? Nanobots?

Anyhow, enough procrastination. Back to work!