Spoken dialogue systems (SDSs) can handle increasingly advanced tasks. This relatively new complexity poses three immediate development challenges [Dybkjær and Dybkjær 2004c]:
- The first is how to model the dialog when the user can select from many tasks. How can the system present the available choices and anticipate what the user will talk about next?
- The second challenge is how to communicate with customers about SDS design. When the system is fairly simple, developers can easily learn how to handle the domain to be covered and have relatively little need to communicate with domain experts. When the domain is large and complex, however, developers are less likely to understand its nuances and thus must collaborate more closely with those who do. Thus, choosing the best communication method becomes another development task - a concern SDS developers have not had to deal with traditionally.
- The final challenge is how to develop code efficiently for a large SDS when the design is likely to require updates throughout development. A complex application domain poses many flow and language problems.
These pages describe a tool — named DialogDesigner — which supports SDS developers in rapidly designing and evaluating a dialogue model. We show different aspects of the tool functionality in terms of how to model the dialogue, get various graphical views, run a Wizard of Oz (WOZ) simulation session, and extract different presentations in HTML, and we compare DialogDesigner to related tools.
- [Dybkjær and Dybkjær 2004c]: Issues of developing complex spoken dialogues.
- [Dybkjær and Dybkjær 2005e]: Presentation of DialogDesigner.
- [Harris 2005, Chapter 14]: Describes dialogue design as scripting, and strongly advocates the use of an electronic model.