Impressions of Using WAP/WML

Underwhelmed by WAP — Impressions from the coalface

By Mike Banahan

Some weeks ago I wrote a short item outlining how we had taken Somewherenear, a dynamic website and put a WML front-end on to it relatively quickly through the happy combination of an appropriate architecture and handy tools. Several people got in touch with me after than and shared notes on their and my experiences of getting to grips with WAP and WML. Interestingly there was a common thread that emerged from most of the discussions and it had a distinctly different tone from the publicity machine's attempt to convince us that we will all be `surfing the web' from our mobile phones with ease and grace. This is ever the case nowadays — the admen and the press seem to grow in collusion - and the experience of discovering the gritty reality is often a shock. Having been through it now, and feeling moved to put pen to paper, here's an attempt to put things in perspective. This isn't an in-depth and reflective study, it's a first-impressions reaction.

Not only have very few people had the chance to experience the rich and glorious (sorry, we Brits tend to use sarcasm with regrettable ease) offering that the current crop of WAP-enabled mobile phones provide, there seems also to be a lot of misunderstanding about how it all works at a technical level. Though I don't plan to go into detail since you can read all the specs at Wapforum, I'll start with a brief technical overview. After that I'll touch on what it's been like to start developing and using WAP/WML trying to avoid sounding scornful and giving a warts-and-all description of what I and some of my correspondents have concluded. It's not all bad, but there are some hilarious bits in amongst it that are likely to move you to tears or laughter, depending on how important it is to you to deliver this stuff to the end-users.

The Basics of WAP and WML

Ordinary websites are well-understood technology. You pick a web server like Apache, run it on top of your chosen operating system, put together a set of HTML pages using any one of dozens of development methods and then connect the whole lot to the internet. The users of your web pages point their browser at your web server and will see more or less what your designers intended, even if your attempts at HTML have wandered well away from the formal specification for the language. Modern browsers are very forgiving about making sense of even badly deviant pages, as you can tell by picking almost any web site, saving away a few of its pages and then testing them with a tool like Weblint or Validator.

WAP (wireless access protocol) and WML (wireless markup language) are a different matter and it helps to know what those differences are. As appears inevitably to be the case, most people get the fine distinctions confused, so they will say `WAP' when they strictly mean WML, but I'll try to be more specific.

The WAP Forum is an industry consortium who decided that ordinary HTML was inappropriate for the mobile phone industry, so instead of adopting a well-tried-and-tested technology they chose a new one all of their own. Anyone who has been around the software industry for long will immediately feel the hairs on the back of their neck rise when they hear that, and with good reason as we'll see later. The WAP forum produced a whole new set of networking protocols (WAP) and web page language (WML). You can have some sympathy with their motives: bandwidth is very scarce at this level, security is crucial in broadcast networks and the display devices (the phones) are constrained in memory and processing power. That said, our industry is littered with half-baked solutions started for all the right excuses and the conclusion amongst myself and my correspondents is that WAP/WML got pushed into the oven well before the dough was fully risen.

The WAP device doesn't talk to a standard web server, but to a WAP gateway instead. The gateways are similar to proxy servers and your phone will be configured to use a particular gateway no matter which WAP site you are accessing. There will probably be an option to choose a different gateway somewhere in the phone's options. A number of public gateways are springing up for those who don't want to talk to their phone company's version, so you could set yours to one of them. There has been talk in the industry about whether or not the phone companies will operate closed gateways, where you can't access WML sites apart from an approved list, but the availability of alternatives is likely to make it hard for the phone companies to do that for long. The phone companies in the UK seem to have gone for an open-doors policy from the beginning.

The WAP gateway does a number of important jobs. Some are all about network management and phone control that really don't affect the WML site designer, so we can ignore them here. The crucial bit is that the gateway allows you to request WML pages from a WML site: it fetches those pages using standard HTTP/Web requests. If you know how to write WML and can configure your web server to serve them up with the right MIME type, users of open gateways will be able to see them simply by requesting your URL. Slapping together a few basic WML pages and getting them onto the screen of a WAP phone is little harder than writing your first HTML pages.

HOWEVER — and it'a big however - your phone is not talking the normal HTTP protocol to the remote web server; it is talking WAP to the intermediate gateway. The gateway fetches the WML page from the remote server and then converts it into WML bytecode - a compiled data stream - which is what the phone actually receives. This stage is wholly different from the usual web approach where the browser gets the HTML page and then displays it on the screen. The WAP phone doesn't have a clue what to do with WML and never sees any, it gets the compiled byte stream instead. This has an advantage: the compiled stream is significantly smaller than raw WML and since the gateway contains a WML compiler the phone needn't deal with malformed content, which presumably makes the browser less complex.

The sad or funny bit, depending on your viewpoint, is that the gateway really is a compiler. If you miss a comma or a semicolon, or even forget to put quotes around an element's attributes, then your WML is erroneous. Presumably the gateway prints a suitable `syntax error at line 11' message on its console when this happens, but since HTTP is a one-way protocol there is no way that your web server can tell this and you won't get any feedback if you've got it wrong. On the Nokia 7110 that I use all that I see is `Page cannot be displayed'. Believe me, these gateways are strict. You can use XML validators to check your WML in advance since WML is a derivative of XML, but that's less helpful if you generate pages on the fly from a database.

Even if you can get your page past the compiler, the bit that will really bring tears to your eyes is the page length limit. Each device has its own limit — not on the size of the WML page, that would be too easy - but instead on the compiled byte stream!!! Don't expect to get more than about 1400 bytes of compiled data to work reliably. Seriously, this is in the formal specs. That invaluable resource, The WAP FAQ says that the Nokia 7110 limits a deck to 1397 compiled bytes.

WML

WML itself is a curious mixture of good and original stuff. I'd like to take a cheap jibe and quote Dr. Johnson: "the bits that are original are not good and the bits that are good are not original", but it's not quite as simple as that. Having had only a month or so part-time to consider it, I'm not going to pretend expertise on every aspect of WML, but this writeup isn't intended to be the result of deep reflection: it's an impression of what it's like to start using WAP/WML.

I've spent almost 25 years in the software industry and worked with dozens of languages, reaching expert level in a few. During that time you develop an instinctive feel for languages and I tend to trust my gut feel most of the time. The initial reaction to WML was pretty mixed and it hasn't improved. There are a few nice touches in it but overall it has a feel reminiscent of a bright student's project that didn't get properly finished.

WML is terribly limited in what it will display on the screen, with an extremely restricted set of markup tags supported and a curious `deck of cards' metaphor where each page is considered to consist of a `deck' — individually displayable sub-pages within the whole page itself. The usefulness of the deck/card division is unclear in the tutorials that I have seen so far and I haven't discovered a compelling argument for it yet.

There is a brand-new image format introduced, the monochrome-only WBMP (wireless bitmap) image, which few existing software packages support.

Since there is most unlikely to be a mouse attached to your phone, the point-and-click model can't be guaranteed (or so the WML team appear to think) and WML introduces the concept of events, and the tasks that can be bound to events. The rationale for this is that users might want to use voice control or other types of `input' other than pressing a button. I have tried to fathom WML's implementation of the event/task model, but so far without much success. The evidence would seem to be that I'm not alone and I'm still waiting to meet someone who does claim to grasp it. The tutorials I've read so far seem to suffer from the same problem, so I conclude that the majority of WML developers are going to find this a tricky one.

Some of the good bits are:

Some of the worst bits are:

A final curiosity is that despite using the excuse of of limited memory and processing power in the phones to explain away a deficient markup language, the whole of ECMA script (Javascript to you and me) is then bolted in, plus a phone-specific library binding to telephony functions. This is not bad, it's just strange. Bear in mind that you have so few bytes to play with in the transfer length limit that you will have to be a remarkable Javascript programmer to make much use of this. Time will tell whether or not the WAP phone vendors can get their act together and make Javascript/WMLScript work better than the mess that we had with HTML browsers.

The Phones

Have you tried a WAP phone? The experience is not a pleasant one. There is a general consensus that within months all but the cheapest new handsets will support WAP, so before long most users will have had a chance to play with one. It's intensely frustrating to anyone who is used to `real' internet. The sad part is that such a low denominator was chosen by the WAP forum.

As soon as people start to experience mobile data, my bet is that they will insist on something better. The excuses about lack of memory and processing power in the phones just won't stand up: consumer pressure will be irresistible. Either the phones will rapidly bloat up into full-powered HTML browsers with much bigger screens or the vendors will have to respond by extending WML into something less deficient and then there is a real risk of fragmenting the standard.

The phone vendors really haven't figured out what to do about inputting events. This means that as the page developer you have very little idea what your customers are going to experience. Having tried the phone.com simulator, the Slob Trot simulator and a real Nokia 7110 I've been frustrated to the point of head-shaking and shouting at the screen whilst trying to build pages that work acceptably on all of them. And then a stupid and annoying surprises, like finding out that sending a `location' header doesn't work according to the HTTP specification (it seems that relative URLs won't work; they have to absolute, including the server name). Evidence continues to accumulate that the various browsers manage to misconform to the standard in irritating ways.

Best of all? Now you would think that since these devices are phones for the most part, handling telephone numbers would be really well thought out. And if you read the draft specs, there is a special `wtai:' URL scheme which allows you to write a link that will cause the phone to dial a number. Pretty fundamental, after all. So what do Nokia do in the 7110? Ignore it. Instead you have to hunt amongst the selectable options for the `use number' option. This searches the current page for something that appears to resemble a phone number and then lets you dial it — but if (for example) the phone number is preceded by a street address with a number in it, you get that instead. It takes real imagination to come up with something as daft as that and I've got a mind to create a very special award for the bright spark who thought of it. As a word of warning: don't buy a Nokia phone until they sort out the dial-link problem. They have a limited excuse in that the specifications for dial links is only in a proposed rather than accepted state, but I still want to know what they were smoking when they came up with the `use number' idea.

Overall

Mobile data is a compelling concept. The idea of being cut free from wires and being able to access information in various shapes and forms is hugely attractive. Being able to make use of the mobile phone companys' billing systems to allow for online purchasing is an awesome opportunity. There can be hardly any doubt that somehow, somewhere, somebody will figure out how to do it right, but on the evidence to date, WAP/WML is not the answer. Let's hope that after this poor start the industry will get its act together better and start thinking from the consumers' point of view, not its own.

To do it right means doing much better than the current crop of phones, coming up with a better language than WML (which aims much too low) and paying a lot more attention to the difficulties of delivering content. The ludicrous maximum transfer limit has to go immediately — and I don't want to hear whining about how it's hard for the networks to do that, those people are paid to solve network problems.

I'd like to hear what other people's experiences have been and if I get enough useful responses, I'll try to summarise them in a later version of this note. There is a lot of uncritical promotional material about, but I haven't seen much that describes what it's really like to use WAP/WML and those of us who have to work with it deserve some honest and down-to-earth information too.

Mike Banahan, 27th May 2000

Links

Additions/Errata/Comments/Whatever

Since publishing this item, several people have been moved to write back, some agreeing with much of what I've said, others taking issue (in some cases vigorously). Factual information points are mentioned below, along with attributions, though I don't vouch either way for their correctness.

I'll add other items as I receive them.