Applied Language Technologies
marx@altech.com
CHI '97 Workshop: Speech User Interface
Design Challenges
Candace Kamm [KAMM] identifies three qualities that vary among users: expectations, experience, and preference. Certainly much overlap exists between the three, but for the sake of scope this paper will concern itself primarily with preference. Now, "preference" can be a slippery concept, though the work of Cliff Nass and Byron Reeves [NASS] lends it some tangibility. The chief tenet of their work is that people's social reactions to computers are exactly the same as their social reactions to other people. And although the bulk Nass' and Reeves' research involved visual computing systems, the familiarity of spoken language interaction suggests that their findings may be equally applicable to speech applications, if not more so. Just as people tend to befriend those who resemble themselves, study after study of theirs reinforces the finding that people prefer interfaces with characteristics that resemble their own. Among these characteristics is personality type, usually expressed as "dominant" or "submissive." Those with dominant personality types prefer quick, get-the-job-done interfaces whereas submissive personalities favor systems that are forgiving, give help, and do not rush them.
At ALTech, we have seen this issue repeatedly with our demonstrations. I'll describe a demo that has existed in two incarnations, one more "dominant" and one more "submissive." Our experience suggests that no one style-even a compromise between styles-can please all of the people all of the time.
The "name and address" demo was one of the first for ALTech. Originally built by speech scientists (not UI designers), it was intended to deliver an impressive technology demonstration. Anyone in the national White Pages database of 80,000,000 households could be identified conclusively by the system after answering a series of questions. The interactional style was very terse, almost minimalistic: prompts were brief, reprompts were absent, anthropomorphization was entirely avoided. Here is a sample session:
Computer: Please give the following information. Zip code.
User: Two one seven eight four.
Computer: City.
User: Sykesville.
Computer: Was that Rockville, Maryland?
User: No.
Computer: Phone number, including area code.
User: Area code four one oh seven nine five five two three oh.
Computer: Last name.
User: Marx.
Computer: Street address.
User: 4402 Carroll Park Court.
Computer: Is this Marx at 4402 Carroll Park Court in Sykesville?
User: Yes.
Computer: Okay. Try again?
Users' impression of the technical achievement aside, reaction to the style of the name and address demo was mixed between those who appreciated its telegraphic interaction (especially those who had to demo it week after week) and those who found it impersonal. Neither user group was right or wrong; preferences simply differed.
The name and address demo was given a fresh coat of paint with a "friendlier" interface. The demo was framed around a catalog-ordering scenario; prompts were lengthened; retries were introduced. The resulting callflow was the following:
Computer: Thank you for calling 1-800-4-WINTER. To send you
a copy of our Winter Outerwear Catalog, we need to
get some information about you. First of all, please
say your five-digit zip code.
User: Two one seven-uh-um-eight-uh-five-no, four six one
three five.
Computer: Sorry, I didn't understand. Please say your
five-digit zip code again. Even if you have a
nine-digit zip code, please say only the first five
digits.
User: Two one seven eight four.
Computer: Next, please say the city where you live.
User: Sykesville, Maryland.
Computer: Was that Rockville, Maryland?
User: No.
Computer: Don't worry, I'll figure it out. Please tell me your
phone number including area code.
User: Area code four one oh seven nine five five two three oh.
Computer: Next, I need to know your last name.
User: Marx.
Computer: Finally, please say me your street address.
User: 4402 Carroll Park Court.
Computer: Is this the Marx residence at 4402 Carroll Park
Court in Sykesville?
User: Yes.
Computer: Terrific! Your catalog should arrive in four to six
weeks. Thanks again for calling 1-800-4-Winter.
Not surprisingly, those who preferred the original interface scorned the new "frilly" dialogue with its wordy prompts, (over)generous retry counts, etc. Others preferred the informative, forgiving nature of the new version.
The point illustrated is that neither interface was "right." Different people with different personalities preferred different interfaces. Certainly the telegraphic interface could have been jazzed up slightly, or the wordy one trimmed somewhat, but the perceptions may have been very similar. Our experience, however, suggests that a better strategy (if achievable) would have been for the demo to adopt the style more amenable to the user during the call.
Fortunately, claims Crangle, spoken language systems are uniquely suited to dynamic self-customization [CRANGLE]. Whereas adapting a graphical interface may require an extensive redesign of windows, fonts, etc., a few simple modifications in the behavior of a speech system can profoundly change the user's perception of the aural landscape.
Now, this paper is not about how to match a speech interface to a user's personality or preferences; well-known techniques for doing so have existed in many systems. Among the parameters that can be varied to suit user preferences are these:
At this point it is useful to distinguish between "private," or subscription-based speech applications and "public" systems. In the former, the caller's identity is established through a login process at the beginning of the call. Applications involving personal data-messaging, banking, stock trading, etc.-can generally be categorized as "private." With a public system, however, the application does not know the caller's identity. Applications that provide weather, stock quotes, horoscopes, movie listings, or that act as auto attendants are usually "public." Further, applications whose major purpose is to identify someone, such as a name and address transcription application or order-status system, are effectively "public" systems since the application does not know the caller's identity until the application has mostly run its course.
Many "private" systems allow users to control adaptation by manually setting their preferences. MailCall [MARX] allowed the user to set the text-to-speech output rate and prompt length by editing a text file off-line. NewsTalk [HERMAN] allowed persistent, run-time modifications; e.g., it increased the text-to-speech output rate when the user said "talk faster" and preserved it across sessions.
Public systems, however, do not enjoy these luxuries. Since they do not know the caller's identity, they cannot offer user-specific off-line configuration of any sort. Further, any parameters configured during the session (e.g., "talk faster") cannot persist between sessions.
Ironically, it is in these public systems that adaptation may be most critical. The initial enrollment in a private system implies some amount of commitment, and so a subscriber may be patient for a few sessions even if the application is initially frustrating. A public system, however, may have only one chance to make a good impression; hence, matching its interface to the user's preferences/personality is even more critical to user acceptance. Since no offline configuration is possible, the application must either provide methods for the user to configure the system during the call or adapt automatically. And since user-initiated configuration cannot persist across sessions, having to continually re-set parameters may feel like having to readjust the seat every time you drive your car. Thus automatic adaptation is ideal for a "public" system.
To recapitulate, our design problem is the following: how does a "public" application (where the user's identity is not known) decide whether or when to adapt its style to suit the user? How does it tell whether a user has a dominant or submissive personality type, among other preferences? What sort of behavioral cues can we look for? Should we succeed in detecting said cues or traits, we will begin to develop a sense of timing in applying adaptation techniques to "public" applications, even customizing the interaction within a single session for users whose identity is not known.
HERMAN: J.Herman, "NewsTalk: A Speech Interface to News." MIT S.M. Thesis, 6/95.
CRANGLE: C.Crangle, "Conversational Access to On-Line Medical Information." Proceedings of AVIOS '96.
NASS: C.Nass, et. al., "Adaptive Agents and Personality Change: Complementarity versus similarity as forms of adaptation." In proceedings of CHI '96.
KAMM: C.Kamm, "User Interfaces for Voice Applications." In "Voice Communication Between Humans and Machines."