Contents: Working in Palm Unique user interactions Constraints in the display space Limitations in integrated user assistance Final thoughts Resources About the authors Rate this article Related content: Designing a Palm user interface, Part 1 Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Patrick Cox (phcox@us.ibm.com), WebSphere Human Factors, IBM
Velda Bartek (bartekva@us.ibm.com), WebSphere User-Centered Design, IBM
Keith Jones (joneswk@us.ibm.com), e-Procurement Product Development and Support, IBM

01 Sep 2001

This article concludes the discussion of specific implementation issues that software developers and interaction designers need to consider as they port applications from a Windows to a Palm OS environment. These lessons focus on unique user interactions, display space constraints, and limitations in integrated assistance in the Palm OS application interface. Part 1 presented experiences and lessons learned regarding the general, high-level Palm OS user model and interactions. Although the case study presented here is specific to the port of a wireless client, the observations are germane for those who develop any kind of application for the Palm OS, regardless of whether that application has a Windows legacy or not.

Working in Palm
This, the second of two articles, describes some of the experiences and lessons learned by our multidisciplinary development team while porting an existing wireless client application for the Windows platforms to the Palm OS. One of the goals that we identified was to allow client users to leverage their experiences between the Windows and Palm platforms and use both with equal ease. Our development team, which was very experienced with the use and development of Windows applications but inexperienced with the use (much less the development of) Palm applications, also wanted to provide a "good citizen" client on the Palm platform. With these two goals in place, a significant amount of effort was allocated to understanding user interaction behaviors on the Palm. Once we grasped the particular aspects of the Palm OS user experience -- specifically, the non-object-oriented and modal nature of Palm OS applications -- the user interface of the wireless client for the Palm OS began to take shape through user-centered design activities such as iterative design sessions, heuristic reviews, and usability testing for design validation.

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 the following Palm OS characteristics had the most 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

As mentioned above, the first two issues have already been discussed in Part 1. Now, we'll take a look at the remaining Palm OS characteristics that our team -- whose primary experience is with the Windows platform -- considered important in developing a user interface for the Palm OS. These characteristics should be taken into account by anyone developing a Palm OS application.

Unique user interactions
The Palm OS user interface emphasizes efficiency: Navigation should be simple, command selection should be quick, and data should be easy to access and edit -- all while using a stylus on a device that fits in a pocket. Consequently, user interactions differ considerably from the desktop user interactions to which users are most accustomed. The Palm OS contains several user interface controls that differ (either behaviorally or graphically) in their implementation on the Windows platform. The notable differences are:

• Menu characteristics
• Novel look and feel
• Text input devices
• Active controls
• Accessibility

Menu characteristics
In the Palm OS, menu characteristics diverge sufficiently from the Windows implementation that they must be taken into consideration when designing the method for the user to access commands.

Menu bar
The application menu bar is generally hidden from view and is made visible only when explicitly invoked by the user. Therefore, rather than be reminded by its constant visual presence, the user may often have to recall that additional command functions may be available.

Note the absence of the menu bar in Figure 1. To reveal the menu bar, the user taps on the product name, Wireless Client, at the top of the display area or on the menu icon that is silkscreened on the device.

Figure 1. The main form of the IBM Wireless Client for Palm OS

When the user taps on the product name or menu icon, the menu bar is revealed, as shown in Figure 2.

Figure 2. Menu bar for the IBM Wireless Client for Palm OS

The lack of this visual reminder of a menu bar may lead users to overlook important tasks that are only accessible from the menu bar. We found this to be true in our usability evaluations, when 100% of the participants failed to create a new connection definition. At the time, the only way to perform this task was by executing the New command in the Connection menu. The unanimous failure rate was surprising given that all participants were experienced Palm OS device users. Since this task is frequently performed, our solution to the problem was to place a New command button on the main window of the application. This not only made the command more obvious, but also made it easier to execute.

Command shortcuts
Command shortcuts enable users to bypass the menu bar and quickly execute commands by means of special combinations of graffiti keystrokes. This feature of the Palm OS is analogous to keyboard shortcuts on any desktop platform. While desktop applications typically provide keyboard shortcuts for only a few commonly used commands, most Palm OS applications provide graffiti shortcuts for practically every command. Our application was no exception to this practice -- we wanted users to enjoy the same rapid execution of the wireless client functions that they would be accustomed to with other Palm OS applications. As with Windows applications, which note keyboard shortcuts next to commands in the menu options, graffiti shortcuts (in particular /D and /L) are also noted on the menu bar, as shown in Figure 3.

Figure 3. Command shortcuts

Popup menu
Popup menus, which provide users with context-based access to menu commands, are not implemented in Palm applications. Because Palm OS applications typically have fewer commands -- commands that are readily available with just a tap or two -- popup menus are not necessary. Additionally, the nature of the input device -- namely, the stylus -- would make this feature difficult for the user to activate (for example, a double-tap or a prolonged tap with the stylus would complicate interaction with a simplified device).

Unique look and feel
Several user interface controls have a novel look and feel. The rationale for the novel control characteristics was no doubt driven by the smaller display space (as was the menu bar behavior above). However, new control behaviors introduce potential errors that can confuse the novice Palm OS user.

Hot text entry
This control has the basic look of a standard entry field but is outlined by dots rather than continuous lines. Data appears in this field -- this data can only be edited by means of a dialog that is invoked when the user taps on the field. In essence, this control combines a standard entry field with a routing choice button that indicates more data may be specified. In our wireless application, this control appeared prominently on the main form (see Figure 4) to reflect the current state of the password requirement: "Prompt," "Assigned," and "Not required." The dialog invoked from this field allows the user to specify a password or indicate that no password is required.

Figure 4. Password state displayed in a hot text entry field

Popup lists Because of the differences in hardware and software platforms, there are a number of differences in how user interfaces are coded on the Windows platforms and on the Palm OS platform. Some of these differences are true regardless of the application, such as the need to code within 64K segments. Others are specific to user interface aspects. One of these differences is the absence of a platform-provided drop-down selection list on the Palm. Here is a brief description of how we manually created one to use for the Name control popup list shown in Figures 5 and 6. Palm OS applications have an event-driven interface for various user interface objects. One such object is a popup list. When the user taps the pop-up trigger, the application automatically displays the list resource associated with the pop-up trigger (as shown in Figure 6). This association is created when the pop-up trigger and list resources are being developed. For lists with a dynamic number of items in them, the application can associate a list filling routine with the list resource. Once the user selects a popup list item, a popSelectEvent is given to the application. For a simple list, the application just needs to react to which list item was selected. However, to provide a mechanism like a selector box object, where the selected item is now displayed on the screen, more work is required in the Palm OS application. This is the behavior that we wanted for the Name control. A separate text field resource must be placed on the form to hold the selected list item text. As shown in Figure 5, the selected list item is endicott. However, there is no built-in capability on the Palm OS to automatically associate a text field resource with a list; it must be done through code within the application. In this case, when the application receives the popSelectEvent, it must get the text associated with the list item selected with the supplied API, LstGetSelectionText, and place it into the text field using the field API, FldSetTextHandle. This causes the text line to be updated on the display. In addition, the application is responsible for memory management of the field text space, so the previous text must be freed. While it does not require a significant amount of code to accomplish this, there are a number of these subtle differences in provided resources from Windows to those on the Palm. There is sufficient function on the Palm to create sophisticated user interfaces. It is unwise to assume, however, that a working user interface on a Windows platform will port directly to the Palm OS. In the application discussed here, the user interface portion was completely rewritten from the Windows version.

Figure 5. Name of connection control implemented as a popup list to display the properties of each connection

Figure 6. Activated popup list of configured connection names

As a result of this implementation, connection properties among the various connection definitions could not be viewed simultaneously, which made comparisons of properties among the connections more difficult for the user in a troubleshooting scenario.

Radio button
This control behaves similarly to the Windows radio button control, yet is rendered in a different graphical style. Rather than presenting the set of buttons as circular holes with adjacent text labels, the Palm OS graphically displays the mutually exclusive choices within the bounds of a rectangular grid (see Figure 7). Palm OS terminology also refers to this user interface element as a "push button."

Figure 7. Trace settings implemented as radio buttons

The active choice appears as light text on a black ground (Trace setting is "Off" and Maximum size setting is "Min" in Figure 7); non-active choices appear as black text on a light ground. Our maximum trace file size implementation of this control requires users to select the maximum size of the trace database that's used to store diagnostic information for troubleshooting. Because of the limited amount of storage space on a Palm OS device, the choices were in percentages of available space, rather than in absolute size (for example, 500 KB) of the more spacious storage available where Windows applications exist.

Password entry field
This control looks and feels different than the standard Windows implementation. Because even experienced Palm OS users err when entering graffiti characters, entry fields for passwords are not masked. This sacrifice in security has apparently been made because it is more important that the user has the ability to monitor graffiti input for accuracy. Consequently, when the user wishes to change a password, no companion entry field is needed to confirm the unobscured password.

Regardless of a user's Palm OS experience, graffiti keystrokes can make text input error-prone and, with a significant amount of data entry, onerous. With this in mind, we implemented a convenience function called "Duplicate" that creates a new connection with identical entries as the one displayed except for the connection name, to which the text "- Copy" was appended. This function makes it easier for users to create a new connection with similar specifications as the original, thereby avoiding the error-prone nature of creating a new one from scratch. Users can then make the appropriate minor modifications requiring less graffiti character input to this duplicate entry.

Menu commands and user interface controls are never disabled. If a function may not be used under a particular condition, rather than rendering its command or control on the display as grayed out, the command or control does not appear at all on the interface. This behavior is very different from a typical Windows application. For example, in the wireless client user interface, an Internet protocol address entry field would only appear in a previously blank area on a dialog if the user indicated that he did not want to assign the address dynamically.

Accessibility challenges
The Palm OS offers challenges with respect to accessibility for users with physical limitations. While it may seem that a handheld Palm OS device is by nature exclusionary, this is not necessarily always true.

Manual impairments
If a Palm keyboard is used in conjunction with the handheld device, keyboard navigation through the user interface is possible, obviating the need for a stylus. However, no voice input capability for the Palm OS is present at this time, so severely manually disabled users will not find the Palm OS accessible.

Visual impairments
Within certain limits, fonts can be enlarged to accommodate the needs of users who have trouble seeing detail. Applications can be written so that users can select their font size preference as small, medium, or large. No screen readers or speech output capability for the Palm OS are present at this time, so users with severe visual impairments will not find the Palm OS accessible.

Auditory impairments
Palm OS applications do not rely on sound to convey information. Therefore, individuals with hearing difficulty should experience no problems using a Palm OS device.

Constraints in the display space
For neophyte developers and user interface designers of Palm OS applications, perhaps the most obvious indication that this platform is different from desktop platforms is the scant display area for the application. The screen size of a Palm OS device is 160 x 160 pixels. Within this limited space, the user interface developer and designer must often struggle to offer a parsimonious, yet functional, usable, and useful application. Although vertical scrolling is commonly seen in Palm OS applications to extend the textual content of a single window (for example, help text or content from Web-based subscription services), application windows with buttons, entry fields, and other controls are rarely, if ever, scrollable. To effectively make the most important tasks easy for the user to accomplish, it's necessary to make trade-offs and compromises in usability and clarity in order to conform to the device display constraints.

In developing the Wireless Client for Palm OS, we encountered several difficulties in accommodating the small display size:

The number of command buttons that can be placed across the bottom of the display is limited by the number of characters in the buttons' labels. Based on our previous experience with the IBM Wireless Client for Windows and feedback from our usability evaluations on early Palm OS client prototypes, we decided that the appropriate command button functions to provide on the main form of the Palm OS client would be Details..., Connect, and New (see Figure 1). These commands covered the primary tasks of Wireless Client users. We initially wanted to provide quicker access to active connection status information through the tap of a single command button on the main form; however, due to space limitations, we placed this command on a menu instead.

The number of menus that can be placed on the menu bar is also limited by the number of characters in the menus' names. This means that, realistically, a maximum of four menus can be provided. Usually, applications offer no more than three. Of the menus provided in each Palm OS application, it is customary to include an Edit menu with the standard commands of Undo, Cut, Copy, Paste, Select All, Keyboard (which displays a dialog with a graphical representation of a QWERTY keyboard to enable non-graffiti text entry), and Graffiti Help. Therefore in practice, a Palm OS application can include only two or three menus with commands specific to the application's purpose.

To assist us in designing an intuitive menu structure, we asked users (Palm OS experience was not required) to individually categorize descriptions of menu commands that would be included in the final version of the client. The users grouped these descriptions (written on note cards) based on whatever categories they felt were appropriate; however, they were only allowed to create two or three categories. Users were also asked to give a name to each of the categories they produced. After this, we performed a statistical technique called cluster analysis on the resulting categorization data. This technique revealed the optimal grouping of the menu commands -- there were two -- and we used the suggestions of the users to assist us in titling the menus -- Connection and Status (in addition to the standard Edit menu). (Refer to Figure 2 to view the menu bar.)

For each connection created, the wireless client requires either the host name or the dotted decimal IP address of the wireless gateway to which the user will connect. If the user specifies a host name, the information in the input field may exceed the limits of a single line. To handle this potential problem, the development team had to design a method to accept and display a long gateway address. Our solution was to add an additional line to the entry field, which would break the address into two pieces, allowing the user to view the entire address on the main form. An alternative implementation that we entertained was to keep the entire address intact on a single line, but require the user to horizontally scroll to view all characters in the address, but not in its entirety. We decided against this because the behavior was uncommon compared to other Palm OS applications and because the user could read the address more conveniently and easily across multiple lines. (Refer to the Gateway field in Figure 5 for an example of a multi-line entry field.)

Space limitations also required the development team to give careful consideration to the particular labels for the input fields and even to the wireless client icon that appears in the application launcher. Most often, compound labels were shortened to a single word with the most meaning, such as "Gateway" instead of "Wireless Gateway" for the Gateway address. The application icon title was shortened from the obviously-too-long "IBM Wireless Client for Palm OS" to "Wireless" in an attempt to leverage the most cogent aspect of the software to the group we expected to use the product. The term "Client" was considered to be too esoteric for non-technical users (and possibly too generic for technical users).

Limitations in integrated user assistance
Integrated user assistance has a different look on Palm OS. Due to space constraints, only limited task descriptions, aids, and directions can be included for panels and dialogs. However, software for the Palm OS should be so easy to learn that detailed user assistance is unnecessary. In fact, most Palm OS applications do not have a centralized help system that is accessible from the menu bar. Furthermore, the Palm OS environment provides limited support for interface annotation. Users will not receive the common aids they may often rely upon with a desktop platform: task description information on panels, units of measure for fields, flyover help, and dynamic information display areas on panels.

User assistance is usually available for application dialog boxes and is context-specific to that dialog box. When assistance is available, it is not accessed by a command button on the dialog but by tapping a small circled "i" image in the righthand corner of the dialog title bar, as shown in Figure 7. (Incidentally, user assistance may not be implemented on the main form of an application.) Our usability testing demonstrated that users do not always remember to use that feature when it is available, so relying on detailed user assistance to counter poor interface design is not recommended. User assistance information appears in a modal dialog entitled Tips, and the content is intended to be just that. In fact, in the code, Tip text is defined as a string resource and string resources can be a maximum of 32,767 characters. Similarly, text limitations are also applied to the amount of information that can be presented in alerts (messages): Developers are restricted to using 256 characters to inform users about possible error states. Fortunately, we never ran into this limit -- the longest alert for the Palm OS client is approximately 150 characters.

However, despite what we've just said about user assistance in the Palm OS environment, our development team did not feel comfortable omitting Tips for the Wireless Client main form. Our discomfort resulted primarily from the need to shorten the input field labels on the panel and to further elaborate upon the different settings for the password field. Our feelings were reinforced by feedback from participants in the usability evaluations. To provide assistance here, we had to bypass the Palm OS limitation on accessing help from the circled "i" image in the title bar of the main form (actually, the main form title bar does not extend to the right corner of the display area -- only as far as the name of the application). So, we added a Help command to a menu. When activated, this command displayed a short description of each of the input fields on the main form with other helpful information regarding the wireless client. In this instance, we did not strictly adhere to the standard practice for the Palm OS, but the old salvo "Better safe than sorry" carried us to our decision.

Final thoughts
We found many important differences between the user interfaces of the Windows and Palm OS platforms and the challenges in adapting an existing Windows user interface model to the Palm OS user interface model. However, our purpose here was not to give the impression that the process was onerous or frustrating. In fact, it was quite the opposite. Our development team enjoyed creating solutions to the novel problems and puzzles presented by this unique (at least to us) project.

In this document, we frequently use terms like "limitations" and "constraints" when comparing the Palm OS user interface to that of the desktop Windows platforms. The unfortunate negative connotations associated with these terms should be counterbalanced with a reminder that the Palm OS "limitations" described herein also carry with them positive associations such as "mobility," "efficiency," and "immediacy."

An appropriate analogy might involve the comparison of living in two different environments -- a large suburban home or a recreational vehicle. While the former offers spaciousness, conveniences, and many opportunities for customization, the latter allows for freedom of movement within an environment of limited space and (for the most part) bare necessities. One is not intrinsically better than the other; each has simply been optimized to meet its primary purpose.

Resources

• Part 1 of Designing a Palm user interface takes a look at how two Palm OS features -- non-object-oriented graphical user interface and modal applications -- affect the process of porting an application from Windows to the Palm.
  
  
• Palm OS Developer Documentation Web site provides additional resources -- including tutorials and specifications -- related to the platform.
  
  
• The Palm OS SDK HTML Documentation covers versions up to and including 4.0.
  
  
• Palm also offers a Development Support site that includes source code, licensee information, and an FAQ.
  
  
• Palm OS Web site includes a resource for developers with a 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.
  
  
• IBM's WebSphere Everyplace Suite software development kit can be used to create and test wireless applications.
  
  
• For more on accessibility issues, visit IBM's Accessibility Center, which is designed to provide people with disabilities greater access to information and technology.
  
  
• For coverage of a broad range of wireless issues, you'll definitely want to pay a visit to the Wireless zone here on developerWorks.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Web architecture >