1ft Startup

If you’re managing a large site, building the WAP version of your site in a completely isolated environment is an appealing idea. It’s a business experiment, it doesn’t impact the daily site or put it at any risk, and it’s a quick way to get it up and running. This worked extremely well when I built the mobile site for a large news agency — News agencies are in the business of syndication, so they make their data extremely accessible. One of their web developers put it: You turn the tap on, and news is supposed to flow out.

So we launched our mobile news site, it was a huge success, and traffic started flowing in. Eventually, though, we started getting a few complaints that went like this: People were emailing articles to each-other from the web, and when they tried to click the link on their BlackBerries, they were redirected to the front page of the mobile site! They’d get a link from their friend, to:

news-site.com/article/25798470

And when they hit the link on their phone, they’d be detected as mobile and redirected to:

mobile.news-site.com

Not good! The same thing was also happening from users’ RSS readers. We did eventually fix this, but we had to set up some crazy redirects to take care of it (and unify some back-end data more tightly, so we could refer to the same article IDs).

The much cleaner approach would have been an integrated one, that (assuming a MVC model) simply displayed a different View while using the same Model/Controller.

A huge part of WAP consulting these days lies around ‘making the mobile version of my site.’ This is a great way to get things going quickly, but please do this with an eye toward eventually providing airtight site integration!

I was sitting in the Mobile Mondays NY meeting last week, listening to the SEO advice from the very level-headed guy at Google, and realized that everyone on stage was preaching what we have been trying to educate people on for years in the industry: WAP is different from the Web. It’s really different. You can’t just point people at your .com site and expect their phones not to crash, you need to accommodate users in ways you never have before. At its easiest, this just means directing them to a watered down site with a few pages of text, but if you’re really serious about it, this means building a fully adaptive site that scales its images, custom-tailors its stylesheets (or lack of), and even completely changes the markup from WML to XHTML-MP to CHTML.

That’s what we’ve been preaching for years, and it’s finally about to become irrelevant.
About a million iPhones are out there around now, and growing fast. Maybe even more Nokia N95s or other extra-smart gadgets are out there. Some of the new phones can’t even read WML, but they all execute Javascript like nobody’s business. They’re normal browsers.. nearly. Over the last week, potentially thousands of users stopped going to the mobile-specific sites and started going directly to their usual desktop web sites. Even more people browsed the web for the first time ever on their phones.

What does this mean for the mobile web as we know it so far? Is it so niche that it’s not even worth looking at, because it’ll be so overtaken by users with smart devices that it will become invisible on the radar?

Probably. The mobile web will never be as complicated as it is today. It’s a patchwork of support, where when you evaluate the characteristics of one device, you add support to about 0.8% of your customers. The mobile web sites have been outsourced to development companies that build a mobile-friendly version of the site, usually completely decoupled from the real site, with its own revenue streams. Soon, all you’ll need is a separate stylesheet, if that.

It’s hard to say it, but we knew the day would come: WAP as we know it has peaked and the days of a totally different mobile site will be on their way to the dustbin.

This doesn’t mean that mobile web development will die, it will just become far simpler. I still don’t believe that a page designed for a 19″ display will ever be desirable on a 3″ display, but that’s easier to fix: Most of the changes will be doable with the same content, with a separate stylesheet (incidentally, why doesn’t the iPhone respond to the ‘handheld’ CSS media type so that you don’t have to do any detection at all?). In the meantime, though, those of us who fought for years to explain the dire difference between the two worlds need to adjust our tunes.

Certain tedious tasks come up all the time that are unique to the mobile dev world. One of those things is digging for information about phone capabilities (screen dimensions, feature support, etc). There are plenty of sites that handle this in some capacity (my favorite is Phonescoop), but as with all sites that aren’t your own, sometimes they just take you 80% of the way there and leave you wishing you had just one more button in just the right place.

I needed something a little more efficient for quick, capability-based lookups, to I threw this tool together:

http://devices.theoreticlabs.com

This is my first Ruby on Rails project (running on mongrel, yeah!) so there’s bound to be some wackness, but it works for ma; actual mileage may vary. It’s built on top of the excellent-for-its-price open source handset capabilities database, WURFL. Enjoy!

I’ve been reading Alex Wipperfurth’s Brand Hijack, a nice little book about the successes and failures of grassroots / user-driven marketing efforts. One brief comment in the first chapter suggests that one of the disappointments of WAP is that it is billed as bringing the Web experience to Mobile. In fact, it’s nothing at all like that, and that’s been the big letdown. I know this point has been rehashed in various ways even in this blog, but this comment struck me.

Can we call WAP the WWW On Your Phone or not?

Surely, the two media have things in common. Technically, they’re based off of the same protocol, and the same hypertext paradigm, with the same core markup capabilities. Both provide an intricate web of information accessible to the user. Mobile browsers even try to render normal web sites.

But there are some important differences: The desktop gives a rich media experience: motion, vector graphics, sound, flash, video, etc. Mobile is largely a simple, restricted browsing experience with maybe a few images; When they try to render those desktop sites, they usually do so in vain. The desktop gives you fast, consistently-connected browsing, but mobile doles out slow, sporadic helpings of bandwidth. The desktop is used in relatively stationary areas, sometimes for long amounts of time. Mobile is what the name implies.

To anyone who has spent ten seconds with a mobile browser, these differences are obvious. The technical intentions are largely the same, but the way people use mobile is totally different. The real question is: are we doing a disservice to WAP by trying to tell people that it’s the same as the desktop Web?

I think so.

To tell users that WAP is the mobile internet is misleading, and sets the whole industry back — users expect to be eating sugar and instead they’re getting salt. Even once networks and browsers improve, the two worlds will never be one. Nor should they be: The interface is different, and the way people want to use them is different.

So why do we keep doing it? Why do we always hurt the ones we love? The problem is a question of what a better metaphor for WAP actually is. If we can’t describe it to a new user in about 5 words, they’re lost. And we just picked up the most technically-direct correlation, which is how we screwed ourselves up in the first place. What is WAP, then? Electronic index cards? A pocket information haiku?

We may well stay stuck here until we can give a simple answer to this most simple question. And like the original web, the answer will inevitably lie in WAP’s emerging applications more than the medium of WAP itself — but that’s a subject for another post.

I had thought that all there was to mobile wallpaper was the most primitive of human instincts: Babes, cars, bling, etc. Well, a company called Mobux is publishing mobile screensavers by Australian artists in a bid to save the soul (or raise the brow) of mobile content. This was picked up by moconews, who points out that “personalization is no longer just for teenagers and early adopters.” As a developer who has been accomplice to the bittersweet loss of pre-teen innocence by way of their cell phones, I’m impressed by this. I’m sure it’s not the first of its kind, and I’m sure that Mobux has more profitable content categories than this project, but it’s always heartwarming to see some of the industry’s content providers cutting out some of the sleaze-factor.

There are two major things that make mobile software development vastly different and more frustrating than development in other industries. These hindrances are holding the whole sector back, and really, it’s in everyone’s best interest to smooth the development path for mobile software, both for WAP and downloadable applications.

Carriers need to learn how to let go.

Remember Prodigy, and the good old days of AOL? The carriers do, and they’re totally in love with the “walled garden” style of trapping a user in their own universe. Carriers still want to control all of the mobile content that the user sees, buys, and uses. This goes both for the mobile web and for downloadble applications. This has a couple effects:

• Users are given limited choices. Obviously. But this means that it’s very hard for the industry to grow organically. You’ll hear over and over again that “nobody knows what works yet” in mobile, and this is largely due to the fact that it’s extremely difficult to get the audience to try new things. What the user sees and gets is dictated from the top down.
• Mobile software companies depend hugely on carrier relationships. The success of your game/application depends a lot less on free market capitalism and how good your product actually is, and much more on how strong your relationships with the big carriers are.

Handsets need to obey standards.

There’s a terrible tension between the need for software and browser compatibility across multiple handsets, and the need for handsets to distinguish themselves from others in the market with wacky features. That’s not to say that Nokia or Motorola should stop making phones with peculiar geometry or features nobody else has, but they need to do so without requiring developers to bend their code to fit into yet another sub-model. A single phone represents a fraction of a percent of a developer’s user base, so maintaining so many SKUs quickly becomes unmaintainable.

Java ME needs to stabilize. Porting games and apps — that is, making a mobile app work across multiple handsets — is an awesomely frustrating chore. There’s a special room in hell where you have to port Java ME apps to support handsets full of undocumented bugs. From this torture has risen a thriving cluster of small startups that specialize in porting, who have knowlege of the handsets’ different capabilities and bugs and retool code that works well for one phone to work against three dozen other phones. Those shops often rely on a third-party database of undocumented phone capabilities, another mini-industry built on the inefficiencies of the mobile space. A big part of the promise of Java is supposed to be that “write once, run anywhere” feel-good feeling, and maybe with the exception of varying graphics sizes for different screen sizes, it should. Full-time porting jobs should not exist! But they do, and they probably will continue to for a few years. It must be said that BREW is much better in this respect; it doesn’t hurt that Qualcomm is the tightly-controlled central source for the firmware.

All of this is sort of a crying shame for a technology that should be so much farther along than it is, but it also presents a neat, obvious opportunity to people willing to move it forward. The silver lining for the United States is that our backwardness and slowness has given us two crystal balls into the future of mobile: The internet, and the rest of the world’s mobile industry. You can guess some things about the future: Walled gardens will give way to third party portals, and as more site come online and cross-connect to each other, search engines will become more useful and the portals will become less so. The greater the connectivity capabilities, the better the apps — and we can watch the huge successes half a world away that will likely be repeated here in two more years. The industry is moving, fast, and everyone (even the carriers, in their own weird way) seem to recognize this situation and are working to move everyone out of the darkness, and soon, this mini-rant will be obsolete.

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.