Lessons on developing for the mobile world

Getting onto the mobile web is easy, right?. It’s just some slimmed down css and html, with a few new rules, such as the need to “think light”. Not quite.
There are issues that need to be addressed at many levels. Let’s consider, for the moment, the tech baseline.

Most phones will probably be only marginally better than:

• Screen size of 240 x 320 pixels, colour
• Clock speed of max 600MHz, but after dealing with the heavy lifting of the radio and signal processing up in the microwave band, there are very few CPU cycles left for rendering web pages. You’d be shocked at how seemingly trivial things like calculating image locations and gradient fills eat up cycles.
• Data rate is likely to be around 10kbps in real life, even if the big red sticker says 900kbps down, and 250 kbps up or some other fanciful claim. While most phones will have EDGE, GPRS, or High Speed Wadda Wadda Plus One at some phenomenal value, don’t forget it is a contended service. 10kbps, however, is fine for most of your mobi needs: this data rate will take one second to refresh your entire screen, pixel by pixel
• The air interface forces latency to around 500ms. This means sending server updates is a bad idea (for example to refresh a drop down) – because it takes a long time.

The implication of the above constraints is that you need to serve your users just the right information. At the very least you must recognise their device through a User Agent string, so that the markup is customised for their phone. Graphics served to the device should already be of the optimal size and format – the phone should not need to scale or throw away data to match the width and length attributes.

There are established rules in this regard: Google them.

Signing In
As important to customising markup for devices, you should also personalise the content for the user. This comes down to requiring your user to sign in. Signing in to your mobile portal can be automatic (through cookies or MSISDN recognition) or through the manual entering of a username and password.

Apart from the vast amount of business intelligence this provides into your user behaviour, it also lets you personalise services. The single biggest advantage? You can give your user exactly what she requires, right there in the very first screen-full.

Remember that small screens mean you mustn’t make them scroll or click around.

Know Your Limits

When it comes to the real world of engineering mobile sites, there are only so many hours in the day, and flawless products are expensive in dev time. So while device recognition (through WURFL, for example) allows you to recognise phones to a high degree of granularity, you should really confine yourself to rendering mark-up to three or four phone classes (“dumb”, “feature” and “smart”) and a few parameters (e.g. data rate, screen size).

While some phones may support wild and wacky mark-up possibilities, do not do it just because you can. Time is money. Debugging takes time. QED.

Screens should be refreshed “one-shot” – e.g. forms should not be populated iteratively with the server, through Ajax/DOM Events. (In fact, just don’t use Ajax, flat xhtml will save you an ocean of tears.)

There are two main lessons in developing a mobile web service that will stand the test of time. First, you really need to think the workflow through on your user’s behalf – how and why they’ll move about, and what information they’ll be wanting first.

Second, the mobile web should use the same data sources as your fixed web services. This means building an enabling platform to let you use the raw data from your backend services, eg XML. This does not mean reformatting HTML on the front end.

Scaleability
The mobile web is all about ease of use, convenience and integration of services. Inevitably, your mobile portal will evolve with a need to provide increasingly interactive and personalised services, so plan for this in advance.

Right now it’s easy – bang up a couple of static pages. But to interact usefully with federated service you’ll need enabling platform technologies, such as Enterprise Service Busses, Message Queues, etc.

This is because the pages you render on the server will need to deal with the vagaries of asynchronous services, or worse, broken or slow synchronous services.

There is nothing worse than a mobile web page that is slow because, during assembly, the system had to wait for the elves in the Facebook service (or whatever) to wake up. The evolution of your portal will be horizontal with the number and diversity of services, as well as vertically with increased numbers of users (well, at least you hope…).

Apart from the need to scale, another fundamental part of your planning should include the inevitability of change – you will have to tweak your existing services according to customer feedback.

Cost
This is critical – the cost of developing the mobile portal becomes prohibitive with complexity. Complexity is manifested through ad-hoc additions to the service’s state. State should be maintained in an atomic way. It is an untenable situation when every new service requires tweaks to all its existing pages and services.

Monetising the mobile portal is going to be the battle-ground. Should you monetise it directly (mobi banner ads? paid subs? affiliate programme?), or is the mobile portal a way to reduce user churn and increasing stickiness (i.e. funded as a marketing/brand cost)?

Either way, you have to assume your mobile portal will need to support back-end services, which means an architecture plan and integration platform.

The mobile web is a fantastic social platform and should be managed as such. View your mobile site as the one-stop shop of your users.

Information on your portal should be dynamically configured, personalised and relevant to the user’s location, time of day and social context.