SUEDE: A Wizard Of Oz Prototyping Tool For Speech User .

2y ago
63 Views
2 Downloads
618.22 KB
10 Pages
Last View : 25d ago
Last Download : 3m ago
Upload by : Lee Brooke
Transcription

SUEDE: A Wizard of Oz Prototyping Toolfor Speech User InterfacesScott R. Klemmer, Anoop K. Sinha, Jack Chen, James A. Landay, Nadeem Aboobaker, Annie WangGroup for User Interface ResearchCS Division, EECS DepartmentUniversity of California at BerkeleyBerkeley, CA 94720-1776 USA 1 510 643 3043landay@cs.berkeley.edu http://guir.berkeley.eduABSTRACTSpeech-based user interfaces are growing in popularity.Unfortunately, the technology expertise required to buildspeech UIs precludes many individuals from participatingin the speech interface design process. Furthermore, thetime and knowledge costs of building even simple speechsystems make it difficult for designers to iteratively designspeech UIs. SUEDE, the speech interface prototyping toolwe describe in this paper, allows designers to rapidly createprompt/response speech interfaces. It offers anelectronically supported Wizard of Oz (WOz) techniquethat captures test data, allowing designers to analyze theinterface after testing. This informal tool enables speechuser interface designers, even non-experts, to quicklycreate, test, and analyze speech user interface prototypes.KeywordsWizard of Oz, speech user interfaces, prototyping, design,low-fidelity, informal user interfaces, design toolsINTRODUCTIONSpeech-based user interfaces are more appropriate thangraphical user interfaces in many settings and thus willlikely become a more common user interface paradigm inthe near future [10]. However, speech-based user interfacesare difficult to design well. Speech UIs are hard toprototype due to high costs in terms of the time andtechnology expertise required to build them. This makesiterative design difficult and often results in poor userinterfaces. We have developed an interactive prototypingtool called SUEDE to address this problem. SUEDE is alightweight, easy-to-use design tool based on the conceptsof example-based test scripts, prompt/response statetransitions, Wizard of Oz studies, and analysis of user studydata.Why Speech-based UIsToday’s graphical user interfaces (GUIs) do not let userscommunicate in ways that they naturally do with otherhuman beings [35]. Additionally, a non-trivial percentageof the U.S. population is blind or has trouble seeing wordsin ordinary newsprint (5% of those over age 15 [29]). Manyothers have limited literacy skills (21% of those over age16 [40]), typing skills, or use of their hands. The standardGUI does not work well for these users or for others inmany situations: when users are moving around, using theirhands or eyes for something else, or interacting withanother person. To enjoy the benefits of ubiquitouscomputing [46], we need newer, better interface paradigms.Speech-based user interfaces are one paradigm that cansuccessfully address many of the aforementioned problems.Supporting Speech Interface DesignersAlthough many researchers and industry analysts believethat speech user interfaces will become commonplace,there are a number of factors that hinder their incorporationinto everyday use.A key limiting factor in speech interface design is the lackof basic knowledge about user “performance duringcomputer-based spoken interaction” [10]. Many interactiondesigners who could contribute to this body of knowledgeare excluded from speech design by the complexities of thecore technologies, the formal representations used forspecify ing these technologies, and the lack of appropriatedesign tools to support iterative design.The complex recognizer and synthesizer technologiesinherent in a speech UI require a high level of technicalcompetency to understand. These systems generally have alarge number of “knobs” and parameters that must bemeticulously adjusted in order to get optimumperformance. Previous research studying the use of visualdesign tools showed that when given these knobs, designersspend many hours manipulating the parameters rather thanexploring the design space [4, 15].The most effective method for constructing high qualityuser interfaces is an iterative approach [16]. This requires afast, repeated cycle of design, prototyping, and evaluation.Therefore, to be successful, a speech interface design toolmust be easy to learn, require little programming expertiseto use, and support the rapid creation, testing, andmodification of interface designs. These requirements form

Figure 1. SUEDE’s Design mode allows the easy creation of example scripts (top) and speech UI designs (bottom).interface design process. Next, we give an overview of thethe basis of any user interface prototyping tool targetedsystem implementation. We then review the related work intowards interface designers [45].prototyping methodologies and tools for speech userThe grammar and state machine representations used tointerface design. We finish with future plans anddesign speech-based systems are formal and abstract. Thisconclusions.is in awkward contrast with the informal, concreterepresentations, such as scenarios [6, 8], sketches [5, 22],and storyboards [23, 24, 45], that designers commonlyemploy to explore design ideas through examples.Designers typically start with usage scenarios and movetowards abstractions over time.DESIGN / TEST / ANALYSIS METHODOLOGYThis basic mismatch in approach is an important issue thatmust be resolved for any tool to be successful. We havepreviously argued that an “informal interface” approach,using unrecognized, natural input (e.g., sketching orspeech) successfully supports designers in the early stagesof design [18, 24]. Using these tools, designers areencouraged to explore the design space rather than detailone design idea too far. SUEDE embodies this approach.SUEDE’s interface is organized around three importantphases that these designers perform in the early stages ofdesign: Design, Test, and Analysis. In the Design phase,they often begin by creating conversation examples (seeFigure 1, top). These examples evolve into, and provide thefoundation for, the actual interface design (shown inprogress in Figure 1, bottom). In the Test phase, they tryout the design with target users. During Analysis, designersexamine collected test data, deciding how it shouldinfluence the next design iteration.The rest of this paper is organized as follows. We first givean overview of the Design / Test / Analysis methodologyused by practicing speech UI designers and supported inSUEDE. After that section, we describe in detail howSUEDE supports the early stages of the speech userSUEDE’s design was based on interviews with six speechUI designers from both industrial research (SRI and SunMicrosystems Laboratories) and development organizations(Nuance Communications and Sun Microsystems).The problems with real world speech user interfaces arisewhen users do not know what to say, speak outside thesystem’s grammar, or say something that is misrecognized

by the system. The designers we spoke with wanted morehelp analyzing their test data to deal with these types oferrors.We developed the Design / Test / Analysis methodology asan explicit model for interface design tools as a result ofremarks made by Edward Tufte at his Presenting Data andInformation seminar (December 8, 1999 in San Francisco).Tufte argued that usability testing, as practiced today, doesnot work since it entails repeated cycles of Design andTest, resulting in a UI popularity contest. He argued insteadthat good design was a process of repeated application ofDesign and Analysis. We believe both approaches areinsufficient; the approach that most successful design andusability specialists use is the repeated application ofDesign, Test, and Analysis. SUEDE provides an interfacemode for each of these three tasks (see Figures 1, 2, and 3).graph represents the dialog flow based on the user’sresponses to the system’s prompts. Designs are created bydragging cards from the script onto the design area,creating new cards on the design area, and linking theminto the dialog flow. The orange script cards becomeorange prompt cards () in the design area. Thegreen script cards become green response links ()in the design area. The important interaction techniques areillustrated in the below diagrams:Dragging an orange script prompt card tothe design area creates an orange promptcard.Dragging a green script response card tothe canvas area creates a green responselink in the design graph.HOW SUEDE WORKSWe will explain the functionality of SUEDE using theexample of someone who is designing a telephone-basedspeech interface for reading and sending email, as in theMailCall system [26]. A typical session in this system startsby prompting the user for their name and then asking themwhat they want to do: read email, send email, getsummaries, or hang up.Dragging a script response card onto anexisting design graph prompt card createsan outbound response link from thatprompt.Design ModeA left mouse drag gesture between twocards creates a link. Dragging from thebackground onto a prompt creates aglobal.Speech designers often begin the design process by writinglinear dialog examples in a word processor [33]. SUEDEallows linear dialog examples to be created horizontally inthe top area, called the script area, of Design mode (seeFigure 1, top).Prompts are recorded by the designer for the phrases thatthe computer speaks. Responses are the phrases thatparticipants make in response to prompts. System promptsalternate with user responses for accomplishing thedifferent tasks. The orange prompt cards in the scriptrepresent the system’s speech prompts and the greenresponse cards represent example responses of the enduser. The designer can record her own voice for the speechon both types of cards, as well as type in a correspondinglabel for each of the cards. By playing the recordings fromleft to right, the designer can both see and hear the exampleinteraction.We can see from the second script at the top of Figure 1that the designer has recorded the following alternatingprompts and responses: “Hello, what is your name?”,“Annie”, “What would you like to do”, “Read email”, “Youhave two messages”, “Read them”, “First message fromJack” and “Anything important?”.After creating the examples, typically on index cards orsmall pieces of paper, a designer creates a flowchartrepresentation of the dialog flow. In SUEDE, afterconstructing several example scripts and working withthem to become familiar with the dialog flow, the designerstarts to construct a design graph, representing the actualinterface prototype (see Figure 1, bottom). The designGlobals, Groups, and Voice BalloonsSUEDE also supports special types of prompt cards calledglobals and groups, as well as a mechanism, called a voiceballoon, for parameterizing a later prompt with a testparticipant’s actual speech response.A global is a speech command that can be spoken at anytime during an end-user test session, such as “main menu”or “help.” In Test mode, clicking on a global will transitionthe participant to the connected prompt card.A group is a set of prompt cards that are possible promptsfollowing a specific participant response. As an example:Prompt:“Welcome to the weather system.”Response: “What is the weather like in San Francisco?”Prompt Group:“It is sunny”“It is raining”“It is foggy”Another example is the “Message Options” group in Figure1, containing the possible prompts resulting from the “reademail” command.The wizard has the option of choosing among any of thesereplies to the participant when testing. Each of these has the

same logical structure in the interface. Above, the designerused the message options group to enable the wizard to testdifferent scenarios, yielding an interface with theappearance of being database backed (as the fullyimplemented system probably would be). Groups can alsobe used for tapering, a speech technique in which differentprompts are given, based on the number of times theprompt has been previously played. Groups can also beused to give different error messages to differentparticipants.only the record and play controls (the prompts inside“Message Options” in Figure 1).A voice balloon corresponds to “filling in the blanks” in adirected dialog system, where the user’s responses are usedin the subsequent prompts. The participant’s unmodifiedrecorded audio is automatically spliced into a later prompt.An example of this would be:Test ModePrompt A: “What flight would you like?”Response: “AIR2000”Prompt B: “What day would you like to take the flight?”Response: “Tuesday”Prompt C: “The schedule for AIR2000 on Tuesday is ”Voice balloons are added to a prompt as follows:A voice balloon is added to a card bydragging from a response link onto aprompt card.Groups have three similar scales. Their large scale displaysall their prompts at their full size. By default, groupsdisplay all prompts at their compact size (“MessageOptions” in Figure 1). When compacted, groups displayonly their title. Designers can switch between theserepresentations by gesture. A left mouse gesture upwardexpands a prompt or group, and a left mouse gesturedownward contracts a prompt or group.SUEDE designs can be immediately executed by clickingon the Test button. The designer can try out her designideas as soon as she has created them without the need for aspeech back-end. That is, no speech recognition or speechsynthesis is necessary to create prototypes in SUEDE.Wizard of Oz methodologies have a long tradition in thedesign of speech systems [16]. In conventional WOzstudies, designers test scenarios manually by walkingthrough the different steps in a dialog flow. The wizardsimulates dialog transitions as a computer would, readingthe system prompts to the participants and “processing”their responses.In SUEDE, the designer switches to Test mode by clickingon the Test button in the upper right corner of the mainA voice balloon represents the run-time response of a testparticipant. It can be used in a prompt at design time as aplaceholder for a participant’s utterance. In the flightscheduling example above, the designer created a voiceballoon corresponding to a user’s response to the prompt“What flight would you like?” This voice balloon was thendragged onto the later prompt “The schedule for,” resultingin “The schedule for A ”. At run time, A would befilled in with the user’s own response to the first prompt.A Scalable Design VisualizationThe designers that we spoke with were building promptand response interfaces of about 200 nodes. One designercurrently using Visio for early stage design felt frustratedthat her designs were spread across a dozen pieces of paper(her Visio designs had about fifteen nodes per page). Shewas interested in having the entire design fit on onedisplay.SUEDE supports scaling in two ways. First, scrollbarsallow designers to pan around interfaces that are larger thanone screen. More importantly, prompts and groups can beshown at three different scales. At their largest, promptsdisplay their full text and all the prompt audio controls(prompt M in Figure 1). By default, prompts display oneline of text and all the audio controls (prompt A in Figure1). At their smallest, prompts display one line of text, andFigure 2. Test mode is presented in a web browser andallows the wizard to focus on the current state of the UI(top) and the available responses for that state (bottom).

screen (see Figure 1). When the designer switches to Testmode, SUEDE generates an appropriate HTML file forevery prompt card in the design graph. The hyperlinks oneach page represent the corresponding response linkspossible from that card. Clicking on a link moves from cardto card.The testing window is a browser-based interface (seeFigure 2). The screen is broken up into four distinctsections (from top to bottom): session menu, a transcript ofthe current session, barge-in and timeout controls, and anHTML page of the valid user responses to the currentprompt card. Global responses are available on all pages.In Test mode, a wizard works in front of a computer screen.The participant performs the test away from the wizard, ina space with speakers to hear the system prompts and amicrophone hooked up to the computer to record hisresponses. When the wizard starts a test session, SUEDEautomatically plays the pre-recorded audio from the currentprompt card. The wizard waits for the test participant torespond, and then clicks on the appropriate hyperlink basedon the response. During the course of the test session, atranscript sequence is generated containing the originalsystem audio output and a recording of the participant’sspoken audio input.The wizard’s only job is to click on the appropriate controlsand links in the test interface HTML area (see Figure cally insert simulated speech recognition errors,which is further described in the “Error Modeling” sectionbelow. The wizard can monitor the progress of the sessionin the Transcript area at the top of the test interface, whichshows the prompts that have been played so far, along withthe matched responses.Continuing our MailCall example, we see in Figure 2 thatthe test session has just played the “What would you like todo?” A participant might respond, “I’d like to write anemail please.” The wizard would interpret the user’sresponse and click on the “Send email” link. Also note inFigure 2 the three distinct choices under “Read email,”illustrating the test view of SUEDE’s group structure. Attest time, the wizard can choose any one of the groupedprompts to transition to next.Since there is no speech recognition system underlying thisWizard of Oz test, in the early stages of design the wizardwill use this opportunity to accept several alternativeinputs. In our example, the wizard might accept “Send,” “Iwant to send,” and “Write email” as valid utterances for the“Send email” response link. These actual audio responseswill be recorded and associated with the response link andcan be later reviewed in Analysis mode to help determinethe input grammar for the final design.Error ModelingIn the session menu area, there is a parameter marked “%Errors”. This value sets the simulated speech recognitionerror. As the wizard is running the system, SUEDE caninsert random misrecognition errors as a real speechrecognizer might do, as described in [31]. If a random errorhappens, SUEDE overrides the wizard’s choice, informshim of this fact, and randomly chooses one of the otherpossible links on that page. The wizard is not tasked withmimicking an error rate. A representative example of arandom error follows:Prompt:“On what day would you like to fly?”Response: “Thursday”Prompt:“The flights on Tuesday are ”A typical participant response in this scenario would be:Response: “No I meant Thursday”Handling this situation should be part of a robust speechinterface design. Recording what participants say inresponse to errors helps the designer analyze and handlethese errors in future design iterations. We plan to extendSUEDE to allow automatic backup to a previous prompt toassist in handling these types of errors.TimeoutsMany speech interfaces treat the lack of response after acertain time window as a timeout error. A common strategyfor a timeout in many interfaces is to repeat the last playedprompt, in hope that the participant will be able to respond,in case they did not hear the prompt the first time. Clickingthe Timeout button in Test mode executes this behavior.A more sophisticated timeout handling response is to givecooperative incremental feedback to the participant. InSUEDE, incremental feedback can be modeled with promptgroups and response links.Barge-InBarge-in is a fairly sophisticated speech interface techniquein which a participant responds to a prompt while theprompt is being played. It is especially important inconversational interfaces where prompts might be long andrepetitive. SUEDE allows the wizard to simulate barge-inby stopping the current prompt and switching to recordingaudio when the Barge-in button is pr

Wizard of Oz, speech user interfaces, prototyping, design, low-fidelity, informal user interfaces, design tools INTRODUCTION Speech-based user interfaces are more appropriate than graphical user interfaces in many settings and thus will

Related Documents:

(b) A wizard follows the user and updates his or her location in the wizard UI on a tablet PC. Figure 2. Topiary’s wizard UI. The wizard map represents entities’ current location and orientation; to simulate updates, a wizard drags them on the map. The end-user screen lets a wizard mon

Recover files detected by their signatures wizard on page 69 Recover files from a formatted partition wizard on page 73 Recover files from a deleted partitions wizard on page 75 Recover files from a physical disk wizard on page 77 Restore a deleted partition wizard on page 82 Create a new partition wizard on page 83

Nappa Leather Seat Pack Nappa leather seat cover Suede headlining Suede A/B/C pillars Suede sunvisor (driver & passenger) 2470 Lexicon Audio System Lexicon audio system Speakers rear package tray Tweeter (front & rear), external amp (mid) & center (front) 790 Wheels Alloy wheels 19 inch (A-Type) Michelin Tyres 750

The User Profile Wizard User Guide. This document! The Deployment Files folder. This folder contains the files needed to migrate a workstation to a new domain. User Profile Wizard The User Profile Wizard Command Line Console The User Profile Wizard Deployment Kit We will reference these icons throughout this user guide.

Wing Type Surface Setup is the last step in the Wizard. Press the in the upper right corner to save settings and exit the Wizard. The application will display the AS3X Settings menu after exiting the Wizard. Exit the Wizard

The Royal Shakespeare Company’s stage adaptation of The Wizard of Oz is a musical based on the novel The Wonderful Wizard of Oz by L. Frank Baum, and the 1939 Metro-Goldwyn-Mayer film, The Wizard of Oz, with a book by John Kane, music by Harold Arlen and lyrics by E.Y. Harburg. It debuted at the Barbican Theatre in London’s West

Setup Wizard: General 12 Setup Wizard: Camera & Email 13 Setup Wizard: System Time 14 Setup Wizard: Account Configuration 15 . SwannView Link: Local Settings 50 51 55 56 Warranty Information 57 Helpdesk/Technical Support Details Rear Cover: 4. Chapter: 1: Introduction: INTRODUCTION: EN: INTRODUCTION : 5: Introduction:

SwannView Link: Device Settings7 NVR Rear Panel Troubleshooting 8 Connection Diagram Addendum: Third Party Hardware 9 Connecting Additional Devices 10 Controlling the NVR 11 Setup Wizard: General 12 Setup Wizard: Camera & Email 13 Setup Wizard: System Time 14 Setup Wizard: Account Configuration 15 Setting your Smartphone or Tablet 16 .