From: Rohit Khare (Rohit@KnowNow.com)
Date: Sun Jun 04 2000 - 23:16:51 PDT
>>http://www.osopinion.com/Opinions/MikeBanahan/MikeBanahan1.html
Opinion Columns / OS News / Open Forums / CoolSites
Underwhelmed by WAP:
Impressions from the coalface
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 like php3. 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 (see the WAP FAQ for examples). 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:
* The use of interpolated variables in text and URLs. You can
initialise a WML variable with a commonly-used string once then
interpolate it in the body of the document dozens of times - very
handy for standard calls to CGI scripts. If it's long, the long
string only has to be sent to the device once and only counts once
against your byte code restriction. Variables are preserved across
card decks (pages) too.
* Cascading 'option' tags that HTML could usefully do with -
similar to cascading menus on a typical windows/mouse system.
* Input fields with format hints attached that help you to
control what can be typed into them. Most phones make you use the
keypad to enter data; if you can specify alphabetic or numeric input
for a field, the phone can switch keypad modes without the user
having to find the key to press to do that.
Some of the worst bits are:
* A complete imagination failure that restricts the layout
options to such a laughably small set that all but first-generation
devices will rapidly outstrip them. If that doesn't lead to
vendor-specfic incompatible extensions almost overnight, I'll eat my
hat.
* The event model and its strange binding to variable-setting.
* Giving official sanction to monochrome bitmaps instead of
pressing the vendors to support grayscale (at least).
* No support for cookies. This is disastrous. Although you can
simulate the lack of cookies in a single session by generating
session keys and embedding them in your generated WML, they burn
bandwidth, ensure that every page has to be generated dynamically,
are tricky to get right and they aren't persistent. Persistence is
particularly important because it's hard for users to enter
username/password information through restricted phone keyboards; it
means that you can't offer them the option of remaining logged-in by
storing a cookie on their phone. (This is strictly a WAP rather than
a WML deficiency).
* Poor implementation of browsers to the extent of sometimes
crashing the phones and requiring WML authors to test on all known
display devices to have any faith that their pages render 'correctly'.
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.
------------------------------------------------------------------------
Authors background:
------------------------------------------------------------------------
Mike Banahan can be reached for response to this column by e-mailing
him at: mikeb@gbdirect.co.uk
OSO
This archive was generated by hypermail 2b29 : Sun Jun 04 2000 - 23:20:39 PDT