|
|
Pete Lockhart
Beta Base, Inc.
805 SE 101st Avenue
Vancouver, WA 98664-4133
+1 360 892 2991
pete@teleport.com
Tony Salvador
Intel Corporation
JF3-210, 5200 NE Elam Young Parkway
Hillsboro, OR 97124
+1 503-264-6455
tony_salvador@ccm.jf.intel.com
James Newbery
University of Nottingham
Department of Psychology
Nottingham, UK NG7 1NG
+44 115 959 9215
lpyijn@psychology.nottingham.ac.uk
This paper describes the efforts involved in the design of a novel Personal Information Manager (PIM) about the size of a credit card with a touch screen that fit neatly in one's shirt pocket or the PCMCIA slot on a PC. The device had to support both viewing data as well as entering data. This project at Intel offered human factors engineers extraordinary freedom in terms of functional design constraints, including no pre-existing operating system or pre-existing metaphor. However, in terms of practical constraints, such as low power demands, extremely small screen size and low resolution, color and the inexperience of the engineering team working with human factors professionals, this project offered us a unique challenge. In the end, ergonomic concerns, functionality concerns and navigation issues required a novel approach to the design of this hand-held computing appliance. Making decisions was additionally complicated as the novel hardware was being developed simultaneously. During design, we needed to produce innovative tests that would give valid results without using the actual hardware and we needed to explain at each step what we were doing and the input we would have for hardware and/or software decisions.
design, usability testing, user requirements, ergonomics, hand held, mobile computing
A product team from the Mobile and Home Architecture
Lab at Intel had been formed to develop a handheld
Personal Information Manager (PIM) that would give the user access to information while traveling but would also integrate with a desktop PIM. At the time the human factors team was invited to this project, some initial thoughts about the goals and use of this mobile PIM device (we'll refer to it as MPIM) were already in place. Some of the goals for the product were:
Some focus group research had already been done and
the calculator and clock functionality was rated as lower in importance
by focus group participants. Data synchronization, touch screens,
power management and recharging, were rated as important by the
users. While most data entry would be accomplished on the desktop,
users felt they also needed the capability of entering small amounts
of data while on the road, including notes attached to calendar
entries or phone book entries.
The hardware was to consist of a PCMCIA (Personal
Computer Memory Card International Association) card with a touch
screen. The screen was the user interface for viewing and inputting
information while mobile. Upon returning to the office, the user
would simply insert the PCMCIA card into the appropriate slot
on the desktop machine and the data on the MPIM would be automatically
integrated into the desktop PIM and vice versa.
As usual, we had only a very short time frame especially
when compared to the number of issues that we needed to explore.
We were first brought on board in August and we need to have a
design completed, implemented and validated through a planned
-- and rather large scale user test -- by the end of January.
Along with the short schedule went a small budget, especially
for user testing.
The physical size allocated to the user interface
was another challenge. The display area was approximately 2 5/8
inches by 1 3/4 inches, and the best resolution we could expect
was 240 x 160 pixels. In this space we needed to display the functionality
of the MPIM and to allow the user to do limited input. A touchscreen
was being planned for access.
Another challenge we faced was that of selecting
a design and testing it without having the actual hardware
in place. At the time we started the work, we anticipated that
the hardware would be available in the later phases of our work
but that actually turned out not to be the case.
Probably the most difficult challenge we faced was the actual process. None of the hardware or software engineers nor the manager of the group had worked with human factors engineers previously. So, in addition to doing our job, we needed time along the way to establish a viable working relationship with the group. As our product involved both hardware and software, and the engineering constraints were rather stringent, the entire team, including us, needed to understand all the implications that one decision would have on issues. Several of us in the human factors group were working on a new way to collect and structure user input for use in requirements and design work (Salvador and Scholtz, 1996). This project was small enough in functionality that it was a perfect testbed for using this process. So, to add to our challenges, we were using a requirements process that we were still developing.
One human factors person, an intern, was actually
assigned to the project full time. But due to the interesting
nature of the work three other human factors engineers volunteered
some time initially. One of these devoted some time throughout
the rest of the project to oversee the work of the intern. In
addition, there was a GUI designer assigned to the task who was
very aware of and sympathetic to human factors issues.
Some initial market research had been conducted using
focus group techniques to determine the likelihood of purchasing
such a product and the benefits and barriers that users saw for
this product. While users liked the fact that MPIM would work
with existing software, solved the problem of data synchronization,
and was extremely portable, they were very concerned with the
ease of use due to the very small size of the display. Concerns
about data entry were also very important to users.
There were several aspects to our plan: literature
searches and review of existing PIM software, development of user
scenarios and creation of the Systematic Creativity requirements
data structures, preliminary design work, and then refinement
of the designs based on iterative usability testing.
We looked at several handheld and several desktop
PIMs. We found that all had calendar, appointment and to-do list
functionality. All except one included phone book functionality
and the ability to connect to mail. We also found that all handheld
PIMs had one touch application navigation. Several used the "files"
format, allowing the user to select the file they wished to view
and immediately navigate to this data. Additionally, applications
started from a display that allowed easy access to data entry
or editing. Upon completion of data entry, the display was updated
to show the user how the data looked.
During our evaluation of these existing programs
we found that simple navigation was extremely important. Of the
five products we looked at, the navigation in one was extremely
confusing and another contained confusing embedded contacts and
phone lists. We were also convinced that we needed to support
the majority of the functions: calendar, appointment, to-do lists,
phone book, and mail in order to be competitive. We needed the
product to work with existing software and to automatically synch
with desktop PIMs so we decided not to deal with support for mail.
This would add to the list of software that we needed to be compatible
with and would place too many demands on our tight development
schedule. Communication was a concern raised during initial focus
group research as several people asked if the product could connect
to a cell phone, be used as a modem, or be used as a pager. However,
the other functionality was considered of prime importance.
We also examined the literature on touch screens
and viable input controls. Given certain expected user scenarios,
e.g., making a phone call in an airport phone booth, we also looked
at research involving character size, contrast and viewing distance.
Furthermore, we excluded a stylus as an input device. We decided
that the touchscreen approach would indeed be feasible given certain
design constraints: First, we decided that using lift off activation
(Potter, Weldon, and Shneiderman, 1988) with the cursor being
displayed slightly above the user's finger sounded like the most
feasible approach. We also found that we needed to have characters
between 2.2 mm and 2.6 mm in size giving us a preferred viewing
distance of from 344 mm to 447 mm with maximum viewing distance
range of 473 mm to 559 mm.
We developed user scenarios to use for product vision and hence, product design. These scenarios included:
The user scenarios highlighted the use of cut and
paste facilities to transfer data between MPIM functionality.
For example, a user should be able to paste in a name and phone
number from his phone book to his calendar entry. The scenarios
also included quick access to data entry from all functionality,
calendar, appointments, phone book or notes.
We used our Systematic Creativity method, then under
development, to approach the issue of design. We took the user
scenarios and produced user goals and tasks. We then broke these
down into actions and objects that were needed to support the
task.
Consider the scenario where the user is on a trip visiting previous contacts and making new contacts. The user has the goal to maintain the accuracy, currency and completeness of the phone book on his MPIM. Tasks that support this goal would include:
Breaking down a task into actions and objects is
the next step. Suppose the user's goal is to have access to phone
numbers. A task that supports this is to find the phone number
of a particular person. Actions and objects for this task are:
| Action | Object | Performed by |
| open | phone book | user |
| find | name | user |
| find | phone number | user |
| close | phone book | user/MPIM |
We include an indication of who should perform the action: the
user or the system. In the above example, the "close"
action is performed jointly. The user gives an explicit command
to have the phone book closed, but the system then shuts down
the phone book and probably displays the main menu display.
For design considerations, we use the prioritization of the user
goals to determine the visibility of the tasks that support each
goal. We use the actions and objects necessary for each task as
the starting point for design. Once we have a reasonably complete
set of actions and objects we sort these in several ways: by action
to identify the objects upon which that action is done, and by
object to identify the actions that need to be accomplished. This
helps us to design metaphors and action techniques to maintain
consistency throughout the product.
Once we had the actions and objects determined from the user scenarios
we saw that we had many possible links among different applications
within the product. For example, the user might be looking at
his calendar, see that he is running late for his next meeting
with Mr. Jones-Smith and want to quickly call to say that he will
be arriving 10 minutes later than scheduled. In addition to risking
job security, that series of actions implied strongly that accessing
the phone book data directly from the name in the calendar would
be advantageous, rather than having to shut down the calendar,
open the phone book, find the name and locate the appropriate
number. This led us to produce two designs: a data centric design,
corresponding to the scenario just described and a more conventional,
program centric design. Figures 1 and 2 show sketches of screens
for both the data centric and program centric designs.
In figure 1, the user would select "contact" to get
information about a person. And then select the from the popup
menu, addresses, numbers, appointments, etc. to view the desired
data. The program centric design in figure 2 would present the
user with the programs to choose to view either appointments,
contact information, etc. The data would appear in larger chunks
but with no links between applications.
The data centric design relied on the data interactions themselves
to guide navigation and viewing. As another example, viewing a
data item in the calendar about a meeting with Bob would allow
the user to access Bob's phone number directly from the Bob data
item in the "calendar." Conversely, viewing an entry
in the phone book would also pull up dates on the calendar that
displayed appointments with that individual. To-do lists, appointments,
people, time were all directly accessible -- there was no prescribed
order, allowing maximum flexibility for navigation and data access
(and input). The strength of this design is its in-context navigation.
The design limitation of this approach is that it challenged user
expectations.
The program centric design provided access based on what we considered
to be the "historical artifact" tradition. Phone books,
address books, appointment calendars were considered separate
entities due to the paper medium on which they were produced.
PIMS have cleverly maintained these distinctions. To see an appointment,
the user would go to the calendar program. To see a phone number,
the user would go to the contacts program, etc. The major design
strength of this design was its analogue to history and what were
likely to be user expectations based on current PIM usage. Admittedly,
this is a strong point.
|
|
||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||
Obviously, we felt that using the data centric design
would enable users to navigate more quickly through the system
and would help ameliorate the display and input constraints of
the system. However, we were unable to convince the team that
this approach was the best one. Marketing had visions of eventually
using third party applications and the need for all applications
to interact together would make novel approach difficult, if not
impossible. The software team was more comfortable with using
an application centered approach. Due to the time that we had
to produce the prototype system, the application centered approach
once again was selected.
Nevertheless, in our detailed designs and testing,
we relied on the tasks, actions and objects to produce design
description for each screen in both the program centered approach
and the data centered approach. These descriptions consisted
of: a definition of what the screen accomplished, the visual elements
the user would see on the screen, the actions the user could perform
on this screen and the response that the system would produce
to each action. We also included all screens the user could access
from this particular one and the controls that would be needed
to support the actions on this screen. We included some example
screens to supplement the text descriptions. Figure 3 shows an
example of a screen definition complete with a sketch of how this
could appear.
We produced a test plan to address three sets of
issues: 1) ergonomic issues, e.g., user preferences for handling
and orientation, 2) touch screen controls, e.g., usability of
touch screen strategy, controls, and input and 3) navigation,
e.g., isolated control events and program centric v. data centric
navigation. In this section we present a summary of the tests
we ran, noting the questions that were to be answered, the answers
we obtained and a brief outline of the method or methods we used
in testing.
The main objective of this test was to examine users' natural orientation preferences in terms of: physical handling, input handling and reading handling. The following are activities we asked users to carry out with PCMCIA cards:
We gave users three different screens: a pie chart, a maze and a tic-tac-toe game. Each of the tasks that accompanied these screens asked the user a question that necessitated reading information from the screen. Note that the screens were designed to be used in either a portrait or landscape position.
Subjects preferred the portrait orientation over
the landscape orientation (72% to 38%). By a small margin, users
preferred to hold the PCMCIA card with the "ledge" at
the top (39% top as compared to 33% who preferred holding the
ledge at the bottom).
We identified four styles of access:
We found that users used the rodeo and game boy access
methods (that is, thumb access) 83% of the time. This was distributed
evenly across left handed and right handed selections. There was
no correlation between access style and orientation.
We were concerned about the use of the thumb for selecting and knew that accuracy was going to be an issue in our small display on the touch screen. So we devised a follow-up test that used smaller buttons that we felt were more likely to be representative of the size users would have to use on the display. We asked users to use the following four strategies and rate them as to comfort and how secure they felt the MPIM was.
The strategies were:
For comfort, we found a main effect of orientation
with portrait being higher than landscape. And we found a main
effect of style with hold and point being higher than rodeo but
there was no interaction. For security, that is how secure the
user felt relative to dropping the device, we found a main effect
only for style. Users felt more secure using the hold and point
style but the orientation did not affect security.
We also asked subjects to look at to do lists, phone
lists, and appointment list presented in both portrait and landscape
and give us a preference on orientation. Overall, users preferred
the landscape orientation for viewing as it allowed them to see
more of an entity as opposed to more entities.
We then asked the users to give us a preference based
on handling as well as on presentation. Users were willing to
sacrifice their landscape preferences for comfort and security
given by the portrait orientation. At this point, since we needed
to make a single selection, we decided to design the MPIM using
a portrait orientation with the hold and point access style.
We also did some testing to see whether input could be accomplished using a keypad on the touch screen and the form that this keypad should take (modified QWERTY, horizontal alphabetical, single alphanumeric, separate numeric and alpha keypads). We wanted to stay away from using a stylus device along with the MPIM as these are likely to get misplaced. We envisioned limited input while on the road, but input was important to our customers. We tested out the following type of alpha keypad layouts on a touch screen:
We also tested numeric keypad layouts: standard telephone
touchpad, numerically arranged, standard PC numerical keyboard.
We found that users indicated a preference for a single alphanumeric
pad saying that flipping between pads was awkward. Users felt
that errors might be higher for a single keypad with small buttons
but they were willing to make that tradeoff assuming that they
could delete an incorrect choice quickly. There was no clear cut
difference in performance on the alpha pads but users preferred
the modified QWERTY pad.
We ran a test to determine the button size that users could comfortably and accurately use. We determined that a minumum size would be 15 pixels wide by 12 pixels high with an activation area beginning one pixel below the bottom of the control and extending downward for 12 pixels.
Later in the design, we got access to the prototype of the actual touch screen itself. We used this prototype to see how accurately users could make selections and how quickly they grasped the concept of selection on liftoff. Test results gave a reasonable accuracy rate. This was encouraging but further testing was needed on the actual units. The unit that was used for testing was a large touch screen with the same pixel size as the intended final version. However, we used only a section of it, covering up the remaining portion. Unfortunately, subjects were required to bend over and use the unit which was placed on a table, rather than being able to hold it. Nonetheless, the liftoff strategy was shown to be easily learned and could used with a high degree of accuracy.
Figure 4: An example of portrait phone book given
to users
Several navigation tests were done. In the first, we had users walkthrough five different tasks using paper mockups. The interface we had mocked up for this test was a broad, flat hierarchy with many crosslinks between and within applications. We wanted to see if users could perform some common tasks and how these tasks would compare with those on their current PIMs. These tasks used in this test were:
We noted the path users took to do these tasks and
compared them to the optimal way the task should be done. For
example, to find a phone number, the optimal way was to select
the menu button. This brings up a menu from which the user selects
"contacts". Selecting contacts gives a popup menu from
which the user can select numbers, addresses, notes, preferences.
Selecting numbers brings up the address book display from which
the user selects the proper alphabetical category and scrolls
so that the correct name and number appear in the view port. Users
did well on this task: four out of five users were able to do
this successfully. The only hesitation was in scrolling to get
the selected entry in the view port in order to view the phone
number as well as the name. We considered adding an "expand"
item in the menu that appears on the locator screen.
The task of viewing today's appointments from the to do list was surprising to users. They expected to use a menu or go to button to get there indirectly. However, from the to do list, a button allowed the users to go directly to view appointments. With the exception of navigation between days (checking the availability for appointments two days from now), users felt that the tasks on MPIM were at least as fast or faster than in their current PIM.
Figure 5: An example of landscape phone book given
to users
Most users were not expecting to select the actual
"information" as they said. But once they were told
they could, they liked this way of navigation and felt that it
made perfect sense for touch screen use. Users also liked the
context sensitive menu and commented that it saved display space
and allowed them to do what they wanted with the information that
was being displayed.
In a later test we concentrated on input navigation.
That is, we tested tasks which required the user to navigate to
the correct section and input data. The four tasks used in this
case were: entering a new appointment, entering a series of quick
notes, allocating unassigned notes to the phone list application
and changing an existing address. We noted the steps users took
to accomplish these tasks and measured these against the "optimal"
way to accomplish the task.
Users had an overall correct response rate of 86%
which fell slightly below the 95% usability objective we had established.
The problems we identified included several instances of ambiguous
terminology which confused the users. Users also mentioned their
desire for a cut and paste facility among the various applications.
However, some users did not understand the hierarchical database
model and had trouble grasping the fact that record and label
fields were context sensitive. As these users were all current
PIMs users they may have been expecting a more traditional, deeper
hierarchy that most PIMs use. Our first test had shown that once
users grasped the strategy they were enthusiastic about it. And
as the optimal path was choosen the majority of the time,
we felt that we were on the right track for a prototype design.
From a human factors standpoint we felt that several
noteworthy points were made during this process. First of all,
this was one of the first times we were called in to work on a
prototype project, rather than a development project at Intel.
We were able to use our processes and to come up with innovative
testing to answer some basic issues without the use of the actual
hardware and in a very short time frame. We felt that by the end
of the project, the project team had a good understanding of what
we did and respected our input. On the downside, our major recommendation
that a data centric design made more sense than a program centric
design was not taken for business reasons. The question of orientation
and touch screen access consumed a large portion of our testing.
The team had just assumed that a landscape orientation would be
used to maximize the amount of information displayed. Therefore,
having them elect to go with the portrait orientation based on
our data was a major decision. Since this was a prototype rather
than a product, we did not worry as much about the finer design
details. Our concern was that users would be able to easily access
the functionality and that feedback from field testing would produce
results that would encourage the development of the actual product.
Although we were not involved in the field testing (due to a lack
of funding at this point), we had drafted a questionnaire to be
used for data collection.
Paul Sorenson was a contributing member of the early human factors work and we thank him for his efforts.
|
|
