KamalPatel.net
Back to Downloads/Articles

Creating Usable Wireless Applications

By Kamal Patel
February 20, 2001

Background

Space is at a premium in wireless devices, and the applications designed for such devices require careful User Interface design. Taking the web contents and squeezing them on these devices does not work. In this article we will discuss some issues that need to be addressed when designing such applications.

Limit the Soft Key Characters

A soft key is a physical key on a wireless device and most devices are equipped with left and right soft keys. Some devices only support limited characters in the soft keys so a good rule would be to try and limit the number of characters to five. Another option is to use images instead of text in soft keys. This way, we can create images using small fonts and use them instead. Here is an example of using images containing text in soft keys:

</do>

In marked part above, the home text is also a part of the image. Not all devices support the use of images, and in such cases the text specified in the alt attribute of the <image> element is displayed. Soft keys without an image can be created using the label attribute of the <go> element.

</do>

Provide One Key access

When using wireless devices, the user has to visit each link sequentially before they reach the right one. As an example, if we want to go a third level page in HTML, the user will be required to visit three hyperlinks, each time loading a new page. In a WML deck if the first link is at the 6^th position, the second one is at the 8^th position, and the third one at the 7^th position, the user is required to perform 21 clicks, going 6 + 8 + 7 in total, to visit the desired card.

The solution to this problem is by providing the user with one key access. If the user was simply able to click the key 6, followed by the key 8 followed by the key 7 then we would have achieved the same results with only three keys being pressed. WML 1.2 supports an accesskey attribute that allows us to specify the keypad key to use as a hot key for that option. This attribute, accesskey, is supported through the <a> element.

Notice the implementation difference between the two user agents above for accesskey attribute. Remember that accesskey is not supported in WML version 1.1.

Another way to implement the same feature is through the use of <select> and <option> elements, also called select lists. Select lists have become very popular among browsers supporting Up.Browser developed by Openwave (Previously called Phone.com). When using the <select> and <option> elements, the hot keys’ are assigned automatically starting from 1 through 9. Any elements after 9 are not assigned a hot key. Here is an image of a device created through the use of <select> and <option> elements:

<select> and <option> elements also support using images and make the deck look a lot more professional. This is code that generated the card displayed in the above image.

<p>

<b>select - option</b>

<option onpick="#crdTwo"><img src="images/finance.wbmp" alt=" "/>Finance</option>

</select>

</p>

</card>

If there are more than 9 options in your select list, clicking on the 0 Keypad calls the link in the 10^th position. A good design approach is to have the 9^th element as ‘More…” that would display the additional list options. Remember that keeping the user’s click to a minimum should be a very important design objective for wireless applications.

Always have a “back” key

When a card is displayed in the WML Browser it is also pushed into the device’s history stack. The <prev> element loads the last accessed card by the user from the history stack. Here is an example of using the <prev> element to create soft-keys.

<prev/>

</do>

Even though both the devices above loaded the same card we notice that the second one does not have a “Back” soft key. This is because some devices come with a built in soft key for going to the previous card and they ignore the <prev> element’s code. As the wireless devices are small, and have limited typing capabilities, it is important that we allow the users to go back to the previously accessed card.

Keep your decks small

Even though WML supports the creation of multiple cards in a deck, it would not be wise to package all cards in your application together in just one deck. WML supports this packaging mechanism so that commonly used cards can be grouped and loaded at the client browser at one time. This would be ok if your applications were small with 4-5 cards. This is because there is a limit to a number of bytes that can be in a compiled WML deck.

What is a compiled deck, anyway? When a request is sent from a user agent to load a WML deck the request goes through the wireless service provider to the WAP gateway. The WAP gateway acts as if it was the client and forwards this request to the web server. In return the web server responds with the requested content to the WAP Gateway. The WAP Gateway creates a compact version of this WML file in a format called WBXML (WAP Binary XML) and actually sends the WBXML to the user agent. The process of creating the WBXML involves:

· Replacing all elements with a predefined single character code

· Removing all comments and white space

· Compiling the deck

This process is also referred to as tokenization. The question about the limit of this compiled deck still remains open. What it this limit? Well, it depends on the device being used so there is no standard set for this limit. Generally the limit falls in the range of 1000 – 1400 bytes. When developing applications using emulators, most of them will display the actual size and compiled size of the deck. Here is an example that displays these sizes for the data entry example we used earlier:

In this example the uncompiled deck size is 395 bytes and the size after compiling is 206 bytes. Note that the limit only applies to compiled deck size.

Use Templates

Templates allow us to create common functionality and share the functionality among all the cards in the deck. A WML deck can contain templates that are created using the <template> element. Here is an example a back key created using a <template> element.

<wml>

<prev/>

</do>

</template>

</card>

</wml>

The advantage of using this method is that we do not have to write a back key for every card in this deck. All the above cards automatically get a back soft key assigned to them and so do all new cards that we create in this deck. Currently templates only support the use of <do> and <onevent> elements.

The advantage of using templates is very obvious. However, at times, it is possible that we do not wish to use this soft key created by the template. As an example, let us say that we have a help key in the template, which points to a help card. When all cards in the deck are displayed they show a help key, however, we do not wish to display this key when we are in the help card. We achieve this by overriding the template.

<noop/>

</do>

</card>

Here, we have created a key with a blank label that performs no operation by calling <noop>. Notice that when the same elements are defined at card level and deck level, card level elements have a higher precedence over deck level elements.

Conclusion

In this article we discussed some guidelines for making applications usable. Developing an application is one thing and making it usable is another. These guidelines along with others are important in order to make life easier for the users who will use these applications. Apart from what we discussed there will be other issues that you will need to consider when creating wireless applications. Remember that very simple things such as having the most commonly used features listed first or minimizing the amount of scrolling and keystrokes make a big difference in wireless applications.