Kortum P. (ed.) HCI Beyond the GUI. Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces
Подождите немного. Документ загружается.
11.4.3 Selecting Appropriate User Interface
Modalities
Sometimes the choice of UI modality may be clear-cut, and sometimes further
analysis is necessary to ensure that the right tool is being used for the job. This
section provides some of the relative strengths and weaknesses of the UI modal-
ities (Table 11.2) that are typically used together to form MMUIs. Please see the
other chapters of the book and the references at the end of this chapter for a more
exhaustive list of the strengths and weaknesses of the various UI modalities.
There are other strengths and weaknesses associated with each modality, but
Table 11.2 should provide a good starting point for the trade-offs involved when
deciding which are appropriate for a particular application.
11.4.4 Task Allocation to Multiple Modalities
Once the appropriate UI modalities have been selected for the application, the
next step is to assign which tasks will be performed with which modality. Just
as human factors have traditionally performed function allocation (see Wright,
Dearden, & Fields, 2000; Kantowitz & Sorkin, 1987) for the human operator and
machines, task allocation among the selected UI modalities needs to be
TABLE 11.1
Cont’d
Evaluation Question Explanation Example
Are the users so diverse so as to
warrant multiple modalities?
Some applications are narrowly
focused with what they do and
so their users tend to be almost
as narrowly focused. However,
other applications have broad
appeal and their users are
diverse.
An address book is used by some
people only in conjunction
with sending e-mails to a close
circle of family and friends.
Others use their address book
to keep track of all business
acquaintances, including
multiple phone numbers,
e-mail addresses, street
addresses, personal details,
and so forth.
Do the capabilities and
limitations of the users preclude
using any modality?
Will users with disabilities, either
inherent or based on their
situation, have trouble using
one or more of the modalities?
If so, are the other modalities
accessible to them?
Someone with hand tremors or
someone who is driving can
interact using speech rather
than pressing keys on a phone
to check messages.
11 Multimode Interfaces: Two or More Interfaces
372
performed. This allocation should be based on the needs and tasks of the users,
the reasons behind selecting multiple modalities, and the strengths and weak-
nesses of those modalities to fulfill the needs of the users.
In most cases, all tasks will be assigned to each of the UI modalities. The
most important benefit of this practice is that users have full choice of which
modality they can use for any task that the application can perform. This ca n
be very important for universal design objectives. It al so eliminates the need
for users to remember whether a specific function is supported within the cur-
rent UI and avoids the accompanying c onfusion that arises if a user is in the mid-
dle of a task and then realizes that he needs to stop and switch modalities. An
illustration of this might b e a bill payment application that allows payment with
a credit card, debit card, checking account, or gift card. If both a touch-tone IVR
and a website permit a ll forms of payment, the user is free to choose to call or go
online to pay a bill. However, if the IVR cannot accept gift cards, then the user
TABLE 11.2 Strengths and Weaknesses of UI Modalities
User Interface Strengths Weaknesses
GUI/Web Uses the high-bandwidth visual
channel with a large screen.
Usually not time dependent.
Can provide multimedia interaction.
Hardware associated with these UIs usually is
not easily portable.
Usually requires vision and manual dexterity
for the user to interact with it, unless
designed with accessibility in mind.
Small-screen
devices
Easily portable.
Typically enabled for audio input and
output.
Limited screen real estate to work with.
Input methods are usually more difficult.
Small size makes it difficult to see and
manipulate.
Touch-tone
IVR
Recognition of user input is nearly
perfect.
Not susceptible to background noise
(Paterno, 2004).
Lends itself to simplified menu
choices and linear tasks (Lee &
Lai, 2005).
Input options are constrained and have to be
mapped to arbitrary numbers.
Entering characters other than numerals is
difficult.
Contexts of use or disability can prevent the
use of hands for input.
Speech-enabled
IVR
A natural means of communication
for most users (Cohen et al., 2005).
Better at performing nonlinear tasks
(Lee & Lai, 2005).
“Hands-free” and good for when the
visual channel is overloaded
(Paterno, 2004).
Recognition of user input is not 100%.
Susceptible to noisy environments (Cohen,
Giangola, & Balogh, 2005).
Not all users can produce recognizable
speech.
11.4 Human Factors Design of the Interface
373
may call, enter his account number, the amount he would like to pay, and only
then find out that t he gift card he wanted to use will not work and he must hang
up an d visit the Web.
Although there are many advantages to implementing all functions in all of the
UIs, this strategy is often costly. In addition, there are tasks that may not be appropri-
ate for every UI modality. Furthermore, including all features from GUIs and websites
(i.e., high information-processing bandwidth modalities [Wickens, 1992]) into small-
screen devices or IVRs that use audio (i.e., lower information-processing modes)
may result in user overload in the latter. Figure 11.3(a) and (b) (on page 367) illustrate
this point. While the weather map for the full website has controls to add or remove
numerous features, the weather map for mobile devices picked only those that are
needed for the essential task and removed the customization controls.
Whatever the choice, it must be made during the early stages of analysis and
design and then tested for validation as a workable solution.
11.4.5 Perform Detailed Design, Test,
and Iterate Design
The last steps in the design process for MMUIs are not much different than in any
other user-centered design process. The inputs from the previous human factors
activities provide the basis for detailed UI design, the design must be tested with
representative users, and the design iterated based on user input. While the steps
may be the same, considerable effort must be devoted to these steps.
One special consideration during the design process for MMUIs is that, to the
extent possible, all UIs should be designed at the same time. Doing this helps to
ensure that there is consistency among the UIs from the very beginning. Each
design “should take into account the specific capabilities and constraints of
the device while maintaining cross-platform consistency and universal usability”
(Seffah, Forbrig, & Javahery, 2004). In addition, the learning process that occurs
while designing task flows for one UI can be transferred to the other UIs. Concur-
rent design also helps to ensure that the user needs supported by one UI do not
marginalize the needs supported by the other UIs. If this cannot be done, then
the predominant UI should be designed first. The predominant UI can be deter-
mined based on which UI will support the highest-frequency tasks and any other
tasks that are critical to the success of the application (e.g., setup).
While performing concurrent design, Seffah, Forbrig, and Javahery (2004)
proposed the following usability factors specific to MMUIs:
F Various interaction styles among UIs
F Information scalability/adaptability to various devices and UIs
F Task structure adaptability
F Consistent application behavior
11 Multimode Interfaces: Two or More Interfaces
374
F User awareness of trade-offs due to technical capabilities and constraints
F Application availability
F Overall “inter-usability”
The last point is one Seffah, Forbrig, and Javahery (2004) defined as “horizontal
usability.” Either name is suitable, but the key point is that it is a dimension spe-
cific to MMUIs. It is important to understand that while the usability of the UIs
may be sufficient separately, to truly know the usability of an MMUI, all UIs must
be assessed together to determine their integrated user friendliness.
Another special consideration for MMUIs is that all the UIs should be jointly
user-tested. For these studies, exposing all participants to all of the designs provides
the most flexibility, allowing the same participant to make direct comparisons
among the various UIs being tested. This also allows the designer to see which UI,
if any, is initially picked by the users or to see if users will spontaneously abandon
one of the UIs for another when completing tasks.
Beyond the usual benefits of user testing (Hix & Hartson, 1993), concurrently
testing the UIs helps in several ways. It can be used to validate the task allocation
that was performed, either by evaluating whether the same task in all UIs can be
accomplished or whether the choice to allocate a task to only one UI is appropriate
or too limiting. Depending on the reason for needing more than one UI, joint test-
ing provides realistic scenarios for participants. In many cases, user preferences
for accomplishing tasks with particular UIs can be very helpful when considering
application defaults and further understanding user behavior.
Finally, just as concurrently designing the UIs offers one the ability to learn
from the experience with one modality and apply lessons to the other modalities,
the same is true for the data collected during user testing. Having participants per-
form the same task in all of the modalities allows one to observe inconsistencies in
the design, as well as the strengths and weaknesses of the UI modalities themselves.
11.4.6 A Special Case: Adding a Modality
to an Existing Application
Sometimes the design process for a multimode application does not start from the
beginning. There are times when an application has already been developed that
uses one modality, but where a decision has been made to add another mode of
interaction. As mentioned before, the decision may be based on a misguided belief
that because another UI can be done, it is a good idea to do it. Other times the
reasons for adding another UI are based on the types of data mentioned in the pre-
vious section: users’ needs, their contexts of use, and/or the environments in
which they are currently using the application.
One of the opportunities in this situation that may not be as available when
designing from scra tch is that the u sers, their contexts of use, and tasks are
11.4 Human Factors Design of the Interface
375
already available for study. At some point after deployment of an application, stud-
ies of the application may uncover significant gaps in its usefulness to the users or
its usability. Analyzing how to address these problems may show that iterative
improvements to the original UI are sufficient. Other times, however, the original
modality may not be the best choice for the best solutions and the selection of
another modality is appropriate. But as with designing all the modalities initially,
the decision to use another modality—and which one to use—should be based on
data about the users, what they need, and how they perform their tasks.
Task allocation among modalities for an MMUI designed from the beginning is
somewhat different than when adding another modality to an existing application.
The crux of the difference is that one of the UIs has already been designed and thus
has already been allocated its tasks. The principal design problem for the new UI is
determining what other tasks should be included in the new UI. There is no definite
answer, but time and cost considerations usually mean that only the tasks that
would make the necessary improvements to the original application are included
in the new modality. In addition, tasks allocated to the original UI could be added
or removed, but usually not at this point. Alternatively, a complete task allocation
can be performed, treating the inclusion of a new UI as a chance to perform a com-
plete redesign. This is usually more time consuming and costly, but sometimes a
thorough redesign is needed to achieve the desired improvements.
The other major difference between developing an MMU I from scratch and
adding another modality after application deployment is that joint design is not
possible. In this case, the new UI should be designed in light of the existing
modality, understanding that the original UI probably will not fundamentally
change but also recognizing that many users are accustomed t o the existing
interface an d that any changes to that interfa ce are likely to have negative
consequences.
Joint testing of the original and new UIs should take place in the same way as
for a totally new application, but with one caveat: Both existing users and new
users with no knowledge of the application should be participants in these studies.
Perspectives of both user groups are very important because while it is important that
current customers are not alienated by the new design, it is also crucial that new users
are attracted to the improved application. When testing current users, pay attention to
any negative transfer to the new UI from their experiences with the existing one,
especially regarding consistency. With users who have no knowledge of the applica-
tion—new or old—concentrate on whether the addition of the new UI meets the
requirements that were established for adding the new modality.
This early testing should be designed to decide whether the task allocation is
correct, especially if the minimalist approach was taken due to time and cost.
Moreover, it will also point out whether the original UI needs to be significantly
changed to accommodate the new modality. Finally, as is the case with designing
from scratch, this testing, redesign, and retesting should continue until a satisfac-
tory design has been achieved.
11 Multimode Interfaces: Two or More Interfaces
376
11.4.7 Summary of Design Steps for Multimode
User Interfaces
Steps for analyzing and designing multiple UI modalities are
1. Define the user population, including people with disabilities.
2. Determine capabilities and limitations of users.
3. Collect user needs, including specific contexts of use and environments.
4. Match user needs with system functionality.
5. Perform task analysis.
6. Evaluate the need for more than one UI.
7. Select the specific interface modality(s) based on strengths and weaknesses of
each.
8. Assign tasks/functionality to all modalities or only some of them.
9. Concurrently perform the detailed design of the UIs.
10. Test with representative users, collecting data about usability/accessibility for
tasks and modalities.
11. Iterate design and retest as needed.
11.5
TECHNIQUES FOR TESTING THE INTERFACE
Because this chapter does not discuss a unique interface but rather a combination
of interfaces, the testing techniques described here will focus on testing an appli-
cation that uses multiple UIs and how to test whether the correct UIs are being
used rather than how to test a particular modality. See other chapters in this book
for a discussion of non-GUI/Web testing techniques, or the references at the end
of this chapter for discussions of testing GUI/Web UIs.
When evaluating MMUIs, many of the standard usability evaluation techni-
ques are used. Early testing will generally be done with prototypes of the applica-
tion and fewer participants; the focus is on finding ways to make the UI designs
better. Later testing will generally be with a fully developed application and have
more participants; the goal here will be to iron out details and begin to predict
overall user performance. In both cases, comparative techniques are especially
important. As with any application, the most important testing is that done early
and iteratively, with representative users.
11.5.1 Early Testing
The primary goals of early testing are to validate the choice of modalities and any
task allocation that has been done. The first round of testing ideally should be con-
ducted while the detailed UI design process is under way. At this stage, testing
11.5 Techniques for Testing the Interface
377
with throwaway (or “exploratory”) prototypes is best because they can be built and
changed quickly, even during testing. For visual interfaces, these prototypes are
usually “wireframes” or simple clickable prototypes created in HTML or rapid pro-
totyping languages. For speech recognition systems, a Wizard of Oz technique can
be very useful for creating quick mock-ups of early designs (Cohen, Giangola, &
Balogh, 2005). (See also Chapter 6.) In this same way, even touch-tone IVRs can
be prototyped (i.e., by having the caller say the key they want to press).
The essential theme for this testing is that the earlier representative users
have a chance to provide meaningful, valid input into the development process.
The closer these early interfaces resemble the target UI design, the greater the
likelihood that the product will be designed with fewer iterations. This is espe-
cially important for MMUIs because with multiple UIs, any one UI will likely
get fewer resources to make changes than if it were a stand-alone application.
In addition, MMUIs typically have a more complex support infrastructure, whose
own design cannot change easily.
Because fine details are not important at this stage, a small sample size of rep-
resentative users is appropriate. The test should expose all of the participants to
each of the design alternatives so direct comparisons can be made. The tasks for
participants should be selected to focus on the ones most relevant to the ongoing
detailed design, which include the following:
F Most frequently performed
F Most critical to the overall success of the application
F Most fully explore the choice of a particular modality
F Specifically allocated to only one of the UIs
F Most likely to use more than one modality at a time or consecutively
Testing the most frequent and critical tasks is common in usability testing and
will not be discussed here (Hix & Hartson, 1993). When testing MMUIs, the goal
should be to choose a sample of tasks that allows the experimenter to observe
the behavior with each of the UI modalities. Not only does this provide perfor-
mance data for the tasks, but it also provides the opportunity to get a better sense
of what does and does not work for that modality in the application, as well as a
chance to ask participants which modality they preferred and why.
Tasks that have been allocated to only one modality, especially if those are
tasks that can only be performed using that modality, should be thoroughly tested.
These tasks are included because there is no alternative modality in the applica-
tion for them and therefore they absolutely must work in the chosen modality.
If not, one or more of the other modalities needs to be considered for the task.
Tasks that require using more than one modality at a time or consecutively
may or may not be relevant to a particular application. Sometimes there are
tasks that may require a user to interact with more than one modality at the
same time (e.g., registering a small-screen device wi th the application while
11 Multimode Interfaces: Two or More Interfaces
378
logged in to a GUI/Web UI) or consecutively (e.g., once setup using a telephone
UI reaches a lo gical end point, the user may be required to use the Web to fi nish
the installation). If t his is the case, then these tasks should be tested early with
the best prototypes avail able (even if t he study parti cipants are asked to “make
believe” about some things) because these tasks can be very complex and the
transition between modalities may not be clear. It is important to determine
whether the interactions in both modalities are consistent wi th users’ expecta-
tions and that the UIs in both modalities are consistent and meet the require-
ments for good usability. If this is not the case, then one or both interfaces
mayneedtoberedesigned,andthisshouldbedoneasearlyinthedesignpro-
cess as possible.
Based on the results of early testing, it is important to apply the results to the
ongoing design process. Adding, changing, or removing functionality may be
required, as well as revising the UI designs. At this point, even starting over and
trying a new approach may be appropriate.
11.5.2 Later Testing
After early testing has helped shape the designs of the UIs, a workable design
should be ready to be built. Testing on a semi-functioning system—either an evo-
lutionary prototype or an early alpha version of the application—should take place
as soon as possible. When this system is ready, the next major round of testing
should take place.
There are two major goals for this round of testing: validating the UI designs
that were based on early user testing and testing tasks that could not be easily or
accurately tested with lower-fidelity prototypes. Again, standard usability techni-
ques are used, although more participants are probably warranted here as the
need grows to become more confident with the results.
The same type of tasks that were used in early testing are still applicable,
especially the high-frequency and critical tasks. Tasks for exploring a modality
and those assigned to a single modality are less critical because that part of the
design needs to be mostly settled at this point but still should be validated.
Some of the new tasks important in this round of testing include
F Tasks that are heavily dependent on back-end systems or other dependencies
that made them difficult or unreliable to evaluate in early testing
F Tasks that can be performed on more than one UI
The former is for tasks that could not adequately be captured in early testing with
lower-fidelity prototypes. In many cases with MMUIs, the user interaction is
heavily dependent on integrated systems and/or dynamic data that cannot always
be sufficiently replicated in early testing. This is the time to test users with those
tasks.
11.5 Techniques for Testing the Interface
379
This is also where in the testing process to determine the relative perfor-
mance of the same task with multiple UIs. This can be important when assessing
the relative strengths and weaknesses of the various UIs of the application, for
setting application defaults, and for projecting usage patterns.
A test during which all participants experience all of the experimental options is
still appropriate at this point. This time the direct comparisons are usually made
between performance on the same task with different modalities, although if alterna-
tive designs are available at this stage, a comparative evaluation is also useful. How-
ever, if there are numerous tasks with several UIs, a test in which various groups of
participants perform diverse tasks with different modalities may be the only practical
experimental design at this point. With multiple UI modalities to be factored in, the
test size can quickly grow out of hand when all participants do all of the tasks.
Up to this point the user testing could be done just about anywhere because
the focus was on validating the fundamentals of the UI designs. But often the
needs and tasks of the users that drove the need for multiple UI modalities are
unusual and/or varied. In these cases a more naturalistic setting may be neces-
sary. The context of use and the environments in which the users are expected
to use the application need to be considered as part of the testing methodology.
For example, if a UI for a small-screen device is part of the application because
of a strong need for mobility/ubiquity, then some of the testing should be con-
ducted in an environment that replicates the expected uses that originally
required the use of multiple UIs.
11.5.3 Inclusion of People with Disabilities
in User Testing
During all phases of design and testing the inclusion of the needs and input of peo-
ple with disabilities is important. Overlooking this part of design and testing is
often accompanied by the excuse of trying to get most of the UI right for nondis-
abled users, with the promise of making the necessary adjustments to accommo-
date the disabled user later. This belief is even less true with MMUIs because
the multiple modes often are a boon to people with disabilities. Moreover, MMUIs
tend to be used more often in diverse contexts of use and environments, creating
situations that are functionally equivalent to a disability (e.g., not being able to
hear because of a noisy environment).
People with disabilities not only provide feedback during testing about
acc essibility features, but frequently are more susceptible to marginal de signs
and c an uncover usability prob lems that would n ot necessarily be uncovered
with a small sample size. As such, i t is valuable to consider these needs
during design, but it is also important to understand that the improvements to
the design resulting from user testing with this group improve the overall user-
centered process.
11 Multimode Interfaces: Two or More Interfaces
380
11.6
DESIGN GUIDELINES
Multimode UIs are extremely varied. Because they are composed of more than one
UI, they are generally more complex and yet have all of the same issues as their
component UIs. The sum can be greater than its individual parts, but only if done
right.
Although there is no recipe for how to design a good MMUI, this section lists
and describes selected guidelines on ways to improve the chance for creating a
useful, usable, and accessible one.
11.6.1 Only Choose MMUIs If There Is a Compelling,
Real, and Beneficial Need
Having multiple UI modalities for the same application makes almost everything
about the design and development more difficult, complex, and costly. And if the
UI designer is not careful, this burden can be transferred to the users. The goal of
design is to let the users benefit from the choice of multiple UI modalities, but
not let them suffer because of it. To do that, first be judicious about the decision to
use multiple UI modalities and about which are chosen. If the data support the need
to have an MMUI (i.e., based on the user population and analysis of their needs and
contexts of use) is strong enough, then the UI design should follow that course.
Example:
A diverse user population, including individuals with vision and
hearing loss, need to be able to find out the showtimes for numerous
movies at multiple theaters, whether they are at home, work, or in the
car. Based on these varied users and contexts of use, web and speech rec-
ognition IVR UIs are selected.
11.6.2 Choose Modalities Whose Strengths and
Weaknesses Match the Needs and Tasks
of the Intended User Population
The entire purpose of having more than one UI modality for an application is to
take advantage of the capabilities that multiple modalities provide. Consequently,
users’ needs and the tasks they perform that cannot adequately be handled by one
modality must be assigned to a modality whose capabilities are a good fit.
Example:
For a movie showtimes application, a speech recognition IVR is
chosen over touch-tone because there are numerous movie names, so
saying the name of the movie is much easier than selecting from multiple
hierarchical menus.
11.6 Design Guidelines
381