<?xml version="1.0" standalone="yes"?>
<Paper uid="W01-1622">
  <Title>Adding extra input/output modalities to a spoken dialogue system</Title>
  <Section position="7" start_page="2" end_page="2" type="evalu">
    <SectionTitle>
4 Discussion and conclusions
</SectionTitle>
    <Paragraph position="0"> In this paper we have described the architecture of a multimodal train timetable information system that was built by extending a speech-only version. Most of the desired functionality of the modules that we added or changed was specified on the basis of off-line experiments and findings in the literature. The system is now ready to be tested by real users.</Paragraph>
    <Paragraph position="1"> Adding visual feedback has been shown to help in several respects. In Terken (2001) it was shown that the visual feedback helps the user to build a mental model of the task at hand. Furthermore, we argued that visual feedback may be interpreted as a form of implicit verification, which helps the user to detect recognition errors. This allows to apply confidence thresholds to avoid confirmation turns, even if a number of false accepts occur. This is in contrast with speech-only systems, where false accepts will remain unnoticed.</Paragraph>
    <Paragraph position="2"> User tests with our present prototype are needed to verify whether the additional modalities do indeed help to increase efficiency, effectiveness and user satisfaction. These tests will be conducted in the near future. In the current prototype a number of ad hoc choices were made. We expect that several of these choices will have to be revised based on the outcomes of the tests.</Paragraph>
    <Paragraph position="3"> CM scores that are calculated for individual words must be transformed into scores for slot/value pairs. This can be done in several ways: by taking the mean score, the maximum score, weighting the scores for values and slots, etc. In the current prototype we take the mean of the scores of the words that yielded a certain slot/value pair, but more sophisticated methods may be needed.</Paragraph>
    <Paragraph position="4"> In principle it is possible to go beyond the current design and give feedback on the status of the slots (confirmed or not, changeable or not) in addition to showing their values. This might prevent the user from getting lost in the dialogue. However, it is not yet clear whether additional visual attributes can be designed that are self-explanatory and will not confuse the user. It might be useful to enable the user to correct information by clicking the field that contains incorrect information and saying the correct information. Also, showing a list of alternative recognition hypotheses from which the user can select the correct one, might help. In the current system we have not implemented this option.</Paragraph>
    <Paragraph position="5"> Currently, the complete output of the dialogue manager is sent both to the speech output module and the screen. Informal tests have shown that the speech output designed for a speech-only system is much too verbose. Especially the oral presentation of the travel advice can be a short summary, e.g. consisting of only the departure and arrival times, when the complete advice is also presented on the screen.</Paragraph>
  </Section>
class="xml-element"></Paper>