All of our recommendations are fairly straightforward. There are no big secrets in WAP design. The problem with WAP is that its inherent limitations mercilessly expose the weaknesses of a badly thought out design or implementation.

There are two types of WAP service: Internal and External. This article relates to both - although internal users of your WAP service will not be paying with their own money for the privilege, they will surely make clear their discontent if the system isn't focused and efficient!

Before you start to build that WAP site or service, ask one question:
"Would someone pay to access this service on a regular basis?"

If the answer is not a resounding "Yes!", then there is a real problem.

Assuming that the service or site passes this "Is it worth it?" test, there are some considerations which should help improve its quality.

If you want to build excellent WAP sites and services there are several areas of consideration. First, there are general design principles which apply in the WAP domain; second, there are WAP-specific problems to be aware of.

1. Before you begin, be very clear what the system is to deliver. Think hard about usability and navigation.

   A complex, muddled Web Site is bad, but how much worse for the WAP user who has a much more restricted view.

2. Keep it simple. There are situations where rich content is good - but that's not WAP. Each time the handset accesses new content, it should be clear and pertinent to the job in hand. Make each access count.

3. Don't try to build a WAP version of your existing Web Site or intranet system. It is very tempting to "translate" existing content - after all, you have already invested lots of effort, so why go through all that again? Well, the answer is that by translating an existing system you will break rule 2 and probably rule 1 also.

   The limited display of a handset implies you cannot rely on the same visual cues which you employ in the existing system. Which throws a greater burden on the navigational aspect of your WAP service, and probably makes the job of navigation harder for the user to comprehend.

   Start from scratch. Focus on the service. Be clear about its boundaries - what it will provide, and what it will not. It's so easy to throw in extras on the Web; avoid this temptation when creating a WAP service.

4. As with traditional HTML browsers, each browser/handset combination has its own idiosyncracies, bugs and "features". Sadly, WAP highlights these - it is very unforgiving, and so it is possible to create perfect WML which simply breaks when accessed by a popular device.

   So, be aware of the issues. Design defensively. By following principle 2, avoiding unnecessary functionality, you should benefit from lower exposure to these problems - another good reason to keep it simple.

1. Web Browsers do not break when you send lots of content to them. WAP microbrowsers do! For example, the Nokia 7110 has a limit of 1397 bytes of (pre-compiled) content which it can receive without error.

   So, each WML deck of cards must be small.

2. As the WAP support for graphics is limited to small, static, monochrome images, do not use a graphic unless the service really benefits from it. Otherwise, you will be wasting time, bandwidth and user patience.

3. You cannot rely on emulators to precisely reflect the behaviour of real handsets, so test the service with as many real handsets as you can acquire.

4. While there is some variation between PC display sizes and resolutions, the difference between - for example - the Nokia 7110 and the Ericsson R380 is dramatic: the latter presents roughly six times more usable display than the former. So, when creating WAP services you must have a clear policy for supporting these diverse clients.

5. Security is more complex. As there is a gateway between the handset and the WAP site, and as the two halves of the chain support different security standards, there is potential exposure here. Understand what type of secure access your gateway provides. Work with it.

We have found the above principles to be both obvious and easy to follow.

WAP services do present challenges. Our preferred approach is to create simple, well-defined services, which only rely on well-supported WML. We store this generic WML along with style information. Output is generated - usually by Java Servlets or JSP - on request. This allows the generator to look up the handset/browser combination in a capabilities database, and, if a match is found, to generate output crafted to that client. In this way, we can handle both the general and the particular, but only by having designed this into the service from the outset.

WAP is not "rocket science". However, creating effective WAP services requires careful planning and design. By generating all content on demand, the system can be made arbitrarily flexible, if so desired.