 | Level: Introductory James Lewin (jim@lewingroup.com), President, The Lewin Group
01 May 2001 Jump-start your understanding of wireless applications -- one of the hottest areas of activity for Web developers. This article looks at key issues surrounding WAP (Wireless Application Protocol) that are of significant interest to developers of wireless applications. The obvious issues are immediately apparent, such as the adaptation of the user interface to devices with limited capabilities, small screens, and difficult data entry. Other less obvious, but equally important, considerations include identifying appropriate applications, dealing with encryption issues, managing sessions, and the intelligent use of cache.
The real status of the wireless Internet is blurred by the hype from vendors on one side, and the negative reactions of critics on the other. When I first became interested in developing applications for wireless devices, I was eager to find out as much as I could. Most of the articles, though, were either the vendor hype or the panned technology reviews I just mentioned, or basic introductions to formatting text for wireless
devices. What I was reallylooking for was something that explained the real
issues involved in wireless Web development with WAP -- something that
would bring my understanding up to speed. This article is intended to do
just that for you. It looks at some of the issues surrounding the WAP controversy
and how they affect Web developers, and introduces concepts important to
WAP development. Also, it looks at the obstacles that you are likely
to face as a wireless developer, and provides suggestions for tackling
these problems.
Don't believe the hype
Hype about the wireless Internet seems to be everywhere today, in ads
coming from cell phone vendors and wireless carriers, and in gee whiz type
articles. An example of the hype is demonstrated by vendors who portray
WAP and the current devices as "the wireless Web." Five minutes with any
of the current wireless devices makes it clear that they offer nothing
like the rich experience of the Web. Yet most advertising portrays today's
technologies as an anytime, anywhere Web. On the other hand, industry critics are panning WAP and the wireless
Internet. One important critique has come from usability guru Jakob Nielsen.
His analysis of the WAP user experience in Great Britain was very critical,
and has been picked up by the popular press (see Resources).
ZDNet went so far as to declare that "WAP is Crap"(see Resources).
Finally, it's been widely reported that in Europe,
where WAP is further along than in the rest of the world, users are either
not interested or are unimpressed with the current offerings. Reading any
of these reports, it would be easy to get the impression that WAP is a
flop. |
Why is WAP important?
- It's designed to make the most out of current wireless technologies.
- It's rapidly being put to work by hundreds of companies that want to be
on the leading edge of the transformation to ubiquitous Internet access.
- Now is the time to determine what works for your company and what will
meet the needs of your customers.
- It ain't perfect, but it can get the job done!
|
|
The WAP reality
The reality is somewhere in between the hype and its backlash. Forward-thinking
companies and developers will want to look seriously at WAP and the wireless
Internet. Here are the facts:
- The Internet freed up users so that they could access information on servers
anywhere in the world. The mobile Internet promises to free up the client,
so users can be anywhere in the world and access anything on the Internet.
- Most criticisms of WAP are really criticisms of current devices. Options
for devices are rapidly expanding.
- Current devices are hard to use, although they are quickly getting better.
- Predictions of billions of wireless devices have to be tempered by the
fact that only a paltry number of consumers are willing to pay for the
limited capabilities of current wireless services.
-
Network speeds are slow and coverage is spotty. Major cities have coverage,
though, and we can expect steady incremental improvements.
WAP for developers
Before converting applications to WAP or creating new ones, consider
whether they are suitable:
- Will the application meet the needs of your clients? Customers are most
likely to use wireless Internet devices when they are not near the richer
and faster Internet experience their work or home computer offers. They'll
be using the devices when at lunch, in transit, away from home, and shopping.
- Does the application meet internal needs? Internal apps may be some of
the most successful projects, because you have control over the access
device. WAP can give mobile employees access to company applications without
the need to stop and hook up a laptop. In many cases it may make sense
to give employees WAP devices instead of a PC. The device employees use
to enter and access information on your network is now small enough to be worn.
- Are there new types of applications that WAP makes possible? Peer-to-peer
and entertainment applications may end up being very important because
of the times and places consumers will use them.
Characteristics of good WAP applications
Follow these guidelines for creating WAP applications:
- Apps should be fast or fun. Most users will be paying by the minute, so
applications need to make it easy to get in and get out. If they aren't
fast, they need to be an entertaining way to pass the time, or users won't
pay.
- Apps should provide limited choices because of the limitations of the devices.
Likely choices should be anticipated and placed in a prominent position.
- Apps should have highly limited data entry. Data entry on most devices
is extremely cumbersome. Users may check mortgage rates by phone, but they
aren't going to apply for one there.
- Apps should be action-oriented, or provide information that is very timely.
Most users won't pay to read marketing materials, advertising, or even
reference materials. They will pay to get timely information that is important
to them, whether it be financial, sports scores, or access to their email
and calendar. They will also pay for the freedom to take action from wherever
they want to.
- Apps should be easy to use. If it isn't easier than making a phone call,
why bother?
Finally, if your apps are consumer applications, they should be "hot." There
will probably be a lot of other companies competing for your clients' business,
so your apps should be as cool as they can be!
Figure 1. WAP vs. Web
The WAP environment
It's important for wireless developers to have a good, basic understanding
of the elements of WAP. Developers will be most interested in the Wireless
Application Environment, including WML (Wireless Markup Language), WML
Script, and WTA (Wireless Telephone Application). Developers are shielded from having to deal with the lower layers of app development by
the existence of the WAP gateway. The gateway translates client requests
from wireless carrier protocols into standard Web ones. WML is sometimes described as the WAP equivalent of HTML. While it does
define the presentation of WAP applications, it also adds important elements
that are foreign to HTML and many Web designers. These include variables,
states, and events. It also provides methods of streamlining data entry
not found in HTML. WML is an XML-based language. It uses the metaphor of a deck of cards
as its model for presenting information. This allows one WML deck (file)
to have several cards (pages) within it. This works great on small screens,
because one download can contain multiple application screens. Here is an example of a simple WML document and a comparable HTML page:
Listing 1. WML vs. HTML
| WML | HTML |
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="card" title="Card 1">
<p>
Hello World!
</p>
</card>
</wml>
|
<html>
<head>
<title>Page 1</title>
</head>
<body>
<p>
Hello World!
</p>
</body>
</html>
|
Formatting text with WML is one of the easiest things about WAP to learn,
but also one of the most trivial. There are many good primers on formatting
WML text (see Resources). In addition to WML, you should be aware of WML Script and WTA. WML Script
is a scripting language that serves the same purpose that JavaScript does
for Web browsers. There are two important things to know about WML script:
- It is different from JavaScript in that it defines native routines that
are burned into the device's memory. This eliminates the need to download
commonly used routines.
- It is of minimal use at this time, unfortunately, because very few devices
currently have any support for it. If you are developing wireless Intranet
applications and have control over client devices, WML Script may be a
useful tool.
Finally, the Wireless Telephony Application Interface (WTA) provides an application
framework for telephony services. WTA will enable Web applications to have
links that initiate phone calls, for example. WTA is also of little use,
at this time, because most available devices don't support it. Because you can't rely on WML Script or WTA to be available, you'll
spend most of your time dealing with WML. Pay special attention to features
that are not found in HTML. These include variables, states, events, and
data entry masking.
The gateway
Figure 2. Gateway example
Required infrastructure changes
Because the gateway handles the job of giving devices access to the
Internet, you will require very few changes to your infrastructure. Your
existing servers can easily handle WML. You'll want to create a domain name for wireless devices that will minimize
data entry. Some suggestions are:
- wap.yourdomain.com
- mweb.yourdomain.com -- for mobile Web site
- wml.yourdomain.com -- for WML-specific site
As another option, you can direct wireless devices to your root domain,
yourdomain.com. You can then have a script redirect the client to content
appropriate for their browser. You can do this by evaluating their HTTP_ACCEPT
or their HTTP_USER_AGENT. I wouldn't recommend doing this
on your main (www) site, simply because it would add the extra overhead
of the redirect to all your Web clients. You will need to configure your server to support the MIME types associated
with WAP. MIME types that you may need to add to your server's configuration
are shown in the table below:
| File Extension | MIME Type | | .wml | text/vnd.wap.wml | | .wmlc | application/vnd.wap.wmlc | | .wmls | text/vnd.wap.wmlscript | | .wmlsc | application/vnd.wap.wmlscriptc | | .wbmp | image/vnd.wap.wbmp |
On Apache, you can add MIME types to the httpd.conf file easily. Look
for the AddType section, and add the settings listed below:
AddType text/vnd.wap.wml .wml
AddType image/vnd.wap.wbmp .wbmp
AddType application/vnd.wap.wmlc .wmlc
AddType text/vnd.wap.wmlscript .wmls
AddType application/vnd.wap.wmlscriptc .wmlsc
|
The remainder of this paper covers architectures for WAP, and finding
solutions to problems that you are likely to encounter in developing WAP
applications. Architectures to consider
You may want to re-evaluate your application architecture to make sure
that it is the best possible match for your needs. Wireless Internet may
create the need to serve similar data in multiple presentation formats.
There are three main approaches: use your existing infrastructure, use
XML to separate applications from presentation technology, or use a transcoder
to intelligently handle this process.
Figure 3. Using existing architecture
Here are the pros and cons of this approach:
Pros
- Existing applications can be modified so that they display a subset of
the standard Web information, but in WML format.
- New applications optimized for wireless can be created that access existing
information, using existing software and application environments.
- This can be done quickly, with no new technology.
Cons
- Applications must be modified to create WML instead of HTML.
- It does not provide a centralized solution.
- Developers have to handle all the processes associated with recognizing
the browser and providing suitable content.
- It may be more difficult to customize content for specific devices.
Figure 4. Using XML to separate presentation from the application
 This appears the same from the user's perspective. The Web server, though,
gets content from an application server in XML. The Web server can then
transform the XML into WML or HTML, depending on the client.
Pros
- This is an appealing architecture because it provides clear separation
of the presentation format from the application logic.
- Uses popular open standards to allow transformation from an XML format
to a presentation customized for each supported device.
- For repetitive content, this may provide a great way to transform it into
multiple formats.
- Separating the application logic from the presentation formatting allows
presentation changes to be made more easily.
Cons
- Requires a larger investment in infrastructure.
- The extra steps required can create additional points of failure.
- The conceptual elegance of using XML may not be so great in practice. Good
WML presentation is not a subset of HTML presentation. This may create
a situation where the XML file is used to store multiple sets of different
content, or where very complex XSL transformations are required. Optimizing
the presentation for wireless may require working with WML features that
have no HTML equivalent.
- Developing the presentation layer requires working with three technologies
-- XML, XSL and WML -- instead of just working with WML.
- Many devices have very limited memory, and XSL has no facilities for adjusting
the size of a transformation based on the size of the result.
- Requires developer to learn new infrastructure and handle ongoing issues
associated with working with new devices.
- Good WML applications may blur the line between presentation and application
even more than HTML applications have.
Figure 5. Using transcoding to create the wireless presentation
Pros
- Transcoders can intelligently transform the content for each device. For
example, graphics can be converted automatically to B&W format for
cell phones, but color for Pocket PC devices.
- Purchasing a packaged solution allows developers to rely on the transcoder
for many steps they would otherwise have to program, such as client recognition
and device-related logic.
- May be a good solution for larger companies that can afford the additional
infrastructure.
Cons
- Transcoding has many of the same limitations associated with it that general
XML solutions do.
- Transcoders are not an "out-of-the-box" wireless solution. Transcoding
your current Web site automatically into WML would very likely generate
WML that would be unusable by any wireless device.
Other issues for developers
Another important item to review is the way you are handling session
management. You cannot depend on using cookies for session management with
wireless devices, because they are not uniformly supported. One work-around
is to use URL-rewriting or hidden fields to perform the same function.
You also may want to consider making your application stateless. If you
do rely on state, you will want to make sure that you take a close look
at how it is being handled. Cache control also has a greater significance with wireless devices.
- You will want to cache as much as you can, to avoid expensive trips back
and forth to the server, and also to minimize the wait time for your clients.
- Wireless devices are easily lost or stolen, so it's especially important
to make sure that no personal information is cached.
You can control how pages are cached in two main
ways: using HTTP headers, and by using Meta tags. HTTP headers should be
recognized by devices such as proxies and network caches. Set the Expires
header to some date in the future for pages that you want cached. On the
other hand, set the Expires header to a past date on pages that
should not be cached. For pages that should not be cached, you should also set the Cache headers:
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
|
You can also modify the way the page is cached using user-agent Meta tags.
Meta tags will be recognized by WAP devices, but not by network caches.
This example tells the user device to expire the page immediately:
<meta forua="true" http-equiv="Cache-Control" content="max-age=0"/>
|
An important issue to keep in mind with caching WML pages is that both
WAP devices and network caches work on decks, not cards within the deck. Note also that WML devices do not provide a standard look and feel,
and have many incompatibilities. This is a major frustration for wireless
developers. Some support a precursor to WML -- HDML; some support older
versions of WML; and others just implement WML poorly. Because of this, you should determine what devices you want to support
and create a device lab for testing. While there are many device emulators
available, they often do not reproduce the characteristics of the devices.
Do not rely on emulators for your final testing! They can be misleading,
because some of them are more forgiving of errors than the devices themselves.
Summary
Keep these items in mind when developing WML applications:
- Make sure that your application is a good candidate for wireless.
- Design your wireless application to create a good user experience, making
it easy and fast to use.
- Determine an appropriate architecture. Most companies will want to adapt
their current infrastructure for the near future. Companies with larger
requirements may want to look into XML or transcoding solutions.
- Decide on a list of supported devices, and create a device lab.
- Pay special attention to the new security and caching issues raised by
WAP.
- Test applications internally using emulators.
- Deploy to publicly accessible servers, and do user testing prior to going
live.
General wireless and WAP information
Software
-
OpenWave
makes one of the most popular wireless browsers, and has a good collection
of developer information. They are also one of the best sources for HDML
information.
Standards sites
-
WapForum is the
Industry standards body responsible for WAP
Vendor sites
Some major companies with WAP sites:
Resources - One important critique has come from usability guru Jakob Nielsen.
His analysis of the WAP user experience in Great Britain was very critical,
and has been picked up by the popular press.
- ZDNet went so far as to declare
that "WAP is Crap."
About the author | | | James Lewin has been working with the Internet since 1995, but he didn't go wireless until 2000. He is the President and owner of The Lewin Group a Networking and Internet Solutions provider. He is an MCSE who also works with Microsoft and open source Internet development tools. |
Rate this page
| |
