A ten-minute guide to setting up a WAP site

Intended audience

This article describes, very briefly, the steps involved in providing WML pages to mobile devices, in particular WAP-enabled mobile phones. It assumes that reader is already familiar with HTTP, HTML, and Web server operation, but knows nothing about WML or WAP protocols. The article does not attempt to describe WML, but does provide a simple example.

Basic principles

Viewers for WAP content are often called microbrowsers. Microbrowsers are found in WAP-enabled mobile phones, and some PDAs, among other things. If you are familiar with Web servers, then you may be reassured to know that at least one thing is the same for WAP services: the HTTP protocol. WAP microbrowsers use exactly the same HTTP protocol for exchanging pages as ordinary Web servers and Web browsers do. So, although you could pay a good deal of money for a `WAP server’ for your enterprise, in fact any Web server will do perfectly well; Apache, for example. Of course, some WAP server products offer a good deal more than basic HTTP support, such as portal services and content management. However, if you just want to create pages of data and make then available to WAP phones, all you need is a Web server. In the same way that Web browsers expect their pages to be delivered in HTML format, WAP microbrowsers expect content in WML format. WML (WAP Markup Language) is simply XML, formatted according to a particular schema. Unlike traditional HTML, which only has a passing resemblance to XML, WML is true XML. It can be processed by a validating parser, and ill-formed content rejected. In principle, WML’s stricter syntax rules suggest that there should be less inter-browser variability in formatting than is the case for HTML, but my experience has not borne this out. You should consider testing your WML pages with more than one browser if you want good coverage.

A significant difference between WML and HTML is that a WML document can contain multiple pages (cards, in WAP jargon). When the browser loads the WML document, it will usually display the first page. This will generally contain links to the other pages. HTML, of course, has a single-page format. If you want to display multiple pages, you need multiple HTML files. The difference is for a very good reason. A WAP phone has to establish a dial-up session for each request, and this takes time. It is more convenient, therefore, if the browser can retrieve a set of pages at the same time. WML provides the concept of cards to enable pages to be grouped. Because a WML file contains cards, you will see the phrase `WML deck’ used to mean a WML file. This is a trendy piece of jargon, and `deck’ means nothing more than `file’ in this context.

When a WAP-enabled phone is asked to display a WML page, it needs a URL. The URL has the same format, and meaning, as the URL in any ordinary Web browser. When it has the URL, the WAP phone will dial up a WAP gateway, and then issue an HTTP request for that URL, usually over the public Internet. The gateway collects the response, and returns it to the browser. The browser then hangs up (either immediately, or after a short delay).

The following sections describe step-by-step what you need to do to get a very simple WML page available to WAP phones.

Step 1: get a web server running

Unless you are going to run your own WAP gateway, that is, software that accepts incoming phone calls and relays them to a Web server, you need a web server on the public Internet. You don’t need exclusive access to the server; if your existing web site is hosted by an ISP, even a free ISP, it should be possible to host WAP content as well. However, the Web server must deliver the correct content-type header when the browser requests WML content. With the Apache Web server, this mapping from file extensions to content types usually lives in /etc/mime.types, although you can also use an AddType directive in httpd.conf. Other servers have other conventions. As a miniumum, you need to ensure that the file extension .wml, or whatever else you intend to use for your WML pages, maps onto the content type text/vnd.wap.wml. There are other content type mappings you might need, but this one is a minimum. The problem with using any kind of shared Web server, either paid for or not, is that you may not be able to influence the mappings of file extensions onto content types. However, all modern Apache versions have WAP mappings in the default mime.types file, so if your ISP uses Apache you should have no problems.
If you intend to deliver Java applications to suitably-equipped devices via your WML pages, then you need to make sure that the appropriate content types are mapped. This is not a default in Apache, so you’ll need to do it yourself. Add the following lines to httpd.conf:

AddType text/vnd.sun.j2me.app-descriptor jad
AddType application/java-archive jar

Of course, other Web servers will require this configuration as well, using whatever technique they support. It is not difficult, in principle, to run your own WAP gateway, and this may be useful for a company that wants to provide a private resource to its employees. A WAP gateway is nothing more than a modem and a PPP server. However, to make use of a private gateway requires some reconfiguration of the browser’s communications settings, and not every WAP phone user will be happy doing this reconfiguration.

Step 2: create a WML page

This is not the place for a tutorial on WML; in any case, there are plenty of those on the Web. Suffice it to say that you need a WML page to test your WAP service, and if this is your first time using WML you should probably make it as simply as possible. The listing below shows a very simply example: it is a deck of two cards, with links between the cards and a bit of text.

<?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="test1" title="KB WAP test p1">
<p>
Test page 1
</p>
<p>
<a href="#test2">Next page</a>
</p>
</card>
<card id="test2" title="KB WAP test p2">
<p>
Test page 2
</p>
<p>
<a href="#test1">Prev page</a>
</p>
</card>
</wml>

Step 3: upload and test with an emulator

Put you WML page(s) into any convenient place on your Web site. If you are planning to build a large WAP site, you would probably want to set up a separate site or area of your site, but this isn’t essential. When you request the WML page with a browser, you will specify its URL just as for an HTML page. I strongly recommend testing the WML pages, and the Web server, using a WAP browser emulator. Then if things don’t go according to plan when you request the page using a microbrowser, you can at least be reasonably confident that the problem does not lie with your Web server or its configuration. I use Deck-it from PyWeb; this is available free of charge for Linux and Windows systems. All you have to do is run Deck-it, and enter the URL of your WML page.

One word of warning, however: do not assume that because you can fetch and display your content using an emulator, you will be able to do so using a real microbrowser. Deck-it, and most other emulators, are far more tolerant of badly-formed WML, and incorrect response headers, than real microbrowsers and WAP gateways are. Remember that a microbrowser is very limited in its memory footprint, so it will parse the WML in a fairly prescriptive way. If your WML isn’t up to par, not only will you not get a display, but you won’t even get a helpful message. Error messages like `bad response from origin server’ may simply mean that your WML is syntactically incorrect. It’s worth getting hold of a WML validator, the stricter the better. Alternatively, there is a public WML validation service at HTMLHelp.

Step 4: test with a microbrowser

If you are using a WAP-enabled phone or PDA, all you need do is start the browser, and enter the URL. On Nokia phones, for example: select `Services’ from the main menu, scroll down to `Go to address’, then enter the URL. With a bit of luck, you should get the same display on the screen that you did on the emulator, or at least something similar. As mentioned before, don’t assume that because an error message looks horribly technical, that it isn’t a simple error like missing a closing tag in the WML.
Be aware that some low-cost mobile phone services restrict phones to getting WAP content from the service provider’s hosts. If you have such a phone service, it will be difficult to enter the URL of your WML site. Nearly all mobile phones allow the communications settings to be changed, and the limition can be overcome by pointing the phone at a different WAP gateway. Of course, you may have to pay for the use of such a service.

Providing Java applications to WAP devices

This is not the place to describe how to create Java applications for mobile devices; I assume that you have available the JAR and/or JAD files that implement the desired application. In brief, the JAR file contains Java executable code in compressed format, while the JAD file is a text file that provides information about the application. Not all WAP devices require JAD files, but most do, so it’s as well to provide them. Mobile devices that support Java applications (known as midlets) generally provide a number of ways for the user to get applications onto the device. For WAP devices, an interesting approach is to make the applications available for download using WAP protocols. In WAP jargon this is called over the air (OTA) installation. Devices that don’t support OTA will use a cable, or bluetooth, or infra-red communication. These installation methods are not relevant to the present discussion, as they are proprietary and not covered by WAP standards. I will concentrate here on making Java applications available OTA.

WAP phones that support OTA installation normally provide the user with at least one of the following methods of download.

• The user follows a link in the browser to a JAD or JAR file (JAD is more widely supported). The device downloads the JAD, locates the corresponding JAR, downloads the JAR, and installs it. Normally the user gets asked at some point if it is OK to install.
• The user tells the phone to install an application, and provides a URL. The URL links to a WML page that contains a list of hyperlinks to JAD or JAR files. The device extracts the hyperlink text from the page, and presents a menu of application choices. When the user selects an application, the device downloads the corresponding JAD and JAR file, and installs the application.

You can support both these methods using the same WML page: just provide a page titled `Application downloads’, or whatever, and provide in the WML a list of hyperlinks like this:

<a href="myhost://myurl/app1.jad">Application 1</a>
<a href="myhost://myurl/app2.jad">Application 2</a>
...etc

The use of absolute URLs in the href tags is necessary, for maximum portability. Mobile devices don’t necessarily assume that a Java application can be obtained from the same directory as the WML file that references it, even if that is the case. In other words, even if your JAD and JAR files are in the same directory as the WML files, you’ll still need absolute URLs to the JAD files.

Top 10 Usability Guidelines for WAP Applications

Following are the things you must practice in your wap projects.

1. Implement navigational menus using a <select> elements.
   The Openwave select element implementation presents one user-friendly list with numbers which act as accelerator shortcut keys, allowing the user to select an option by pressing the corresponding number on the keypad rather than scrolling to it.
2. Keep soft key labels to 5 characters or less.
   Many devices cannot display soft key labels that exceed 5 characters, and will truncate or abbreviate any labels that are longer.
3. Use Wizards instead of forms.
   By using a single card for each input of information, the user can follow a natural process of entering information. User studies show that wizards make for a better user experience than forms. Finally, avoid having a separate ’submit’ card. The last ‘ok’ of the wizard should in fact be the ’submit’ option. This avoids an unnecessary additional click.
4. Keep the content that appears above select and input fields to 1 or 2 lines max (including images).
   Content exceeding two lines may be truncated on smaller devices when used in conjunction with input and select fields (choice and entry cards). This may result in the loss of important information. Test your application on small-screen devices to make sure menu titles and input field prompts fit.
5. Assign the most commonly chosen action or most intuitive task to the accept soft key.
   Make it easy for the user to select the card’s most common action by pressing a single key — the accept (OK) key. Don’t force the user to move the cursor before pressing the accept key (e.g., by making them navigate to some text anchor first).
6. Don’t use the <go> task to navigate to a card that is already on the history stack.
   If you link to a card the user has already visited (e.g., the application’s main menu), be sure to navigate to the card by popping cards from the history stack instead of adding a redundant card to the history stack. This minimizes the risk of history stack overflow on memory-constrained devices, which can result in the user being unexpectedly returned to the subscriber homepage. Use the <prev> or <exit> tasks whenever navigating in the backward direction.
7. Allow the user to dial phone calls from the application by pressing a single key.
   Use the wtai://wp/mc; directive to allow a phone call to be invoked directly from an application via a soft key. Ensure that your application uses this feature whenever you display a phone number. Label the soft key Call so that the user can easily discover the feature.
8. Use the format attribute to constrain text input fields to only allow valid character types.
   In some applications, text entry fields can employ character format constraints. These guide the user to enter the required information. For example, if the user must enter a credit card number of 16 digits, the entry field can be formatted to accept 16 characters exactly. Other formatting is also possible; for example, the browser can be limited to accept only numeric entries. Use format=”NNNNN” for US zip code fields.
9. Don’t set a deck’s expiration (maxage) to a low value unless the content is highly volatile.
   Setting a short expiration time for non-volatile decks (e.g., static application menus) may force the user to reload the deck from the server even though the deck is already in the browser cache. Applications that optimize deck caching are perceived by users to be more efficient and less costly, since they minimize connection times over the wireless network. Short deck expiration values should only be set for highly volatile content (e.g., stock quotes).
10. Ensure all decks are smaller than 500 bytes.
    The download latency for very large decks (1500-2000 bytes) can be over 10 seconds. Wireless device users perceive network latencies to be longer than they actually are, because consumer-grade devices are typically single-tasking devices (prohibiting users from performing other tasks on the device while waiting for content to load). To minimize network latencies, keep each deck as small as possible. The recommended guideline is 500 bytes or less per deck (encoded WML).

Principles of Mobile Web Design

In order for a site to work on a wireless handset, it must adhere to most website accessibility design guidelines, as set out by the W3C. Mobile handsets use WAP technology to browse the Internet. Because of limited screen size, many WAP browsers strip out CSS, and show text in a method similar to how a search engine spider renders a site.

• Websites using tables for layout will not render well on mobile handsets. The site must use CSS for layout
• The site must be coded using either XHTML or XML
• Character encoding should be UTF-8
• Bear in mind different screen sizes of mobile users. The largest screen size available is probably 640 x 480, whereas the average is closer to 120 pixels
• The most important information of your site must be right at the top of the page as it can be very time-consuming for browsers to read through
• Text entry can be quite difficult. Users prefer to select values from a list of choices, such as radio buttons or lists
• Images should be jpeg or gif
• Always provide a ‘back’ button or link, since many phones don’t include a back button
• The maximum total page size recommended is 20 kilobytes
• Remember that your users are paying a lot of money to access your site, so make sure it is definitely worth their money!

Device Capability Detection and Content Transformation

In WAP sites there are two main issues which difficult the job of the developer to create a solution which is optimized and supported on large number of handheld device (featured phone, smart phones and PDA’s etc.).

1. Device Capability Detection

2.Content Transformation

Device Capability Detection

Today there are two major browsers versions in market for wap, i.e WAP 1.0 (WML supported) & WAP 2.0 (XHMTL-MP supported) . Now problem occurs, how can we know that certain device/user is using WAP 1.0 browser, WAP 2.0 browser or it is simply using desktop browser. It is important because a service provider always wishes to redirect a user to certain information/service according to device capability. Its the case when service provider decides to develop its services for wap also.

1st thing to be done is now to detect the device/user and made the decision for redirection. The redirection can be from web to WAP, or from WAP to web. It can also be from WAP 2.0 to WAP 1.0 or vice-versa. Its totally on your implimentation.

This distinguish b/w the handheld devices/browsers and desktop browsers is very easy. All you will have to do is to get the user-agent parameter from the requested side and redirect the user to wap/web site. This is done by reading the user-agent parameter. Now here starts the real game. How to detect and differnciate the handheld devices. e.g. the user access the wap.example.com. now how are service will know after getting the user-agent that its is WML suppoted handset/mobile (browser) or XHTML-MP suported mobile (browser). Here is the solution to this problem.

(i) WURFL (Wireless Universal Resource File)

The WURFL is an “ambitious” configuration file that contains info about all known Wireless devices on earth. Of course, new devices are created and released at all times. While this configuration file is bound to be out of date one day after each update, chances are that the WURFL lists all of the WAP devices.

You can think of the WURFL as a global database of all devices and their capabilities.
Of course, the wurfl is not all that there is to it. What you also need is a way to efficiently read the info from the database and use it in your applications to dynamically customize your apps for families of devices.

i recomend you people to user WURFL API for device detection. pass the user-agent to this api, it will return you a boolean telling weather this device is xhtml compatible or not and now u can make your decision.

here you can find more details:

http://wurfl.sourceforge.net/

(ii) UAProf (User Agent Profile)

UAProf (User agent profile) is an XML document that contains information about the user agent type and device capabilities. It is a standard defined and maintained by the Open Mobile Alliance (formerly the WAP Forum).

UAProf was created according to the CC/PP (Composite Capabilities/Preferences Profiles) framework with RDF (Resource Description Framework) as the schema. Both CC/PP and RDF were defined by the W3C (World Wide Web Consortium).

User agent profiles are stored in a server called the profile repository. Very often a profile repository is maintained by a mobile device manufacturer. For example, the user agent profiles describing the capabilities of Nokia cell phones are stored in a profile repository maintained by Nokia.

Note that not all mobile devices support UAProf and so you may not be able to find the URL of the UAProf document in HTTP headers. If the mobile device does not support UAProf, you can still find out certain information about the user agent using traditional HTTP headers such as Accept, Accept-Charset, Accept-Language and User-Agent.

2. Content Transformation

Content Transformation means sending a content to download on user request according to his/her mobile device specifications. It also can be a desktop pc.

As I already said about how to detect a device and explore its capabilities.

Now is the time how to send content to the user.

There are two ways to deliver content to the user.

1. You store your content in many formats and sizes, and when you check the capabilites of the device, after that you send him/her content which is most suiteable for his/her mobile device.

Benifits of the approach is its simpler and draw back is space acquired by content storage.

2. The more practical approach is Content-Transformation.  In this way you store the content(ringtones/wallpapers) in a standard format. e.g for wallpapers, you use jpg and mp3 format as standard.

RIngtones:

When you are dealing with ringtones, get the this content, if this format is not supported by the user device, convert it to other format using 2rd party tools or by you own code, e.g .mp3 to .amr and then send to the user. If the user supports the mp3, no transformation is needed and you can send him/her content directly.

Wallpapers:

In wallpapers, format doesn’t matters much, but its dimensions. But sometimes both matter.  In this case, device resolutiion is checked for device requsting content, and then the wallpaper is re-sized according to the device resolution. Remember try to store your wallpaper content in larger dimension for better results.

WML Limitations

• WML phones do not support standard graphics such as Gifs or Jpegs, they do support a black-and-white image format called WBMP (Wireless Bitmap)
• WML phones cannot show applets, Flash movies or any other embedded objects. Frames, DHTML, JavaScript etc. are out too.
• WML phones are limited to 2000 characters of text.
• You cannot view WML sites on your browser.