Hoe kun je usability heuristics gebruiken om een spraakgestuurde interface te evalueren?
Richard de Vries 0554054, Communicatie & Multimedia Design 2007
Inleiding
2
Spraaktechnologie
3
Spraaktechnogie & Ubicomp
5
Hoe, methodiek
9
Heuristics
10
Evaluatie volgens Nielsen
20
Usability Heuristics voor visuele spraakgestuurde interfaces.
23
Systeem
24
Gebruiker
25
Input
26
Output
27
Test
28
9 Heuristics voor visuele spraakgestuurde interfaces.
29
1 Reactietijd
29
2 Context
29
3 Kennis en taal
29
4 Uitleg en instructie
29
5 Compatibaliteit
30
6 Errors
30
7 Klank & uitspraak
30
8 Informatie
30
9 Locatie en navigatie
30
Conclusie
31
Referenties
32
1
Inleiding In deze scriptie wil ik bekijken wat de grote verschillen zijn tussen een klassieke opstelling (muis - toetsenbord combinatie) en eenzelfde opstelling met de toevoeging van spraak, aan de hand daarvan wil ik kijken hoe bestaande heuristics hierop toe te passen zijn en welk aspect van een spraakgestuurde interface niet, onjuist of onvolledig behandeld wordt binnen de bestaande heuristics. Een kritische geest zal zichzelf snel de vraag stellen; ‘als er nog geen heuristics voor dit type interface zijn, is er dan wel behoefte aan?’ Dat op zichzelf is een vraag waar een volledige scriptie aan geweid zou kunnen worden. De ontwikkeling van spraaktechnologie heeft zich tot nu toe erg afgespeeld op een technisch vlak. Hierbij is er weinig interesse voor ontwerpvragen. Echter ik denk dat de volgende ontwikkeling plaats zal moeten vinden op een (interaction) design gebied. Voor GUI1 doeleinden zijn er meerdere evaluatie heuritics, ik wil hiervan 4 heuristics samenvatten; de heuritiscs van Donald Norman, Jacob Nielsen, Bruce Tognazzini en de heuristics die door TNO gebruikt worden. Voor VUI2 doeleinden zijn er ook heuristics; voor Microsoft heeft Susan L Hura duidelijke heuristics voor spraaktoepassingen gedefinieerd. Deze heuristics wil ik naast elkaar leggen om te zien waar overlap en waar verschil is. Aan de hand hiervan zou er al een lijst met erg nuttige evaulatie heuristics moeten ontstaan. Echter ik vermoed dat er tussen deze twee typen heuristics een gat ontstaat van mogelijke problemen die niet opgemerkt worden als deze gebruikt worden. Hiervoor zal ik proberen aanvullende heuristics te schrijven.
1
GUI: Graphic User Interface
2
VUI: Voice User Interface 2
Spraaktechnologie De ontwikkeling van spraakherkenning dateert al sinds de jaren 50 vorige eeuw. Deze ontwikkeling heeft voornamelijk plaatsgevonden binnen een wetenschappelijk kader. Dit proces zelf zegt ook veel over de manier hoe spraak herkent wordt. De ontwikkeling heeft een viertal aspecten van spraak beantwoord • fonetisch • tijd • intelligentie • context
Fonetisch Fonetisch onderzoek begint in de jaren 50 en is het analyseren van een audio geluid om zo vervolgens letters uit klanken te herkennen. Wat eigenlijk gebeurd is dat een geluidsfragment gecontroleerd vergeleken wordt met een ander geluidsfragment. Op deze manier zijn herkenners ontwikkeld welke tot 10 verschillende losse woorden kon herkennen.
Normalisatie / tijd Om betere herkenning te krijgen was de volgende stap in dit onderzoek het ‘normaliseren’ van audio. Bij het normaliseren worden de fluctuaties in zowel het volume als de lengte van de audio fragmenten hetzelfde gemaakt.
Persoon In de jaren 70 is de belangrijkste ontwikkeling geweest het spreken onafhankelijk herkennen van spraak. Hierdoor is het mogelijk om spraak van verschillende personen te herkennen waar het voorheen alleen mogelijk was om deze te herkennen voor elke losse persoon.
3
Benadering / context Het onderzoek in de jaren 80 wordt vooral gekenmerkt door de verandering van de benadering van spraaktechnologie. Voorheen was deze benadering vooral gericht op het vergelijken van data. Een audio fragment werd vergeleken met een bestaand fragment om zo te toetsen hoeveel deze overeen komen. Het Hidden Markov Model(6) is een manier om de waarschijnlijkheid van een nog onbekende Een goede benadering voor een hoge parameter te ‘berekenen’. Het model bestaat al herkenning is door de context van een sinds de jaren 60 en wordt toegepast op meerdere gesproken tekst te herkennen. Hierom is gebieden. Binnen spraakherkenning wordt een er voor gekozen om het Hidden Markov model gevormd welke de waarschijnlijkheid Model te gebruiken. aangeeft dat een bepaald woord volgt op een ander woord. Het model wordt groter naarmate er meer worden zijn en er meer woorden vergeleken worden zoals bijvoorbeeld de waarschijnlijkheid dat een woord volgt op 2 eerdere woorden, of 3 eerdere woorden etc.
Vanuit deze ontwikkeling gezien, wat is spraak? Spraak is een herkenning van een aantal klanken waarbij de uitkomst van fonetische overeenkomst + contextuele waarschijnlijkheid het hoogst is.
4
Spraaktechnogie & Ubicomp In 2003 heeft Jakob Nielsen een stukje geschreven over zijn visie op spraak interfaces. Hierin schrijft hij onder andere dat hij in 1986 een groep computer professionals heeft gevraagd wat de grootste interface verandering was in het jaar 2000, hierin werd een spraak interface 2 keer zo vaak genoemd dan een GUI en het meest genoemde antwoord is. Nu ruim na het jaar 2000 worden GUI’s bij bijna elke interface gebruikt en spraak nog nauwelijks. Hij stelt verder dat spraak vaak voorgesteld wordt op een onmogelijke en onlogische manier binnen de science fiction wereld. De positie die Nielsen inneemt is dat spraak het grootste potentieel is als toevoeging binnen een multimodaal dialoog. In 1992 maakte sun een korte film waarin ze hun toekomstvisie schetsen genaamd “starfire”. Deze film laat binnen een scenario zien hoe een aantal nieuwe interactie technieken toegepast kunnen worden. Ook spraaktechniek komt hier voor. De hoofdpersoon neemt bijvoorbeeld de (computer) telefoon op door ‘answer’ te roepen. Ook opent ze bestanden en voegt ze media hieraan toe en creeert ze een illustratie met spraakherkenning. Ook binnen deze toekomstvisie wordt spraakherkenning als toevoeging / onderdeel van een geheel gezien. Als de verwachting is dat spraakherkenning een belangrijk onderdeel wordt van de gebruikersinterface, dan is het aan te raden om nu al na te denken over de interactie en vormgeving van zo’n interface. Het beste pleidooi hiervoor kun je vinden in Jakob Nielsen en Don Gentner’s “The anti-mac interface”. In The anti-mac interface beschrijven Don Gentner en Jakob Nielsen hoe de human interface guidelines van apple macintosh (niet optimaal) functioneren in hedendaagse computers. Deze guidelines zijn ontworpen met randvoorwaarden die nu vaak niet meer geheel kloppen. • • • •
•
Ontwerpen zijn gebaseerd op naive gebruikers, zonder enige computer ervaring De applicaties waren beperkt De computers waren minder krachtig De input/output was erg beperkt. Zwart-wit scherm, toetsenbord & 1 knops muis. Geen audio in/of output. De computer was nergens mee verbonden (op zijn hoogst met een printer)
Deze guidelines zijn niet significant veranderd sinds ze zijn ontworpen en zijn vrijwel gelijk aan andere GUI’s (zoals Windows). Ze hebben geleid tot het WIMP 3 model voor een GUI. In deze paper worden een aantal aspecten van een GUI opnieuw bekeken vanuit de gebruiker en omgeving van nu: • • • • • 3
Metaphors Direct Manipulation See & point Consistency WYSIWYG
WIMP: Windows Icons Menu’s Pointer 5
• • • • • •
User Control Feedback and dialog Forgiveness Perceived Stability Aesthetic Integrity Modelessness
Binnen het kader van een spraakgestuurde GUI vallen met name Direct Manipulation op. De auteur stelt dat direct manipulation kan leiden tot een eentonige handeling wanneer een gebruiker meerdere acties wil uitvoeren. Verder zijn er scenarios waarbij de oog-hand coördinatie minder precies is dan een rekenkundige of taal opdracht. Met see & point wordt kort gezegd de muis interactie bedoeld. Kijken – aanwijzen – klikken. Binnen de randvoorwaarden waarin de guidelines geschreven zijn is dit een hele logische vorm van interactie. Nu we echter veel meer vormen van interactie tot onze beschikking hebben is het een hele onlogische vorm van interactie. Wat volledig onbenut wordt is taal. Wanneer men niet de mogelijkheid heeft om te communiceren via taal (wanneer 2 mensen bijvoorbeeld niet dezelfde taal spreken) wordt vaak terug gegrepen naar het kijkenaanwijzen. Het werkt, heel beperkt. Het artikel pleit voor een verandering van de interface volgens een aantal ‘anti-mac interface’ principes: • • • • •
the central role of language a richer internal representation of object a more expressive interface expert users shared control
“The central role of language” klinkt geavanceerder dan wat er mee bedoeld wordt. Een AI omgeving waarbij gebruikers een volledige dialoog hebben met hun computer wordt niet bedoeld. Echter taal zou een goede aanvulling op de interactie kunnen betekenen. In zekere zin heeft een command line deze eigenschap. Echter hierbij missen een aantal belangrijke aspecten om deze gebruiksvriendelijk te noemen. In de 1e plaats begrijpt de computer alleen de commando’s die in geprogrammeerd zijn en er is geen makkelijke manier om te ontdekken wat deze commando’s zijn. In de 2e plaats is er geen tolerantie voor spelfouten, synoniemen of verkeerde grammatica. Een oplossing hiervoor is door een bepaalde feedback te geven; spellingscorrectie, mogelijkheden weergeven, kennis van de gebruiker en zijn taak. De ondertoon en conclusie van deze paper kan zijn dat het bestaande model van een GUI niet meer volstaat voor de taken die er nu aan verbonden zit. Het zou dan ook willen pleiten om het model volledig anders te doen. Alleen is het moeilijk om dit model te veranderen omdat het in de loop der jaren ontzettend groot en omsluitend is. Op het gebied van spraakherkenning is er nog geen model waarbinnen applicaties ontworpen worden. Qua ontwikkeling zou je spraakherkenning kunnen plaatsen op het niveau van command line interfaces; het niveau is nog maar net bruikbaar en de functionaliteit lijkt ook erg veel op die van een command line interface.
6
Command Line
VUI
WIMP GUI
Ubicomp
GUI + VUI
Ubicomp, of ubiquitous computing, kan gezien worden als een stroming / gedachte waarbij de ‘computer’ altijd aanwezig en beschikbaar is. Het klassieke desktop model van een computer waar men achter gaat zitten om bepaalde taken uit te voeren zou dan ook verdwijnen en computertaken zouden meer onderdeel worden van het dagelijks leven. In “the computer of the 21st century” legt Mark Weiser uit hoe hij met zijn collega’s bij Xerox PARC geloven in het verweven van informatie technologie in de maatschappij, als voorbeeld geeft hij aan dat geschreven woord ook volledig verweven is in onze maatschappij. Ik denk dat een van de eerste stappen richting het werkelijk verweven van ‘personal computer’ binnen de maatschappij is het zoeken naar een nieuwe vorm van input. De klassieke vorm van een input device is een fysieke, tastbare. Dit komt in conflict met de ubicomp gedachte omdat de gebruiker zich altijd zal moeten vormen naar deze input device.
De meest natuurlijke vorm van uiting voor mensen is door middel van gebaren of spraak. Het is dan ook logisch om te denken dat gebaren of spraak een natuurlijke manier zou zijn om een computer te bedienen.
Natural gesture is een manier om door middel van gebaren een computer te besturen. Hier wordt onderzoek naar gedaan en functies van deze input zijn ook gebruikt in bijvoorbeeld playstations “eye toy” Spraakherkenning is een ontwikkeling die spraak tot een bruikbare input maakt voor een computer. Ten opzichte van natural gesture heeft spraakherkenning een aantal praktische voordelen: - Meer variatie Wij (mensen) kennen simpelweg meer verschillende woorden dan dat wij gebaren kennen.
7
- Meer vrijheid Geluid beweegt zich vrij door een ruimte, licht (beeld) wordt daarentegen opgevangen door obstakels. Bij spraakherkenning kan een gebruiker zich in een veel grotere radius van de ontvanger bevinden dan bij beeldherkenning en kan zich zelfs achter obstakels bevinden. - Minder verandering Technisch gezien is het makkelijker spraakherkenning in bestaande interfaces te implementeren. Knoppen hebben al labels en commando’s zijn stukjes tekst Spraakherkenning wordt inmiddels toegepast op een groot aantal verschillende gebieden. Vaak zijn dit hele specifieke toepassingen gericht op een situatie waarbij gebruikers Hoe (in)efficiënt heb ik met een klein testje geprobeerd te ontdekken. Een gebruiker belt naar 0900 1475 ( het telefoonnummer van OVIS) De andere gebruiker gebruikt www.9292ov.nl Beide gebruikers zoeken naar de beste reis vertrekkend vanaf Amersfoort naar Rotterdam om 3 uur dezelfde dag. Ze zoeken dit op hetzelfde moment op. Resultaat: Telefonisch duurde 1 minuut 32 seconden Internet duurde 43 seconden. (107% sneller) Hierbij is het ook nog zo dat de internet gebruiker meer informatie heeft gekregen dan de telefonische gebruiker (zoals latere vertrektijden/alternatieven, aankomsttijd en spoorinformatie. onderweg of geen mogelijkheid hebben om hun handen te gebruiken. OVIS is hiervan een goed voorbeeld. Wanneer iemand wil weten hoe laat zijn trein gaat kan deze bellen naar een computer en door middel van een spraak computer de informatie krijgen welke deze wil. Echter bij VUI’s ontbreekt de visuele schakel. Hierdoor wordt de taakuitvoering erg inefficiënt.
Het voordeel van deze VUI is wel dat deze op elk moment beschikbaar is (wanneer de gebruiker kan bellen.) Echter wanneer de taak complex wordt, is het bijna onmogelijk om deze uit te voeren zonder gebruik te maken van een visueel hulpmiddel. Het grote verschil in efficiëntie met een visueel hulpmiddel is dat de gebruiker zelf vrijwel direct kan zien wat zijn mogelijkheden zijn en zelf de informatie kan filteren op welke informatie voor hem nuttig is.
8
Hoe, methodiek Allereerst is het belangrijk om te bepalen met welke set heuristics ik begin. Inmiddels zijn er een tal van verschillende heuristic evaluations mogelijk. Jacob Nielsen heeft het volgende opgeschreven om de groei van heuristic evaluations te illustreren; Elk jaar heeft hij een google zoekopdracht gedaan op “heuristic evaluation” en dit zijn per jaar de resultaten: 1998: 600 pages 2002: 9,500 pages 2003: 14,500 pages 2004: 42,200 pages 2005: 58,000 pages Als eerste wil ik de heuristics van Jacob Nielsen gebruiken. Deze zijn kort en veel gebruikt. Verder wil ik ook de VUI heuristics als bepaald door Susan L Hura voor Microsoft gebruiken. Ook wil ik de design principles van Donald Norman en Bruce Tognazzini’s first principles gebruiken. Wanneer ik een lijst met heuristics gevormt heb wil ik deze voorleggen aan professionals die gewend zijn om heuristics te gebruiken in de evaluatie van een interactieve applicatie. In deze test wil ik er achter komen welke heuristics duidelijk zijn en hoe ik ze kan herschrijven. Verder zal blijken welke aspecten over het hoofd worden gezien of meer aandacht vragen.
9
Heuristics Heuristics kun je beschouwen als een aantal vuistregels binnen een expert review evaluatie van een applicatie. Een expert review / heuristic evaluation behoort onderdeel van het ontwerpproces te zijn. In tegenstelling tot veel andere methodieken is deze gebaseerd op onderzoek en tests. De evaluatie gaat uit van bestaande usability principes en wordt zo gebruikt om op een eenvoudigere manier en in een vroeg stadium problemen te herkennen. Wat ook zeker onderdeel is van een evaluatie is het aangeven van welke principes goed werken. Zo wordt voorkomen dat goede eigenschappen verloren gaan in het oplossen van de ontdekte problemen. De bestaande heuristics die ontwikkeld en gebruikt worden zijn ofwel voor een ‘klassieke’ interface (muis toetsenbord combinatie) ofwel gericht op een enkel spraak interface (spraak <-> spraak) Deze heuristics zijn niet zonder meer toe te passen op een visuele spraak interface. Op het gebied van VUI (Voice User Interface) gaat het eigenlijk altijd om een simpele / enkelvoudige taak bij de gebruiker en bij een GUI wordt alleen rekening gehouden met een visuele / fysieke input. Omdat er bij een VUI geen grafische interface is slaan de heuristics hierbij voornamelijk op taalgebruik en ‘navigatie’/flow. Bij GUI heuristics worden twee belangrijke aspecten over het hoofd gezien; ontbreken van feedback en de foutgevoeligheid van een spraakherkenner.
10
Eerst de heuristics die ik ga gebruiken en een korte omschrijving:
Nielsen: Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
11
Susan L Hura: VUI Heuristics: Lessons in the art of automated conversation Make It Real Users come into their interaction with the automated system with a set of terminology, metaphors, and organizational structures already in place. That is, users have a mental model of the domain and their interaction. Usable applications tap into this knowledge to give users a head start in understanding how to interact with the application. This is an example of a modality-independent guideline that applies to any automated system. Clearly and Consistently Communicate System Capabilities We are at a unique point in technological history. Today, many users have had more exposure to speech technologies via Star Trek than in real life. In the GUI realm, users draw upon their general computer experience, real world experience in the domain of an application, and possibly previous experience with other applications. On the other hand, many users have little or no previous experience interacting with VUIs. However, these same users are not naïve because their experience with spoken language is huge and may dominate their interaction with the application. Therefore, voice user interfaces must be carefully designed to help users understand the capabilities of the system. Interfaces need to unobtrusively guide users to speak predictable utterances and avoid the unconstrained conversational speech that we use talking to another person. The goal is to achieve a natural conversation within the technological boundaries of speech recognition. Minimize the Limitations of the Medium Listening is a difficult task, especially if there are other demands on the user's attention. The user's auditory memory is limited to a few short items, and these are quickly forgotten. The implications of these for a voice user interface are substantial. Navigation and overall architecture of the application must be transparent and easily retained for users to succeed. Moreover, the pace, word choice, and especially the intonation of prompts within a VUI are vital to helping users work in the auditory modality. Help the User Avoid Escalating Errors and Recover from Errors Gracefully Speech recognition technology is imperfect, and users encounter failure for various reasons. Misrecognitions, time-outs, and out of vocabulary speech all occur regularly. To speech developers, these are distinct problems that require specialized remedies. The impression of the user, however, is simply that the system isn't working as they expect it to. With careful consideration of error handling and cleverly designed help, we can produce applications that minimize the impact of problems that users will inevitably encounter. Applications should give users advice when they are likely to need it and allow callers change their minds, make corrections, and try again.
12
Make the User Comfortable Using the Technology Those of us in the speech business are technophiles who enjoy using new technology for its own sake. This is not true for most users of speech-enabled applications. Users tend to care more about accomplishing their goals than about cool technology. And recall that many users have little or no experience with speech technology, so they are unsure what to expect. Applications need to provide users with reassurance that their spoken input was accepted and that their transactions will be processed appropriately. Remember, an automated application is valuable only if callers are comfortable enough to use it.
13
TNO Heuristics Gebruikers In het ontwerp dient rekening gehouden worden met de eigenschappen van de gebruiker. Waarnemen, verwerken, beslissen en handelen van de gebruiker. Doelen of taken De functies en de structuur hiervan moeten aansluiten bij de doelen van de gebruikers. Heuristics op gebruikersniveau Informatiebehoefte De gegeven informatie moet aansluiten bij de informatie die de gebruiker nodig heeft. Behoefte aan taakondersteuning Wanneer de kennis of capaciteiten van de gebruiker onvoldoende zijn om zijn taak uit te voeren moet er een ondersteuning zijn van deze taak. Dit kan een advies functie zijn. gebruikscontext De interface en het gebruik moet aansluiten bij de verwachte situatie waarbinnen deze gebruikt wordt. Voorbeeld hiervan is dat er geen spraakinterface in een ruimte met veel omgevingslawaai. compatibiliteit Minimaliseren van het anders benoemen van noodzakelijke informatie. Het gebruiken van platform standaarden. consistentie Het consistent benoemen van informatie binnen een applicatie. context De context van een bepaalde actie aangeven. Heuristics op communicatie niveau structuur en semantiek Duidelijk de structuur van een systeem aangeven. terugkoppeling Feedback: het systeem moet informatie terug geven waarmee deze bezig is. Bij laden, hoeveel geladen is en hoeveel nog geladen moet worden, foutmeldingen en eventuele bevestiging vragen bij (systeem-)”gevaarlijke” acties. De response tijd dient zo kort mogelijk te zijn.
14
mentale belasting door dialoog De belasting bij het dialoog / informatievoorziening verminderen. Overbodige informatie vermijden. ondersteuning Verschillende componenten leveren die zowel beginnende als ervaren gebruikers tevreden stellen. informatiepresentatie (Advies) informatie moet een onderdeel zijn van de interface, aansluiten op de context waarbinnen de applicatie gebruikt wordt en duidelijk aangeven hoe een bepaalde taak uitgevoerd moet worden. De interface moet duidelijk aangeven dat er advies is over een bepaald onderwerp. flexibiliteit Het is belangrijk om gemakkelijk aanpassingen te kunnen maken aan een interface en functies.
15
Bruce Tognazzini’s First principles Anticipation Anticipate the user's wants and needs. Bring to the user all the information and tools needed for each step of the process. Autonomy
•
The computer, the interface, and the task environment all "belong" to the user, but user-autonomy doesn't mean we abandon rules.
•
Use status mechanisms to keep users aware and informed.
•
Keep status information up to date and within easy view
Color Blindness Any time you use color to convey in the interface, you should also use clear, secondary cues. Consistency [ordered from those interface elements demanding the most faithful consistency effort to those demanding the least]
•
Interpretation of user behavior.
•
Invisible structures.
•
Small visible structures.
•
The overall "look" of a single application or service.
•
A suite of products.
•
In-house consistency.
•
Platform-consistency.
Inconsistency It is just important to be visually inconsistent when things must act differently as it 0.1" when things act the same. The most important consistency is consistency with user expectations. The only way to ascertain user expectations is to do user testing. No amount of study and debate will substitute. Defaults
•
Do not use the word "default" in an application or service.
•
Defaults should be easy to "blow away."
•
Defaults should be "intelligent" and responsive.
16
Efficiency of the user
•
Look at the user's productivity, not the computer's.
•
Keep the user occupied.
•
Write help messages tightly and make them responsive to the problem.
•
Menu and button labels should have the key word(s) first.
Explorable Interfaces
•
Give users well-marked roads and landmarks. Sometimes, however, you have to provide deep ruts.
•
Offer users stable perceptual cues for a sense of "home."
•
Make Actions reversible
•
Always allow "Undo."
•
Always allow a way out.
•
Make it easier to stay in.
Fitts's Law The time to acquire a target is a function of the distance to and size of the target.
•
Use large objects for important functions (Big buttons are faster).
•
Use the pinning actions of the sides, bottom, top, and corners of your display.
Human-Interface Objects (folders, documents, trashcan, etc.)
•
have a standard way of interacting.
•
have standard resulting behaviors.
•
should be understandable, self-consistent, and stable.
Latency Reduction
•
Acknowledge all button clicks by visual or aural feedback within 50 milliseconds.
•
Display progress indicators.
•
Trap multiple clicks of the same button or object. Because the Internet is slow, people tend to press the same button repeatedly, causing things to be even slower.
•
Make it faster. Eliminate any element of the application that is not helping. Be ruthless.
17
Learnability Usability and learnability are not mutually exclusive. Decide which is the most important; then attack both with vigor. Metaphors, Use of
•
Choose metaphors that will enable users to instantly grasp the finest details of the conceptual model.
•
Bring metaphors alive by appealing to people's perceptions-sight, sound, touch, and kinesthesia-as well as triggering their memories.
Protect Users' Work Ensure that users never lose their work as a result of error on their part, the vagaries of Internet transmission, or any other reason other than the completely unavoidable, such as sudden loss of power to the client computer. Readability
•
Text that must be read should have high contrast. Favor black text on white or pale yellow backgrounds. Avoid gray backgrounds.
•
Use font sizes that are large enough to be readable on standard monitors.
•
Pay particular attention to the needs of older people.
Track State
•
Because many of our browser-based products exist in a stateless environment, we have the responsibility to track state as needed.
•
State information should be held in a cookie on the client machine during a session with a transaction service, then stored on the server when they log off.
•
Users should be able to log off at work, go home, and take up exactly where they left off.
Visible Interfaces Avoid invisible navigation.
18
Donald Norman Design Principles
1. Use both knowledge in the world and knowledge in the head. By building conceptual models, write manuals that are easily understood and that are written before the design is implemented. 2. Simplify the structure of tasks. Make sure not to overload the short-term memory, or the long term memory of the user. On average the user is able to remember five things at a time. Make sure the task in consistent and provide mental aids for easy retrieval of information from long-term memory. Make sure the user has control over the task. 3. Make things visible: bridge the gulfs of Execution and Evaluation. The user should be able to figure out the use of an object by seeing the right buttons or devices for executing an operation. 4. Get the mappings right. One way to make things understandable is to use graphics. 5. Exploit the power of constraints, both natural and artificial, in order to give the user the feel that there is one thing to do. 6. Design for error. Plan for any possible error that can be made, this way the user will be allowed the option of recovery from any possible error made. 7. When all else fails, standardize. Create an international standard if something cannot be designed without arbitrary mappings (Norman, 1988, p.189-201).
19
Evaluatie volgens Nielsen Allereerst heb ik de spraakherkenning volgens de heuristics van nielssen geevalueerd om te kijken of deze niet meer volstaat en welke heuristics meer of minder waarde hebben binnen een spraakgestuurde interface. Dit heb ik gedaan door te proberen op zo’n goed mogelijke manier deze heuristic evaluation in te vullen en de verdere uitleg er bij te zetten.
Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Gedeeltelijk ziet men wat er gebeurt, het microfoontje (figuur 1. (1)) licht op wanneer het system ‘wat’ hoort. Of deze het verstaat maakt dan verder niet uit. Verder geeft (3) aan hoe luid deze het hoort. Wanneer gaat het mis? In het plaatje van moet men een toets indrukken (esc) om het systeem te laten starten. Bij het indrukken van die toets krijgt men al direct feedback, nl. hij voelt dat de toets ingedrukt wordt. Een andere optie (fig. 2)is dat men eerst een woord zegt om de computer te laten luisteren, dit kan een bijnaam zijn van de computer of gewoon het woord computer (de gebruiker kan dit zelf kiezen. Wanneer men dit woord zegt zou de computer hiervan op de een of andere manier feedback moeten geven. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. In zekere zin is hier ook wel over nagedacht, er zijn een aantal versimpelde commando’s verzonnen, zoals “get my mail” en “show me what to say” Andere commando’s moeten op een bijna command line achtige manier worden genoemd. Bijvoorbeeld als ik mijn mac uit wil zetten; “switch to finder” “apple menu” “shut down” “shut down” 20
User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. In het geval van Apple’s osx herkenner; ja er zit een undo functie op, deze heet “cancel my last command” wat op zich handig is alleen niet werkt voor spraakherkenning. Er zitten 3 hele korte woorden in en korte woorden zijn moeilijker te herkennen voor een spraakherkenner. Op deze manier zijn er erg veel fouten mogelijk zo kan het bijvoorbeeld door een herkenner geinterperteerd worden als “can sell mile as command” een undo functie moet een woord zijn met een unieke klank die makkelijk te onthouden is. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Dit is een heuristic die moeilijk toe te passen is binnen spraakherkenning. De interface is ‘nieuw’ en het gebruik is compleet anders. De meeste standaarden zijn gebaseerd op een pointer / keyboard combinatie van input. Gelukkig is er wel onderscheid gemaakt tussen applicatie commando’s en globale commando’s. Zo blijft het sluiten van een venster, minimaliseren, maximaliseren, afsluiten van een programma altijd dezelfde commando’s houden. Verdere consistentie is veelal afhankelijk van het gebruikte programma. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Spraakherkenning is erg error gevoelig. De gebruiker zal hier rekening mee moeten houden. Errors ontstaan door omgeving, microfoon te ver weg, te veel omgevings geluid e.d. Gedeeltelijk is hier rekening mee gehouden door de gebruiker speech te laten kalibreren. Echter wanneer het gebruikt wordt en bijvoorbeeld het geluid is te zacht of te hard is dit moeilijk te zien (3) is het audio gedeelte, wanneer men de middelste 2 streepjes bereikt qua volume is het in orde, de bovenste en de onderste niet. Gezien het formaat is dit niet optimaal en verder geeft het systeem geen feedback als de gebruiker continu te hard of te zacht praat. Sommige gebruikers hebben hier zelf ook een truukje voor verzonnen om eerst een bepaalde zin (“what day is it?”) te zeggen om te kijken of ze goed herkend worden. Verder is het belangrijk dat bepaalde labels niet het zelfde klinken (in tegenstelling to een GUI waarbij ze er niet hetzelfde uit moeten zien) In het geval van OSX komt dit helaas erg vaak voor. Veel apple applicaties beginnen met i - .. (tunes/work/chat/ calendar/photo/movie) Hierdoor vergroot men het risico dat de verkeerde applicatie herkent wordt.
21
Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Hier is volledig aan voorbij gegaan bij de ontwikkeling van Speech, commando’s zijn nauwelijks zichtbaar en zitten verborgen in een lijst die alleen met de muis geopend kan worden. Deze lijst past zich ook nauwelijks aan aan de gebruiker. Veel gebruikte commando’s zijn niet zichtbaar. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Dit is in zekere zin gedaan, een expert user kan zelf ‘shortcuts’ maken voor taken die hij veel gebruikt, helaas moet hij dit dus zelf doen en gebeurt dit niet automatisch. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. De herkenner is superminimalistisch en bevat eerder te weinig dan te veel informatie. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Er kan verwacht worden dat er veel errors zullen zijn bij een spraakgestuurde interface. Met name auditieve indicatoren kunnen voor een gebruiker wel eens over het hoofd gezien worden maar door het systeem makkelijk opgemerkt (te veel achtergrond geluid, te zachte microfoon, te langzame spraak) In de meeste gevallen valt te constateren dat hier geen rekening mee gehouden wordt. Dat wil zeggen dat een gebruiker zelfs niet kan herkennen dat er een error is opgetreden. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. Wederom een redelijke standaard heuristic die ook bij spraakherkenning van toepassing is; het geniet de voorkeur om ook in deze help en documentatie bepaalde troubleshooters te hebben.
22
Usability Heuristics voor visuele spraakgestuurde interfaces. De verschillende heuristics heb ik samengevoegd tot een kortere lijst. Vervolgens heb ik alle heuristics bekeken, gegroepeerd en toevoegingen of verklaringen erbij geschren. Binnen deze heuristics stel ik de minimale heuristics waaraan een spraakgestuurde interface zou moeten voldoen. Deze heb ik opgedeeld in 4 groepen; Systeem Systeem heuristics gaan met name over technische(/hardware) aspecten. Gebruiker Gebruikers heuristics hebben de nadruk op de gebruiker. Input Input heuristics hebben betrekking op de commando’s en input die gebruikers kunnen geven aan een systeem. Output Output heuristics gaan over de feedback en informatie welke een gebruiker gepresenteerd krijgt.
23
Systeem Latency Reduction Bruce Tognazzini Acknowledge all button clicks by visual or aural feedback within 50 milliseconds. Display progress indicators. Trap multiple clicks of the same button or object. Because the Internet is slow, people tend to press the same button repeatedly, causing things to be even slower. Make it faster. Eliminate any element of the application that is not helping. Be ruthless. Vertaald naar spraakherkenning: Acknowledge all recognised or recognisable speech preferably by visual or otherwise aural feedback within 50 milliseconds. Display progress indicators. Trap multiple speech input causing things to be even slower. Make it faster. Eliminate any element of the application that is not helping. Be ruthless. Gebruikscontext TNO De interface en het gebruik moet aansluiten bij de verwachte situatie waarbinnen deze gebruikt wordt. Voorbeeld hiervan is dat er geen spraakinterface in een ruimte met veel omgevingslawaai. Toevoeging: Hieraan kan toegevoegd worden dat dit ook rekening gehouden dient te worden met de kwaliteit van de opnameapparatuur. Zowel software als hardwarematig. Het systeem dient rekening te houden met(: * Omgevingsgeluid * Variaties in volume * Lage kwaliteit (bitrate) audio
24
Gebruiker Use both knowledge in the world and knowledge in the head. D. Norman By building conceptual models, write manuals that are easily understood and that are written before the design is implemented. Match between system and the real world J Nielssen The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. Toevoeging: Taal is erg belangrijk. Voor een natuurlijke interactie moet men een taal spreken die natuurlijk is voor de gebruiker. Dit is afhankelijk van de locatie (land) maar zeker ook het domein waarbinnen een applicatie gebruikt wordt (termologie) Make the User Comfortable Using the Technology Susan L. Hura Those of us in the speech business are technophiles who enjoy using new technology for its own sake. This is not true for most users of speech-enabled applications. Users tend to care more about accomplishing their goals than about cool technology. And recall that many users have little or no experience with speech technology, so they are unsure what to expect. Compatibiliteit TNO Minimaliseren van het anders benoemen van noodzakelijke informatie. Toevoeging Dit geld niet alleen voor het benoemen van de informatie maar net zo veel als het implementeren van een spraakinterface. Volg platform standaarden voor het bedienen, opzetten, kalibreren en aanpassen van een spraakherkenner als deze gedefinieerd zijn voor andere Human Input Devices.
25
Input Design for error. D Norman Plan for any possible error that can be made, this way the user will be allowed the option of recovery from any possible error made. Help users recognize, diagnose, and recover from errors J Nielssen Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Toevoeging Dit is meer van toepassing dan bij GUI’s het geval is. Aangezien de werking van spraakherkenning meer foutgevoelig is dan die van bijvoorbeeld een toetsenbord of een muis. Vermijd gelijk-klinkende commando’s Nieuwe heuristic Probeer in alle gevallen beschikbare commando’s te kiezen die niet al te veel klinken als elkaar om zo de accuratie van het systeem te verhogen.
26
Output Recognition rather than recall J Nielssen Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Informatiebehoefte TNO De gegeven informatie moet aansluiten bij de informatie die de gebruiker nodig heeft. Make things visible D Norman Bridge the gulfs of Execution and Evaluation. The user should be able to figure out the use of an object by seeing the right buttons or devices for executing an operation. Explorable Interfaces B Tognazzini - Give users well-marked roads and landmarks. Sometimes, however, you have to provide deep ruts. - Offer users stable perceptual cues for a sense of "home." - Make Actions reversible - Always allow "Undo." - Always allow a way out. - Make it easier to stay in.
27
Test Met deze lijst heb ik een test gedaan om te zien of de heuristics duidelijk en samenhangend genoeg waren. De belangrijkste conclusie hiervan is dat de termologie van de heuristics vaak onduidelijk was terwijl de evaluator wel de gezochte aspecten van de review kon vinden. De oplossing die ik hiervoor gekozen heb is om de heuristics simpeler en korter te benoemen.
28
9 Heuristics voor visuele spraakgestuurde interfaces.
1
Reactietijd
Bevestig alle commando’s binnen 50 miliseconden. Wanneer een bepaald commando een langere tijd duurt om uit te voeren maak dit visueel zichtbaar door een voortgangsindicator en zorg er voor dat gebruikers niet hetzelfde commando meerdere keren achter elkaar kunnen geven. In alle gevallen geldt dat sneller beter is. Wees kritisch met elementen van een apllicatie die niet bijdragen maar wel vertragen.
2
Context
In welke context wordt deze applicatie gebruikt. In welke omgeving wordt de applicatie gebruikt, welke randapparatuur is er beschikbaar. Kritisch moet met name gekeken worden naar: • Omgevingsgeluid • Opname apparatuur • Spraak volume
3
Kennis en taal
Waar komt de gebruiker vandaan. Probeer altijd de geboorte (native) taal te gebruiken van de gebruiker. Houd verder rekening met het jargon wat de gebruiker hanteert. (Her-) gebruik dit jargon en vermijd het herbenoemen van informatie. Zorg ook voor dat de interface logische stappen blijft volgen welke een gebruiker zou verwachten bij het uitvoeren van een taak.
4
Uitleg en instructie
Voordat een gebruiker begint met het gebruiken van spraaktechnologie is het belangrijk om zowel het spraakmodel als de gebruiker aan elkaar te laten wennen. Veel gebruikers zijn bekend met het concept van spraaktechnologie maar zullen het zelden of nooit gebruikt hebben. 29
5
Compatibaliteit
Spraak als een Human Input Device. Net als een muis, toetsenbord, tekentablet, trackball, touchscreen e.d is spraak een human input device. Gebruik daarom platform standaarden om deze te bedienen.
6
Errors
Errors zijn onvermijdelijk, houd hier rekening mee. Geef gebruikers de mogelijkheid om fouten te identificeren en probeer zo veel mogelijk fouten zelf vast te stellen. Geef suggesties voor het oplossen hiervan en probeer zo veel mogelijk een fout door middel van dialoog te herstellen, een goede methode hiervoor is door een “bedoelde u soms: “ vraag te stellen.
7
Klank & uitspraak
Zorg ervoor dat de beschikbare commando’s niet hetzelfde klinken of er meerdere verschillende uitspraken mogelijk zijn.
8
Informatie
Laat binnen een visuele interface zien welke delen hiervan kunnen worden aangestuurd door middel van spraak. Zorg voor een duidelijke taakondersteuning; laat commando’s zien op taakniveau.
9
Locatie en navigatie
Geef de gebruiker een visuele indicatie van waar deze zich bevind binnen een applicatie of een taak. Als er meer stappen zijn, laat deze zien. Geef de gebruiker altijd een mogelijkheid om een taak volledig te annuleren. Zorg voor een undo/ongedaan maken functie.
30
Conclusie Waar ik aan het begin van deze scriptie verwacht had dat een spraakgestuurde interface een volledig andere benadering vroeg dan een niet-spraakgestuurde interface ben ik er nu achter gekomen dat het tegenovergestelde het geval is. Falende ontwerpen en interactie errors ontstaan juist door het los benaderen van een spraakgestuurde interface. Wat wel belangrijk is gebleken is het onderkennen van een andere input. Waar ik nog wel, of misschien nog meer, in ben gaan geloven is de toekomst van spraakherkenning. Het is daarom ook nu tijd dat deze ontwikkeling van een ontwikkel naar een ontwerpfase verschuift. Met deze script hoop ik daarin een eerste stap te kunnen zetten voor deze verschuiving.
31
Referenties 1. Jakob Nielsen's Alertbox, January 27, 2003: Voice Interfaces: Assessing the Potential http://www.useit.com/alertbox/20030127.html 2. Donald Norman: The psychology of everyday things ISBN: 0-465-06709-3: 1988 Basic Books 3. Mark Weiser: The computer of the 21st century SCIENTIFIC AMERICAN V.265, NO.3/SEP, P. 94, 1991 4. Don Gentner & Jakob Nielsen: The Anti-mac Interface ACM: ACM 0002-0782/96/0800. 1996 5. Apple Computer. Macintosh Human Interface Guidelines Addison-Wesley, 1992 6. Heuristics: Lessons in the Art of Automated Conversation Susan L Hura, Juli 2003, http://msdn2.microsoft.com/en-us/library/ms994624.aspx 7. Ten Usability Heuristics Jakob Nielsen, http://www.useit.com/papers/heuristic/heuristic_list.html 8. First Principles of Interaction Design Bruce Tognazzini, http://www.asktog.com/basics/firstPrinciples.html 9. TNO heuristics als gebaseerd op de indelingen en onderzoek van Williges (1997), Neerincx en Houttuin (1996) 10. Spraaktechnologie: een inleiding Louis CW Pols, Vakgroep fonetische wetenschappen, Universiteit van Amsterdam 11. Are you talking to me? Speech on Mac OSX F.J de Kermadec, 17 maart 2004 (http://www.macdevcenter.com/pub/a/mac/2004/17/ speech.html) 12. Speech Interfaces for Games FD Laramee, 2000 13. Sun Starfire: A Vision of Future Computing
1992, B Tognazzini, Sun Microsystems
32