Feedback in Database Inquiry Services
Angelien Sanderman and Vincent van Amerongen
KPN Research
V.R.vanAmerongen@research.kpn.com
CHI '97 Workshop: Speech User Interface
Design Challenges
Short Biography
Angelien Sanderman studied speech and language pathology and finished
her PhD thesis in the beginning of 1996, which concentrated on speech
synthesis. Vincent van Amerongen has a grade in psychology.
On this moment, both authors are human factor researchers at KPN
Research, the research institute of the number one Dutch
telecommunication company. At this institute, we develop and evaluate
new telecommunication services and devices from a human factors' point
of view. Of course, the use of speech technology in this area is an
important issue.
Position Paper
When one person talks to another, communication errors are inevitable.
When speaking to a speech recognition system, recognition errors are
much more frequent and error recovery is more difficult than it is with
humans. It is necessary that the user interfaces of these systems have a
mechanism that allows the user to detect and correct errors (Simpson et
al. 1987). This has implications for the style of feedback. First, it is
important that the user receives sufficient feedback, so that he/she is
able to see that an error has occurred. Second, the user should have the
possibility to correct the error on time, before it causes any trouble
(Nusbaum et al., 1995). The amount of feedback can also be varied.
Mountford et al. (1982) provided users with varying amounts of feedback
in an aircraft navigation data entry task; for example, in 'verbose'
mode, feedback followed each entry, while in 'succinct' mode, there was
no feedback after entries. Users preferred the succinct mode, even
though they felt it required more attention, because the verbose style
made the transactions too lengthy.
Question
The main issue of this position paper is the following question:
In database inquiry services, what are the boundaries in the trade-off
between:
(a) amount of explicit verification: the number of yes/no questions
in order to let the user confirm whether an item is recognized
successfully.
(b) number of turns: the total number of question/answer cycles
necessary to satisfy the user's request?
The OVR system
To discuss this problem, we want to focus on systems like the
OVR-system. The OVR system (Openbaar Vervoer Reisinformatie) is a Dutch
railway information service that advises users on railway connections
(comparable to the ATIS system for flight information).
The OVR-system is a dialogue system that contains basically speech
recognition, dialogue management and speech output. The output is spoken
by means of speech concatenation. At present, the speech recognition has
a performance level of about 80%.
To calculate an advice, the system has to receive the following data:
arrival station, arrival time, departure station and departure time.
The system has a default order of questions. However, the user can
shortcut some of the questions, because the OVR system can spot multiple
data items in one sentence. Also, the user can enter a data item, which
was not explicitly asked for, to influence the order of questions.
Illustration of the Trade-off Between Time, Turns and Verification
Thus, the system (technically) allows for a very efficient -but extreme-
dialogue style like this:
Dialogue A:
system: From where to where do you want to travel?
user: From Groningen to Den Haag.
system: When do you want to travel?
user: Saturday at 10 a.m.
system: I have found the following connection. Departure from Groningen
at 7.30, Arrival in Den Haag at 9.55.
However, the drawback of a dialogue like the one above is, that (a) it
increases the chance of recognition errors and (b) when a recognition
error occurred, errors can not be corrected as quickly as when data
items are entered one by one.
system: Where do you want to depart from?
user: From Groningen.
system: Do you want to depart from Groningen?
user: Yes.
system: Where do you want to go to?
user: Den Haag.
system: Do you want to go to Den Haag?
user: Yes.
system: What day do you want to travel?
user: Saturday.
system: You want to travel on Saturday?
user: Yes.
system: What time do you want to depart or arrive?
user: I want to leave around 7 o'clock.
system: You want to depart on 7 o'clock in Den Haag?
user: Yes.
system: I have found the next connection. Departure from Groningen at
7.30, Arrive in Den Haag at 9.55.
Obviously, this dialogue takes more time, but (a) the chance of
recognition errors is minimal and (b) when an error is made, it is easy
to correct it.
A Comparison Between Dialogue Styles
The above examples are two extremes with advantages and disadvantages;
the advantages are marked '+', the disadvantages are marked '-'.
| Dialogue A | Dialogue B |
|---|
| + natural dialogue | - unnatural dialogue |
| + fast (transaction minimal) | - slow (transaction maximal) |
| - user cannot see that an error has occurred | + user knows exactly when an error has occurred |
| - not easy for a user to correct an error | + easy for a user to correct an error |
| - a long dialogue to correct an error | + 'error-dialogue' does not play a major role |
These two extreme examples are both no suitable options in our dialogue
system. However, it is not easy to strike the happy mean. When are users
more likely to lose their temper: in case of many transaction times or
when a lot of errors occur?
Workshop Goal
The question is: "what are the boundaries in this trade-off between
verification and total number of turns". Of course, there are a number of
service-specific factors that have impact. The most important factor is
the success rate of the recognition system, but also other factors play a
role, like type of service, the importance of the information, the target
group and the expectations of the user. Our general position is that when
the recognition rate is below 95% explicit verification is inevitable and
plays a major role. However, during this workshop we would like to discuss
this issue and the influence of several factors on this issue.
CHI '97 Workshop: Speech User Interface
Design Challenges