190 likes | 785 Views
Waldemar Skoberla e-mail : waldemar.skoberla@temic.com phone : +49 731 3994 110 fax : +49 731 3994 250 WWW : http://www.starrec.com. Introduction. Contents. Introduction The Purpose of Voice Portals The Expectations of the Performance The Reality Challenges and Problems The Solution
E N D
Waldemar Skoberla e-mail : waldemar.skoberla@temic.com phone : +49 731 3994 110 fax : +49 731 3994 250WWW : http://www.starrec.com Introduction
Contents • Introduction • The Purpose of Voice Portals • The Expectations of the Performance • The Reality • Challenges and Problems • The Solution • Summary
Introduction Communication Saying is not listening Listening is not understanding Understanding is not accepting
Introduction There is a long way between an utterance and its acceptance. The purpose of a dialogue is to ensure that the user gets what he wants
The Purpose of Voice Portals User Profile: e.g. personal address book or calendar e.g. Unified Messaging e.g. Time Information Access through unique phone number Voice PortalInstant access to services like news, traffic, weather, stocks, Sports, etc. over the phone e.g. Ticket Reservation
The Purpose of Voice Portals • Comfortable phone access to any kind of information and services (Simple search and find strategy). • Quick access to preferred services and information (personalized services). • No restrictions to the user’s input (natural language understanding). • Voice Portals should open the access to information and services and not prevent it.
The Expectation • Does the user get what he wants?
The Expectation • Easy to use (intuitive dialogues, natural language understanding). • Flat menu structures with cross connections to all available services. • Guidance through the dialogue and context sensitive online help. • Easy to maintain and to extend (new services) • Easy to find one’s way through the dialogue structure (homogenous user interface in all available services). • Possible? Practicable?
The Reality Service 1 S1 Application (ASR) Voice Portal VP Application (ASR) Service 2 S2 Application (DTMF) Phone Access Service N S1 Application (ASR & DTMF)
The Reality • Different approach for Dialogue Design within available services (system driven call flow, mixed initiative approach, with/without Barge In) • The voice in System Prompts changes from one service to another (sometimes demanded but usually disturbing). • Usage of different technologies (speech recognition, DTMF, Barge In) • Confusion for the user
The Challenge • Vocabularies become bigger and grammars more complex (due to new services, natural language understanding, …) • Continuous modification of available services and adding of new services • Growing number of cross connections among all services • Implementation of Text-To-Speech more and more necessary • fast growing complexity of the Voice Portal application
The Problems • Big vocabularies may cause recognition confusions, speech recognizer do not offer100% accuracy (higher possibility of similar sounding words) • Adding new applications cause increasing maintenance efforts (pre-recording of system prompts, establishment of cross connections, updating of online help, adding new words for the recognizer) • Increased misunderstandings due to involved Text-To-Speech engines. (the state of the art quality of TTS is not as good as pre-recorded prompts) • nothing and nobody is perfect
The Problems • Does the user always know what he can say and do? (clear structure and prompting) • People sometimes do not say what they mean. • Is the user always able to handle new and sophisticated features? (natural language understanding) • sometimes less is more (simple applications increase the acceptance)
The Solution? Service 1 Voice Portal S1 Application (ASR) Application Data Exchange Service 2 Phone Access VP Application (ASR) S2 Application (ASR) S1 Application (ASR) Service N
The Solution • User adapted guidance and online support (tracing of user behavior and storing of the profile ) • Support through natural language understanding (no limits to what the user can say) • Hidden user guidance (intelligent prompting) • Design to Error • virtually (for the user ) no limitation to the flexibility
The Solution • Easier dialogue design through predefined and approved dialogue modules for standardized tasks (input of phone number, requesting time and date, etc.) • Support through sophisticated dialogue development tools (no limits to what the user can say) • intelligent tools and predefined dialogue modules reduce development efforts but do not replace human creativity
The Future • Fast growing number of speech enabled services. • Users become more and more familiar with new technologies. • Consideration of Multiple Modes of operation. (e.g. speech input combined with graphical output) • Automatic creation of new applications. (research status)
The Summary • The complexity of voice portal applications will grow very fast in future. • The quality of the services will be improved (sophisticated methods and ASR). • Short time to market through dialogue tools and modules support
Since Dialogues are human … … they cannot be completely designed by machines.