Building Usable WAP Applications

General Usability Guidelines

It is important to develop a set of concrete guidelines that you can apply when designing a WAP application. Here are the most important questions you should ask yourself:

 

Ø       Is the application easy to learn?

Ø       Is the application efficient to use?

Ø       Are unusual operations easy to remember?

Ø       Do users get stuck when there are errors?

Ø       Are users likely to be frustrated by their attempts to use your application?

 

Answering questions like these will put you on a good track to working out how usable your application is. Let's see some general rules for building usable applications.

 

Ø       Top 20% of functionality: When porting an existing application to WAP (an HTML page, for example), you should identify the main activities that users will be interested in using while on the road. Porting parts of the application that are not commonly used will be more expensive for you, and will degrade the overall usability of the system, because of the extra levels and navigation paths you are bound to introduce. In the case of new applications, think of this rule as "refrain from implementing functions that the majority of users won't use on the road".

Ø       Rate user activities: Try to identify the main activities that the majority of the users will perform, and build your application in a way that will let users perform these activities in the fastest way possible. You should make sure that the most common activities are intuitively available for all users.

Ø       Design it as a tree structure: Lay out a hierarchical tree of activities. Users should enter the application at the root and be able to perform any of the available activities through some path starting at the root. Each level of the tree should be laid out according to the likely popularity of the activities it contains.

Ø       Minimize data entry: Most phones only have a phone keypad. Your application should require textual data entry only when absolutely necessary. Similarly, don't require users to remember codes or other information when visiting your application - try to remember things for them. In addition, the input mode of the terminal should be set to support the expected format for the data that users will enter. This can be achieved through input masks.

Ø       Text should be terse: Short, polished, and informative text is vital to guide users.

Ø       Always implement 'back' functionality: All users like to explore when confronted with a new application, and a 'back' function should be available to them at all times. But be careful: users should go back to a logical and consistent place in the application, which is not necessarily the previous card.

Ø       Consistency is very important: Applications can often require users to perform the same activity (or very similar activities) in different parts of the application. It is important that you deploy a consistent set of metaphors that will help users find their way around easily.

Ø       Push: Real-time information is a key piece of functionality that will give extra value to WAP. Unfortunately, push is not part of the WAP standard yet, but we should see it implemented in WAP 1.2. In spite of this, several proprietary possibilities to do push through WAP already exist, and you should exploit them if possible. Don't give up on the extra value your application can acquire through push.

Ø       Be prepared to test: If you are deploying a WAP application that is even moderately complex, you should be ready to build prototypes as early as possible in the development process. Find a non-technical person and let them use your application on real phones.

Identifying Activities

When thinking about the main functionality of your application, start by rating the user activities into categories according to how often users perform them. For example:

 

Ø       Activities that most users perform most of the time

Ø       Activities most users perform occasionally

Ø       Activities that specialized users perform once in a while

 

We give some more detailed groupings below. Identifying those activities is the basis for breaking down the navigation flow and optimizing the navigation path required to perform the main activities.

 

Ø       Think of the tasks required to achieve the object of each activity

Ø       Order the tasks by importance

Ø       Lay out your user interface

 

For each activity, you should understand how users expect to perform them, according to models users are familiar with. This could mean similarity with corresponding PC or phone functions, or with the way users perform the activity in their work.

 

Classifying activities in the following groups will help you map the design directly into WML:

 

Ø       Required Activities (compulsory activities for all users): These are activities that all of the application users will have to perform. One typical such activity is configuring your e-mail address and POP server when using an e-mail application for the first time. Configuring access to a different gateway is another example. It goes without saying that user-friendliness degrades unacceptably if operations like this are requested each time the user accesses an application. Avoid required activities or minimize them as far as possible. In many cases, you can uniquely identify each device and recall user preferences and configuration parameters automatically. Use this possibility and avoid requiring users to log in.

Ø       Main-path Activities (high use activities): These are the activities that 80% or more of your users are likely to perform. Such activities should be easily and intuitively available, without any learning curve or unnatural interaction path for the inexperienced user. Performing main-path activities should be as easy as possible (always one click away).

Ø       Semi-main-path Activities (high use by a large segment of, but not all, users): These are activities that many users (but not the majority) perform often. Keep access to semi-main-path activities as simple as possible, but make sure that they are not an impediment for users who do not perform them.

Ø       Side-path Activities (activities used occasionally by most users): These are activities that 80% of users will perform, but only 20% of the time they use your application. Replying to e-mail is one such activity. It makes sense to implement access to side-path activities in a menu that is not immediately accessible.

Ø       Rare-path Activities (activities never used by most users): These activities are there to support power users. If you identify rare-path activities, consider the possibility of removing them altogether. It's better to have a simple system than one with a lot of obscure options.

 

The classification of activities into main-path, semi-main-path, side-path, and rare-path gives developers an indication of how they should implement navigation to the different kinds of activities. Once a user is inside an activity however - whether it's a frequently used operation or not - you should support that activity like a main-path activity.