 eveloping wireless applications for mobile devices (such as cell phones and PDAs) presents software engineers, quality assurance engineers, and human factors engineers with a unique set of challenges. One of these challenges is to make a science out of something that is an art today: design and quality assurance for a user interface.
In this article we outline a technique for quantifying design and quality assurance for wireless development. While the specific example we use is a WAP application, you can use the same set of principles and mathematical models to quantify other types of mobile and wireless applications. The model we suggest can be used as the specifications for a tool that evaluates various user interfaces for devices, particularly mobile and wireless devices.
Before embarking on a comprehensive discussion of design and analysis of the human interface for wireless development, let's first consider why such an effort is so different from human interface design for a more typical Web application. Here are some of the unique problems faced by user interface designers in wireless application development:
- Limited bandwidth: A wireless device typically has much less bandwidth available for transmitting and receiving data than a wired device.
- Intermittent connection: The connection to a wireless device is typically unreliable. A persistent point-to-point connection is difficult, if not impossible.
- Limited battery life: A wireless device is typically (also) a mobile device. Since mobility dictates compactness in size, and since there is no wired power connection, batteries are the only means of power supply. Even the longest lasting batteries offer a very limited amount of power.
- Limited memory on client device: Once again, because of the mobile nature of wireless devices and their requirements to remain a small size, room for memory is limited. Memory is also limited by the available power source (batteries) on the device.
- Limited CPU: Because of the size of the devices and the battery life, processing information on the device is very expensive. Very few operations should be performed on the device and they should be only performed where there is strong justification for them.
- Limited user interface: A keyboard and/or a mouse are normally not available for a wireless or a mobile device. Also, the display is almost always very small. This makes viewing and data entry more difficult.
This article considers a three-tier architecture where the client browser, Web server-side operations, and database back-end operations each form a separate tier. Such architectures have proven themselves to be scalable and reliable. When you design a three-tier architecture for a wireless application, you quickly discover that there is no significant difference in database and middle-tier design between a wireless application and any other types of Web-based apps.
The problems enumerated above are almost completely confined to the client tier. This means that if your system is designed so that the business logic is decoupled from the presentation layer, and the business logic is encapsulated in the middle-tier, then developing a new GUI layer will be the most significant task you'll face.
It's also important to remember that various devices offer functionality previously unavailable on PCs (such as proximity information and history of path traveled). So we have to think of a user interface that's smart enough to know which device offers which functionality.
As you probably know well by now, the prevailing method for allowing various devices to access the same content is by pushing content into XML instead of HTML. Using Extensible Stylesheet Language (XSL), XML-formatted content can be transformed for presentation into HTML or other formats. In our example we assume that content provided by the middle tier is formatted in XML. This is important to know because it affects how we design the user interface.
|
Introduction
Selecting the Most Effective Interface
Beginning the Initial Design
How the Use Cases Add Up
