1. Interface Design for ICT4B Speech, Dialects, and Interfaces Prof. Dan Klein and Prof. Marti Hearst

2. Special Needs of ICT4B User population Speaks many languages Speaks many dialects Often does not read, or reads little Equipment should be Inexpensive Low power consumption Thus, small screen or no screen

3. Goals for ICT4B Interfaces Task-specific rather than general- purpose computing Shared (multi-person, social) interaction Learnable by observation of use

4. Speech-Centric Interfaces Together these suggest that speech- centric interfaces are more appropriate than screen-centric ones. Alternatively, we should design interfaces that tightly couple speech and screen. However …

5. Slide adapted from James Landay's Speech-based Interfaces are Difficult to Design Speech recognition far from perfect Imagine inputting commands w/ the mouse & getting the wrong result 5-20% of the time How to guess the right dialect? Speech UIs have no visible state Can’t see what you have done before or what affect your commands have had Speech UIs can be hard to learn How do you explore the interface? how do you find out what you can say?

6. Slide adapted from James Landay's Speech UI Problems Difficult to design real dialogues Certain commands only work when in specific states Deep hierarchies (aka voice mail hell) Verbose feedback wastes time/patience only confirm consequential things use meaningful, short cues Interruption half-duplex communication (i.e., no barge-in support) Speech is memory-intensive

7. Slide adapted from James Landay's SpeechActs: Guidelines for Speech UIs Speech interface to computer tools Yankelovich, Levow, and Marx 1995 email, calendar, weather, stock quotes Establish common ground & shared context make sure people know where they are in the conversation

8. Slide adapted from James Landay's SpeechActs: Guidelines for Speech UIs Pacing recognition delays are unnatural, so make it clear when this occurs barge-in lets user interrupt like in real conversations tapering of prompts progressive assistance: short errors messages at first, longer when user needs more help implicit confirmation: include confirm in next command

9. Slide adapted from Dan Jurafky's A travel dialog: Communicator

10. Slide adapted from Dan Jurafky's Call routing: ATT HMIHY

11. Slide adapted from Dan Jurafsky's A tutorial dialogue: ITSPOKE

12. User-Centered Design Focus on the goals of the intended users Identify the tasks to accomplish those goals Use interative design, keeping the users “in the loop”.