![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Our multidisciplinary team of software developers, testers, human factors specialists, information developers, technical support staff, and marketing staff has designed and developed several releases of the IBM Wireless Client. This client software allows a user to connect wirelessly (or via a wireline system) through the IBM Wireless Gateway to a networked system. The client software is available on most Windows operating system platforms. Because the client is enabled across all of these operating systems, it runs on a variety of computer system hardware form factors: desktop, laptop, and handheld. We have just completed delivery of a client that runs on Palm OS v3.5. This article describes the lessons we learned as we ported the application from Windows platforms to the Palm OS platform.
The numerous form factors enable the product to support several user scenarios, such as:
- A police officer who uses a laptop from the front seat of his patrol car to query a remote database for records of past criminal offenses of a currently apprehended suspect
- An office worker who uses her desktop computer system to connect to her company's intranet through a wireline LAN
- A traveler who uses a Windows CE handheld device with a wireless modem to obtain Internet access for directions to a seafood restaurant while lost on the highway
These users perform identical operations with an identical object-oriented user interface across the different Windows operating systems, hardware form factors, and handheld devices. A critical consideration in the Windows client interface design was that of screen real estate. To maximize code reuse, the screen size of the smallest Windows CE device was used as the base window size for the client user interface on all Windows platforms.
In 2000, as customers began accessing information on multiple devices, our team began developing a wireless client for Palm OS v3.5. Our design goals were to:
- Maintain similar product behaviors, terminology, controls, and user models to maximize the transfer of knowledge when the user switches from running the application on a Windows platform to running it on the Palm OS platform, or vice versa
- Be a "good citizen" on the Palm OS platform -- namely, implement user interactions typical of the Palm OS interface rather than blithely follow Windows conventions, however appropriate they may be for the native Windows platform
We hoped that our prior work in developing the Windows client user interfaces would carry over to apply to this platform. However, due to the vast differences between the Palm OS and Windows user interfaces, only a small subset of what we had learned was relevant. Moreover, when our team started this project, we had very little experience in the development or even regular day-to-day usage of Palm OS applications.
To develop the new Palm OS client user interface, our first task was to submerge ourselves in existing Palm applications so that we could comfortably understand the interaction paradigm by which our application must abide. We also reviewed Palm OS user interface guidelines and reviewed other Palm OS applications for representative instantiations. With our newfound knowledge of appropriate Palm OS interface behaviors, we began creating the user interface, keeping our design goals constantly in mind. Our primary user-centered design activities for the client on this platform included:
- Conducting iterative heuristic reviews and user interface design sessions with the entire multidisciplinary team
- Applying a card-sort technique to gather preferred menu structures from prospective users
- Conducting usability evaluations with experienced Palm OS device users
- Assisting in the development and integration of online user assistance
During our iterative design and development process, we discovered several important differences between the Palm OS and Windows user interfaces that demanded consideration. Specifically, we found that these Palm OS characteristics had the greatest impact on our user interface design:
- Non-object-oriented graphical user interface
- Modal applications
- Unique user interactions
- Constraints in the display space
- Limitations in integrated user assistance
Each of these characteristics should be taken into consideration during the design of any Palm OS application. The last three items will be discussed in the second part of this article series.
Non-object-oriented graphical user interface
The Palm OS features a graphical user interface, but not an object-oriented one. On a Palm OS device, the user interacts with graphical representations (for example, application icons) and controls (for example, buttons, scroll bars). Rarely does a rendered image represent an object that allows the user to examine the contents within it and change its properties. Compare this to the Windows desktop, in which many graphical representations are considered to be objects, such as "My Computer," "Printer," "Recycle Bin," or files created by word processors.
The IBM Wireless Client for Windows adheres to this object model. That is, the user creates an object called a "Connection," using a wizard-style application. Through the wizard, the user can specify the desired properties for the Connection, such as a name, the wireless modem type, and gateway address. Once the wizard is completed, that Connection is represented on the Windows desktop as an object. Its properties can be viewed and changed through a notebook control, and a wireless session can be initiated by a command on a pop-up menu for the Connection object. Users who require several different types of connections -- such as a wireless modem, a dial-up, or a LAN -- can use the wizard to create as many distinct Connection objects as needed. This interaction style is very similar to the procedure a Windows user follows to add a printer to a system, and yields conceptually the same results.
This kind of object interaction model is not appropriate for the Palm OS. And, the immediate-access, quick-productivity nature of Palm OS applications would make a wizard-based application look and feel cumbersome and strangely foreign. While the Windows client is easy to use, its user interface had to be redesigned to conform to the Palm OS user interface design model. Palm OS devices have been designed to achieve an admirable balance of usefulness and minimalism: frequent commands should be readily accessible; navigation within an application should be limited; intermediating dialog windows should be limited in number; data should be entered and accessed quickly. In sum, an application should be designed to be so simple that a user can learn the basic functions of that application and be productive within minutes.
To abide by Palm OS design sensibilities, our client for the Palm OS had to immediately present the user with the minimum amount of prompts for information that would allow the user to successfully connect to a wireless gateway. No wizard could be initiated to take the user through a step-by-step entry of required information fields to define a connection. Instead, all of these data fields appear on the first window that is displayed -- the "main form," in Palm OS terminology -- after the user taps the wireless client application icon on the Application Launcher. For the user to connect to a wireless gateway, information must be specified in six fields (see Figure 1).
Figure 1. The main form of the IBM Wireless Client for Palm OS
Three information prompts -- Name (of the connection), Password (prompt at log on), and Network (connection configured for the most recently used virtual serial driver) -- are filled with working default values. The user must provide information in the remaining three fields: Gateway (host name or IP address), User Name, and Organization. (The latter may require no data, depending upon the configuration of the gateway.) Once the appropriate information is specified in these fields, the user can log on to the gateway by tapping the Connect button at the bottom of the main form.
Because Palm OS device users still need to have multiple connections (for example, to connect to a different gateway), the Name control is implemented as a pop-up list from which the user can select the desired connection. (The pop-up list is a control that is very similar in nature to the drop-down list box control of other platforms.) All other fields on the main form display the properties of the currently selected name in the list. To provide the user with the ability to create several connections, we implemented a simple New command, rather than a wizard-style application, which adds the text "New" in the Name pop-up list and clears all the remaining property fields (see Figure 2). The newly-cleared fields indicate to the user that information is required to create a functional connection.
Figure 2. A new Connection form
The Palm OS user interface is completely modal. Users are placed in a state, or mode, in which they can only work with a single application. All windows and dialog boxes within an application are modal as well. The consequence of interaction in this environment is that users must make decisions and perform actions before proceeding to another Palm OS application or task within an application.
Within graphical user interfaces on desktop platforms, modal application behavior is generally considered to be undesirable. Modal behavior restricts users in that they must stop any other task within the application and attend to the action at hand. However, modal behavior may be appropriate at times, for example, when the application requires information before it can complete an operation. Specifically, print dialogs are typically modal, requiring the user to specify the printer, the specific pages to print, or the number of copies to print, before allowing the user to return to the part of the application that is to be printed.
In the Palm OS environment, modal behavior is ubiquitous. A running application must be stopped before another can be started. Dialog boxes must receive some kind of user action before returning to the parent application. However, the Palm OS device has been designed so that the user becomes easily accustomed to this behavior: Applications are streamlined and start and stop immediately; dialogs often require simple decisions and actions in order to interact with them. Above all, simplicity is an overriding philosophy of the Palm OS device, and the management of multiple modeless applications and dialog boxes would add complexity to the user's tasks, not to mention the modification of the device and its software code to handle such behavior.
For the Wireless Client for Palm OS, the modal nature of the environment meant that our development team had to redesign the presentation of status information. On the Windows platform, the gateway-connected user is able to monitor status, such as signal strength, by dynamic icons that appear in the taskbar system tray or as part of an optional toolbar that is displayed on the desktop. Figure 3 depicts icons that are displayed in the system tray of the Windows OS and flyover text that the user might use to determine status regarding Windows wireless client. The last three icons indicate active connection, signal strength, and modem battery strength, respectively.
Figure 3. Wireless client connection status displayed in the taskbar system tray of Windows 95
No such toolbars are possible for display in a Palm OS application. As a result, client status on the Palm OS is conveyed by means of dialog boxes that are invoked by commands from a Status menu option (see Figure 4).
Figure 4. General status information for a Connection
An additional impact of Palm OS modal behavior is that if the user requests context help for a particular dialog, the help information appears in a separate dialog that completely overlays the dialog in which the task is being performed. This can be frustrating to a user who is accustomed to the interaction style of a desktop interface in which a modeless help window can be placed adjacent to the task dialog and reviewed simultaneously. Therefore, beware of placing step-by-step information or other complicated text in help dialogs within the Palm OS; forcing the user to memorize information on such a dialog in order to use the information elsewhere is a questionable practice.
The high-level issues that we've presented here clearly distinguish the Palm OS user interface from the current predominant graphical user interfaces of the Windows platform. These characteristics are significant contributors to the user model of the system, and demanded consideration and understanding before we can reasonably attempt any lower-level design of the user interface and interaction with the wireless client application.
The second part of this series will cover more microscopic issues related to designing a Palm OS user interface, specifically within the context of porting a Windows application to this environment. We discuss some unique user interactions of the Palm OS, the limited amount of display space and its implications for our design, and important considerations in integrated user assistance on the Palm platform.
- Visit the Palm OS Developer Documentation Web site, which provides additional resources -- including tutorials and specifications -- related to the platform.
- Palm also offers a Development Support site that includes source code, licensee information, and an FAQ section.
- The Palm OS Web site includes a resource for developers with news, code, and tools to help get you working with the platform.
- IBM alphaWorks offers a Bluetooth protocol stack that enables programmers to easily develop Bluetooth applications for the Palm OS.
Patrick Cox began his career with IBM as a co-op in 1991 and was eventually hired as a Staff Software Engineer. He received a Ph.D in Human Factors from North Carolina State University in 1999. He currently performs various user interface design and evaluation activities for WebSphere Transcoding Publisher and WebSphere Everyplace Gateway, Gatekeeper, and Client. Ever since he began working on this project, he can't live without his Palm IIIc. You can reach Patrick at phcox@us.ibm.com.
Velda Bartek is the user-centered design lead in the Pervasive Computing organization. She currently works with the WebSphere Transcoding Publisher, WebSphere Everyplace Gateway, and WebSphere Everyplace Server teams. Her Palm device was last seen in Texas. You can reach Velda at bartekva@us.ibm.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
