 | Level: Introductory Carol Jones (jcarol@us.ibm.com), IBM Fellow and Distinguished Engineer, IBM
01 Jun 2000 Find out how to use new Wireless Application Protocol (WAP) and Wireless Markup Language (WML) technologies so that users can access your Web applications using a variety of handheld or mobile devices, including Palm organizers, phones, and others. Carol includes five guidelines for designing for the small screen.
I know what you're thinking: Who would want to surf the Web on a tiny little screen while driving down the highway? Probably no one you'd want to carpool with. But think about it from a different perspective, and it sounds a lot more appealing: Suppose you're walking down the street with a friend who tells you about a great new book that you'd probably like. Wouldn't it be great to buy it on the spot and have it shipped to your home? Or suppose you arrive at O'Hare airport in Chicago to discover that your connecting flight has been canceled. You could dial up the travel agent and wait on hold doing a slow burn while you wonder which gate or ticket counter to sprint toward. Wouldn't it be better if you could find the alternative flights right on your phone's display and start directly for the gate? Or how about getting notified about the price of a certain stock, without having to look it up? Well, you can do all that today, and much more. Read on, to find out how to use the Wireless Application Protocol (WAP) and Wireless Markup Language (WML) to make your Web applications accessible across the Internet from a variety of handheld or mobile devices, including Palm organizers, phones, and others. WML and WAP basics If you're reading this article, odds are that you're already familiar with HTML, the tag language used to make Web pages. To refresh your memory of HTML basics for the purpose of comparison, after you write an HTML page, you save it with an .HTML file extension, and then you place it in a specific folder of your Web server (called the document root), which makes it visible to the rest of the world. When people want to access your page from a browser, they type http://yourserver/yourpage.htm, where yourserver is the name of your Web server, and yourpage.htm is the name of the file that you placed in your Web server's document root folder. When this happens, the server sends the tags from your HTML file back to the browser, which knows how to render them on the screen. This request and response is called the Hypertext Transfer Protocol (HTTP). Wireless Markup Language (WML) works along the same lines as HTML, except that the language is specifically designed for small displays and mobile
devices. You create a WML page (actually, they're called cards and decks) in a text editor, and save it with a .WML file extension. Listing 1 shows a brief example.
Listing 1. A simple WML sample
<?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="Hello" title="Hello">
<p>
Hello from WML!
</p>
</card>
</wml>
|
Wireless Application Protocol (WAP) is a protocol that allows mobile phones and other wireless devices to connect to the Internet. Conceptually you can think of this as being similar to HTTP. You might be wondering why WML and WAP are even necessary. Why not just stick with HTML and HTTP, which are already universally available? Some mobile devices do, in fact, use subsets of HTML, and you can also access WML through an ordinary HTTP server. But to really take advantage of what the new wireless network and mobile devices have to offer, WML and WAP are necessary to get by limitations of technologies that were designed for desktop environments. Keep in mind that handheld devices work very differently from desktop computers. They have less powerful CPUs, less memory, smaller displays, and limited input capabilities. Wireless data networks also have less bandwidth, less predictable availability, and less connection stability than the typical home or office network. Before we get too far with the details of WML and WAP, let me explain how to publish and test the simple example in Listing 1. Once you've got that working, you can try some more complex examples and learn a lot more about developing wireless applications.
Publishing and testing WML If you have a Web server installed on your own computer, you can test your WML file pretty easily. But first, you have to configure your Web server so that it understands WML decks and their MIME type. I use the IBM HTTP Server, so to make this configuration change, I had to edit the httpd.conf file and add the following line:
AddType text/vnd.wap.wml wml
|
If you're going to do a lot of work with WML, you might want to go ahead and add a few other MIME types while you're at it:
AddType image/vnd.wap.wbmp wbmp
AddType application/vnd.wap.wmlc wmlc
AddType text/vnd.wap.wmlscript wmls
AddType application/vnd.wap.wmlscriptc wmlsc
|
If you use the Apache Web server, you follow the same steps. If you use a Netscape or Microsoft server, or some other Web server, consult the server's documentation to find out what changes to make. If you use an ISP, contact the ISP to see if it can handle WML files correctly. OK, that takes care of the first step. Now you need a browser to view the cards with. If you try your normal desktop Web browser to access the card, you'll find that the browser doesn't display it correctly. At best, it will display just the tags inside the file, instead of showing something like the picture for Listing 1. To display the card properly, you need a WML browser. You might be surprised to find out that there are quite a few to choose from. You can download WML browsers from Phone.com, Nokia, Ericsson, Slob Trot, and a few other places. (I'll give you the links in the Resources at the end of this article.) Personally, I like the one from WinWAP from Slob Trot Software Oy Ab, and I also use UP.Simulator from Phone.com. The WinWAP browser looks a lot like a desktop browser, but UP.Simulator looks like a mobile phone. Once you've got a browser installed, you can just enter the URL for your WML deck, just as you would in an ordinary browser, such as http://localhost/Hello.wml. See what the result looks like in the different browsers in Figure 1.
Figure 1. The results of Listing 1, shown in two browsers, WinWAP 2.2 and SP01 from Phone.com
WML tags The WML language defines tags for user interface components, somewhat similar to HTML tags. But WML -- based on Extensible Markup Language (XML) -- is very different from HTML. Instead of a page, WML displays are called cards, and a WML file can contain multiple cards. The WML file is called a deck. Cards contain text, images, links, data-input elements, list-selection elements, and fieldsets. Fieldsets serve as containers for additional WML elements. Because WML is based on XML, all tags must have matching beginning and ending tags. The syntax is case sensitive, and it must be lowercase. Let's go through some of the major tags. Instead of listing the complete syntax for each tag, I'll give you a few examples. Text, tables, and images Text is displayed in the paragraph tag:
<p align="left" mode="nowrap"/>
|
WML includes <table>, <img>, and <tr> elements, similar to HTML tags but with fewer capabilities. WML allows very little formatting capability for text; it's limited to italics, bold, emphasis, and strong tags. Links Links are described by the <a> tag.
<a href="url" title="label" accesskey="1">
text or image tags
</a>
|
Links have a title, which describes the link. Different devices use the title in various ways, such as by displaying a tool tip, playing a voice prompt, or using it for the label on the phone keys. For compatibility with a wide range of devices, limit the link title to five characters. The accesskey attribute places a number to the left of the link text. Input elements The input element lets the user enter text.
Enter something:
<input name="varname" title="label" type="type"
value="value" format="specifier"
emptyok="boolean" size="n" maxlength="n" tabindex="n"/>
|
After the user enters something, the data is stored in the variable called varname. Specifying type="text" causes the text to be visible; type="password" causes the text to be replaced by * characters (asterisks). You can also specify a data format that the user's entry must match, including alphabetic or numeric characters. The emptyok attribute specifies whether the user can leave the field blank. You can group multiple text or input tags using the fieldset tag. List selection The select tag specifies a list of options that the user can choose from.
<select title="label" multiple="boolean" name="variable"
value="default" iname="index_var" ivalue="default"
tabindex="n">
<option value="1">
<img src="/img1" localsrc="" alt="Choice 1"/>
</option>
<option value="1">
<img src="/img2" localsrc="" alt="Choice 2"/>
</option>
</select>
|
The choices are in the option tags, and they can be presented as text or images. Navigation The other major set of tags are related to navigating through cards. The go tag tells the device to open a particular URL. If the URL specifies a particular card, that card is displayed. If the URL specifies a deck, the device displays the first card in that deck. It's very similar to the action parameter on an HTML form tag. The do element ties a user interface mechanism to an action. Examples of user interface mechanisms are the OK, MENU, and BACK buttons on the phone.
<do type="type" label="label" name="name" optional="boolean">
action
</do>
|
The actions are other tags, such as go, rev, nook, refresh, and exit. Listing 2 shows the scripts for several cards, with examples of the most common tags.
Listing 2. WML tag examples
<?xml version="1.0"?>
<wml>
<card id="links">
<p>
Some links:<br/>
<anchor title="Fields"><go href="#fields"/>Fields</anchor><br/>
<anchor title="List"><go href="#list"/>List</anchor>
</p>
</card>
<card id="fields">
<p>
First Name:
<input name="fname" maxlength="15" /> <br/>
Last Name:
<input name="lname" maxlength="15" /> <br/>
Password:
<input name="password" maxlength="8" type="password" />
</p>
<do type="accept" label="Next">
<go href="#list" />
</do>
</card>
<card id="list">
<p>
State:
<select title="state" multiple="false" name="state" value="GA">
<option value="GA">GA</option>
<option value="NC">NC</option>
<option value="SC">SC</option>
<option value="TN">TN</option>
<option value="VA">VA</option>
</select>
<do type="accept" label="Home">
<go method="post" href="#links" />
</do>
</p>
</card>
</wml>
|
When you run the examples in Listing 2, here's what the screens look like:
Figure 2. The screens generated by the examples in Listing 2
Scripting for WML Now you know the basics of laying out cards, but there's still more that you can do. There is WML Script, which is similar to JavaScript. WML Script provides general scripting capabilities to do things like checking the validity of user input, sending messages, accessing the phone's address book, or sending messages. You can also use WML Script to produce messages or dialogs and potentially eliminate some extra trips back to the server for processing. WML can call WML Script functions, passing parameters, and can also set the values of variables inside WML Script functions. The WML Script can set text or images, move to different cards, or call different WML files. I can't really teach you WML Script syntax in a short article like this one, but there are some good online resources, and you can find the links below in Resources. But to give you a flavor of what it is like, I'll take you through an animation example in Listing 3. (Keep in mind, though, that users won't appreciate animations that merely dress up your application, so if you yield to temptation and include animation, make sure that it's central to the functioning of the application.)
Listing 3. A WML animation card
<?xml version="1.0"?>
<wml>
<card title="A simple animation">
<onevent type="onenterforward">
<refresh>
<setvar name="frame" value="exclamation1"/>
<setvar name="sleep" value="2"/>
</refresh>
</onevent>
<onevent type="ontimer">
<go href="animate.wmls#main()"/>
</onevent>
<timer value="$(sleep)"/>
<do type="accept" label="Done">
<go href="Hello.wml"/>
</do>
<p align="center">
<img alt="" src="" localsrc="$(frame)"/>
</p>
</card>
</wml>
|
In this example, notice a couple of new features. The onevent tags handle different events that the card deck can receive. Below that, a timer is defined, and then some actions for what to do when the buttons are pressed. When the card first displays, it shows an exclamation mark graphic in the center of the first line. Then a timer starts and runs for a certain number of milliseconds. When the timer expires, it calls the WMLScript function in Listing 4.
Listing 4. A WML script animation function
extern function main()
{
var frame = WMLBrowser.getVar("frame");
if (frame == "exclamation1")
{
WMLBrowser.setVar("frame", "exclamation2");
}
else
{
WMLBrowser.setVar("frame", "exclamation1");
}
WMLBrowser.refresh();
} //main()
|
The function is really simple. It gets the value of the frame variable, and then toggles it to either the first or second built-in graphic for an exclamation mark. After that, it refreshes the card, so everything runs all over again.
Figure 3. An animated exclamation point, from the function in Listing 4
This animation example uses graphics that are loaded in the memory of the phone, so it won't work in the WinWAP browser, and if you are using one of the phone simulators, it might not work in every phone configuration. That's an important lesson when you're working with mobile devices: there are a lot of differences, so you have to be really careful when you are designing your cards. Which brings us to the next subject...
Designing for small screens Now you know just enough about WML and WMLScript to be dangerous! This is a good time to go over some design principles that will make your WML applications better and easier to use. Since mobile devices like phones have such small displays and limited input capabilities, usability is critical. In fact, it's really more challenging to design for WML because of these constraints. So, here are the top five things to remember as you plan the design of a wireless Web application:
-
It's a phone, not a PC. People prefer to talk on it, not push the buttons. To keep user interaction simple, minimize the number of cards to navigate and minimize data entry.
-
Entering data is very difficult. To enter
ABC on the keypad, you have to press the 2 key once to get the letter A, then twice to get the letter B, and then three times to get the letter C. So be nice to your users and minimize the amount of data you ask them to enter. For example, ask them to enter a zip code or airport code instead of an entire city name. Or offer selection lists for picking the data instead of having users key it in.
-
Air time is costly and battery life finite. Users pay a lot to access the Web through a phone (let's hope it gets cheaper), so keep browsing sessions to a minimum. Think about battery life, too. Keep applications lean and optimized for the speediest possible performance. Animations are fun, but they're a bad idea if they're just a frill. If you can live without an extra calculation,
avoid it; do calculations on the server instead, as long as that doesn't cause extra trips back and forth.
-
Users are less technical -- and more demanding. People using a wireless application probably want a quick answer to a specific question; they're usually not just surfing the Web. Even the more technical users probably
aren't browsing. Someone using a mobile phone to make travel reservations is probably stuck in an airport someplace, not relaxing at home. Design and test with the end user in mind, because a person annoyed by your application probably won't ever try it again.
-
Mobile devices differ. Not all devices have the sample capabilities. Make sure to test your application on all of the target devices you intend to support.
A few years from now, most people could be accessing the Internet through their mobile phones instead of using a desktop computers. In fact, in Japan that's already true. WML gives you a powerful new way to make your Web applications available to these users, whenever and wherever they go.
Download | Description | Name | Size | Download method |
|---|
| Source code for this article | wa-wireless/source.zip | 2 KB | HTTP |
|---|
Resources
About the author | | |
Carol Jones is a Senior Technical Staff Member at IBM. She holds a master's degree from North Carolina State University. At IBM, Carol has led many software development efforts, including WebSphere, VisualAge, and Lotus products. Not one to miss a trend, she currently works in the Pervasive Computing Division. She spends lots of time thinking about how to make software easier for people to use. She can be reached at jcarol@us.ibm.com. |
Rate this page
| |
