Here are some tips to help you write WAP content. Some of these are quite
general, and some are quite detailed and technical, but I hope you'll find all
of them useful.
- Check your content on different browsers.
Most of the current
WAP browsers suffer from bugs and incompatibilities with the published
specifications. This problem is particularly severe when things
should work according to the specifications but fail mysteriously on a
particular browser. (This situation will get better with time; there is now
an official test suite available and a certification program. But until
both are widely adopted, incompatibility remains a serious problem.) This WAP
browser incompatibility means that, for the time being, you should test your
WAP applications on as many different devices as possible. Don't assume that
some technique you've used will work everywhere just because it works on one
browser. Try it out on different devices, preferably on one from a different
manufacturer.
- Check it on different screens.
Don't write your applications
for one device and assume that everyone else has the same screen size.
There are few things more irritating than having a nice new PDA with a big
screen and having four words of text on each page. On the other hand, be aware
that putting long essays onto WAP sites will cut out the huge
portion of your audience accessing your site via a cell phone.
If you have content that will benefit from a big screen, consider making two
versions of your site: one with lots of small files for cell-phone users
and one with a few big files for PDA users. Things like news stories and
sports reports really benefit from this sort of treatment.
Also, don't rely on a screen's width to be a particular dimension. Some sites
lay out tabulated information by relying on a particular cell phone to
put line breaks in the right places. This type of layout is completely
unreadable on most other cell phones, let alone PDA browsers.
- Provide alternatives to timers.
Many WAP sites use WML's
timer facilities to display logos and splash screens before the main
content loads. Very few sites provide any alternate means of entering the
main page if the timer does not work as expected. If no alternative is
provided, the user will be stranded on a page with no way to go forward or
back. (Unsurprisingly, users find this a frustrating experience.)
The most common reason for a timer to fail is a name attribute on the
timer referencing a variable that isn't initialized properly somewhere else.
This works fine the first time, since the default value is used, but later
visits to the same page will use the value "0" for the timer, which disables
it. To be on the safe side, always provide a <do> or
<a> element to perform the same action as the timer. This also
improves the user's experience, since he or she can skip past the timed page,
if the time-out is long.
- Remember to use entities.
A surprisingly common mistake that
even experienced WAP developers make from time to time is to forget to use
character entities when writing characters like "&" and "<" in normal
text. For example, the string: Tips & Tricks would not be valid if
put directly into a WML page, since "&" starts an entity. Write this example
as: Tips & Tricks. Another reason to test your work across
as many different systems as possible. Some browsers and gateways are very
forgiving about these errors, and you may not notice the error if you test
on only one system.
Also remember that all character entities begin with an ampersand (&) and
end with a semicolon (;). If you leave off the semicolon, your page may work
on some devices but fail inexplicably on others.
- Use images sparingly.
WAP is not the Web. Screen sizes are
small, and download times are long. Use an image only where a few words of
text isn't enough. You can probably fit only one image on-screen
at a time on most cell phones, so the complicated image-based layouts
on so many Web pages are simply impossible on a WAP site. And don't use
images as bullet points or other decorations. Not only does this slow down
page display on most devices, but you cannot rely on the image appearing
where you want it to on some browsers. (See Tip #7 for more on this.)
Don't miss our exclusive O'Reilly interview with
Martin Frost.
- Keep the files small.
With bandwidth so low for most
wireless devices, it is very important to reduce the size of individual
files so that a user won't have to wait too long for any page to load. It
is better to break large pages up into several small ones, with "Next"
and "Previous" links, than to send the whole lot in one go.
While it is difficult to put a strict limit on file size, be aware that some
older cell phones cannot load any single file with a size exceeding 1,400
bytes after processing by the WAP gateway. However, newer WAP browsers can
cope with larger files and eventually everyone will have the newer phones.
The WAP gateway will compress the file, but to be safe with these older
devices, you should keep your text files to around 2,000 bytes, which will
typically compress to about 1,400.
- Don't rely on image alignments.
Many WAP browsers support images
poorly. Even though these browsers will display the images, many choose to
display each image on a line by itself. This means that on certain devices you
can't use images for things like bullet points or for extra text characters.
For example, you might want to include a "TM" symbol on a trademarked item
using this WML: <img src="tm.wbmp" align="top"/>. Although
this fragment is correct according to the WML specifications, some devices
will display the image incorrectly by, for example, having the image sit in
its own paragraph in between the two halves of the line of text.
- Check user input with WMLScript.
Judicious use of WMLScript
to check values entered by a user can make a huge difference in how that user
experiences your site. Given how slow wireless connections are, an extra
trip to the server and back can become frustrating, especially when the
response a user gets is something like "You have only entered five digits in
your passcode; it should be six." Use WMLScript to check this sort of thing,
and to display an error message locally to the device. This avoids the extra
network trip and improves the user experience.
- Be intelligent, not clever.
One important tip to bear in
mind is that you should avoid doing too many clever things. There are a
huge variety of different browsers out there: even the best ones aren't
perfect, and the bad ones can be really bad. It may be an
interesting technical exercise to use a complex arrangement of timers and
pages to animate images. However, it doesn't impress users when they can't get
through because their phone's user interface has locked up.
Go easy on the browsers: They're new!
