Fourteen columns ago in CFDJ (Vol. 1, issue 6) I wrote about wireless computing having finally come of age, the importance of WAP, and that ColdFusion developers could leverage this new and exciting technology quickly and easily.

During that time WAP has become quite the buzzword. Developers seem to love it, industry pundits love to hate it, and all the while more and more WAP devices and content are becoming available. According to Pinpoint.com there were less than 1,000 publicly available WAP pages at the end of 1999 and over 2,000,000 by June 2000 (a growth curve that even dwarfs the Web's). And based on current trends, IDC is predicting that by mid-2002 more users will be accessing Internet services using wireless devices than traditional wired connections (this is already the case in Japan).

What all this means is: like it or not, WAP is here to stay. With WAP 2 on the horizon (a more complete specification that adopts XHTML instead of the more "proprietary" WML), WAP creates interesting new possibilities and opportunities for developers willing to give it a try.

In this month's column I'd like to revisit WAP, but not from a beginner's perspective (for that, refer to my aforementioned column). Rather (based on the questions I get asked most frequently), I'd like to take a big step back and look at some overall design and development considerations - things to keep in mind when looking at WAP.

The "Killer App" that Isn't
I often get asked, "What is the killer app that will make WAP successful?" Others get asked this too, and I have to disagree with almost every response I've seen thus far.

There is no killer WAP app - the platform and devices are not designed for applications, never mind killer ones. If users wanted to run apps, they'd use browsers or more traditional clients. WAP is used because it allows instant access to small, bite-sized chunks of highly relevant information. The relationship of WAP to the Web is similar to the one between pagers and cell phones. Your phone is used for full-blown conversations, while pagers are used for small bursts of immediately needed information. Even though most phones nowadays are pagers too, the analogy still works - one does much less but is well suited for short bursts of information; the other does much more but has more overhead. The same is true for WAP and the Web.

The "killer app" is actually not an app at all - it's data, any data that's time-sensitive. Examples are:

• Flight time and gate changes (I rely on this one extensively)
• Stock price alerts (notification and perhaps even the ability to take action)
• Phone number lookups (with the ability to dial the found number)
• Maps and directions

Incidentally, many columnists (including some very respected ones) have denounced WAP with a "who would want to surf the Web on a device with a postage stamp-sized screen" argument. And they're right, who would? The problem is, they're totally missing the point here - the fact that they're thinking about surfing the Web means they've completely misunderstood the use of this technology. They're right, no one should be surfing the Web on a WAP device, but for instant access to the data you need when you need it, WAP makes all the sense in the world.

Forget Pretty, Make It Functional
Have you ever compared today's Web sites with those of a few years ago? There's no comparison. Simple text and graphics with basic formatting have given way to sophisticated (and often heavy) user interfaces that closely resemble complete multimedia applications more than anything else. Users' expectations have changed, and sites have to look good to attract an audience. So developers go to great lengths to ensure that content looks perfect on all browsers and on as many platforms as possible. Nowadays functionality isn't enough on the Web; it needs to look good too.

This is proving to be one of the most difficult transitions for Web developers looking at WAP - in the WAP world functionality is not the primary objective, it's the only real objective. Making screens look pretty is pointless for a whole slew of reasons:

• Device capabilities differ so dramatically that even basic text formatting doesn't work consistently across them all.
• Screen size is usually very limited. If you had standard logos, headers, footers, and formatting, there wouldn't be any space for content.
• Connection speeds are slow, and you can't afford to multiply the amount of data to be downloaded just to make things look nicer.
• Most important, users don't want pretty screens, they want content - plain and simple. If they wanted a fun surfing experience, they'd be using a Web browser. As explained above, WAP (and other wireless technologies too for that matter) is used primarily for instant access to relevant information, and that's it.

Keep Bandwidth in Mind
This brings us to connection speeds - although I'd rarely use the word "speed" in conjunction with WAP. Not only is connection speed limited, the packet size is too (and terribly inconsistent from one device to the next). Phone.com browsers support between 1,492 to 2,000 bytes per packet, some Nokia devices support smaller packets, and some Ericsson devices support larger packets. In addition, network latency rears its ugly head even at packets of this size, so as a rule packet size should be kept at around 500 bytes (not very large at all).

Before you go off to check file sizes, it gets a little more complex. Data is compiled when sent to the device (instead of as raw text), and the packet size you need to watch is the compiled packet size (which can be bigger or smaller than the raw text size). You usually don't have to compile data yourself (the WAP gateway does that); however, even though you're delivering raw (uncompiled) text, you should still know the number of bytes it'll compile to. Most development SDKs (like Phone.com's UP.SDK and Nokia's SDK) feature mechanisms that determine compiled content size. These options should be used.

Another important note is that every effort should be made to fill packets - it takes just as long to send a packet that's half full as it does to send a packet in which every byte is used. When planning your design pay attention to this - perhaps you could send multiple cards (a deck) instead of a single card so the next request won't need a round-trip to the server, or perhaps you could afford to provide more information within a card (preventing the need for another request) if space permits.

Bandwidth concerns will go away eventually, but you can't afford to wait until then. If you're serious about WAP development, you need to worry about this right now. Emulators - Love Them and Hate Them

I've mentioned that the SDK is available from Phone.com and Nokia. These SDKs include device emulators - software programs that let you simulate a device's operation on your computer. Emulators are important, and you must use them. Actually, I'd go as far as to say that you must use them all, or at least the major ones:

• Phone.com
• Nokia
• Ericsson
• Motorola

But don't rely on emulators - ever. They're called emulators for a reason - they're not real devices, they just emulate (pretend to be) them. Emulators can give you a good idea as to how your code will behave (and the better emulators actually run the same software that's running on the device being emulated), but there's no substitute for real-world testing. In an ideal world you wouldn't need emulators at all, but this is not an ideal world. Developers don't have access to all major devices. Some devices operate only in specific parts of this planet, and the exact same device can function differently based on the provider using it. So emulators are needed, but they must be viewed for what they are - emulators. Before you deploy your app you must test it on real devices, as many as you can. You should even try to find users with other devices and enlist them in the testing, even users in other countries. This should be obvious, but I'll say it anyway - the more you test, the better.

Rethink User Interfaces
No pointing device, no keyboard, limited graphics support, no DHTML, limited client-side scripting, no colors, no CSS, no frames or layers, no sophisticated form controls, limited text and font control - the list goes on and on. Effective WAP user-interface design is a challenge, one that re-quires us to rethink user interaction.

Here are some points to consider:

• Don't publish too much content, as most of it won't be readable anyway. The key is to be focused: a focused array of options and focused content within each.
• Use menus for everything since selecting options is very easy on most devices, but don't overuse them. If users have to drill down through umpteen levels of menus, they won't use your app.
• Frequently used menu options should always be listed first.
• The less data entry, the better. Some newer devices are simplifying data entry (with different input types, T9, and other technologies) but even so, data entry is a painful experience at best.
• Wizard-style interfaces work really well, but try to keep as many cards as possible in a single deck so as to prevent lots of round-trips to the server in the middle of a data-entry sequence.
• Request data intelligently. For example, if you need a U.S. city, state, and zip, just ask for zip and work the rest out yourself.
• Make user-provided data persist. Any time you can remember data so users don't have to retype it, the better.
• Always provide a backward navigation option, and not necessarily to the previous card. Allow users to easily get "back" to strategic locations within your application.
• Resist the urge to keep shouting out your company name, logo, and more. Nothing annoys WAP users more than having to scroll down to see content because a company name and logo took up all the visible screen space.
• Creating device-specific content (based on detected capabilities) is extremely complex and highly error-prone. It's great if you can do it, but only do it if you're going to invest significant time and re-sources in the effort (and testing). If you can't make that investment, don't do it at all and just stick to basic (common) functionality.

Writing for HTML and WAP
I know I'm going to get in trouble for this one (I've already received hate mail for saying this in my book, WAP Development with WML and WMLScript), but here goes - don't even bother porting existing HTML applications to WAP, and for that matter, don't try writing code that supports both.

As explained above, WAP sites and Web sites have different goals. If you're trying to port an HTML app to WAP, I suspect you're not creating a WAP site that will truly deliver what WAP users want. What makes a good Web site is not what makes a good WAP site, and the reverse is true too. The goals are different, the user experience is different, the navigation is different - there's usually more that's different than the same.

Even if the HTML and WAP sites were so similar that you could use XML and XSL to render the content in different ways, chances are it still won't work properly. For example, a single HTML page doesn't map to a single WAP card - sometimes a single HTML page needs to be multiple cards, other times many HTML pages need to be a single deck of cards. Trying to render content for both platforms at once usually means that you deliver content for neither effectively.

If you're serious about WAP (and I believe you should be), you need to take a big step back when thinking through your wireless application. If you can reuse existing code or content, great; if not, don't try and force it anyway. It just won't work.

Having said that, I do believe content can (and should) be reused. If you've created your Web application correctly, separating content from presentation and business logic, you'll likely find that content (and perhaps even business logic) can be reused. (Incidentally, this is why Spectra is so well suited for HTML+WAP development). If you're developing code from scratch, you should definitely tier your code this way in order to reuse as much of your investment as possible.

Summary
WAP is an exciting technology, and one that has great potential - if used properly and where appropriate. If you put the effort into designing your applications correctly, getting to WAP can be quite painless (and fun) too.