Validation des USEKIT-Modells zur Verzahnung von Requirements Engineering und Usability Engineering hinsichtlich Unterstützung der Konstruktion multimodaler Benutzerschnittstellen

Inhaltsverzeichnis

1 Einleitung

2 Projekt USEKIT
2.1 Ausgangslage
2.2 Zielsetzungen

3 Multimodale Interfaces
3.1 Speech User Interface
3.1.1 Entwicklung und Einsatzmöglichkeiten
3.1.2 Nutzen und Chancen
3.1.3 Probleme und Herausforderungen
3.2 Technische Komponenten von SUIs
3.2.1 Spracherkennungsprozess
3.2.2 Automatische Spracherkennung
3.2.3 Dialog Management
3.2.4 Sprachausgabe

4 Usability von Multimodalen Interfaces
4.1 Qualitätskriterien von Sprachapplikationen
4.1.1 Fehlermanagement
4.1.1.1 Erkennungsfehler
4.1.1.2 Management von Erkennungsfehlern
4.1.2 Navigations- und Dialogablauf
4.1.2.1 Dialogstrategien
4.1.2.2 Strukturierung der Inhalte
4.1.2.3 Navigationsfunktionen
4.1.3 Informationsdarstellung
4.1.3.1 Wording der Sprachausgabe
4.1.3.2 Ästhetik der Sprachausgabe
4.1.3 Feedback des Systems
4.2 Verzahnungsinformationsmodell
4.2.1 Beschreibung des Verzahnungsinformationsmodells
4.2.2 Komponenten des Verzahnungsinformationsmodell
4.3 Erweiterung des Verzahnungsinformationsmodells
4.3.1 System - Level
4.3.1.1 Entscheidung Internal Action
4.3.1.2 Entscheidung (G)UI - Design
4.3.1.3 Entscheidung (G)UI - Objekte und Struktur
4.3.1.4 Entscheidung UI - Data
4.3.1.5 Entscheidung Dialog
4.3.1.6 Entscheidung Navigations-/Supportfunktion
4.3.2 Interaktion - Level
4.3.2.1 Entscheidung Interaction - Data
4.3.2.2 Entscheidung Interaction
4.3.3 Domain - Level
4.3.3.1 Entscheidung Domain - Data
4.3.4 Task - Level
4.3.4.1 Entscheidung Task
4.4 Datenvalidität des Verzahnungsinformationsmodells
4.4.1 Validierung mit Literatur
4.4.2 Validierung mit Rollensimulation
4.4.3 Unschärfe der Daten

5 Schlussfolgerungen und Ausblick

Literaturverzeichnis

Anhang A: Informationsmodell - SUI

Anhang B: Informationsmodell - Tutorensysteme

Anhang C: Informationsmodell - Voice Support Systeme im Web

Abbildungsverzeichnis

Abbildung 1: Generelle Komponenten in einem Sprachinterface

Abbildung 2: Spracherkennung

Abbildung 3: Dialog Manager

Abbildung 4: Prompt Player

Abbildung 5: Benutzergruppen eines Dialogs

Abbildung 6: Entscheidungspunkte von TORE

Abbildung 7: Komponenten Verzahnungsinformationsmodell

Tabellenverzeichnis

Tabelle 1: Häufigkeitsverteilung von Fehlerunrsachen in gescheiterten Dialogen

Tabelle 2: Inputinformationen der Entscheidung Interal Actions

Tabelle 3: Inputinformationen der Entscheidung (G)UI-Design

Tabelle 4: Inputinformationen der Entscheidung (G)UI-Objekte und Struktur

Tabelle 5: Inputinformationen der Entscheidung UI-Data

Tabelle 6: Inputinformationen der Entscheidung Dialog

Tabelle 7: Inputinformationen der Entscheidung Navigations-/Supportfunktion

Tabelle 8: Inputinformationen der Entscheidung Interaction-Data

Tabelle 9: Inputinformationen der Entscheidung Interaction

Tabelle 10: Inputinformationen der Entscheidung Domain-Data

Tabelle 11: Inputinformationen der Entscheidung Task

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Kapitel 1

1 Einleitung

Usability gewinnt in Deutschland zunehmend an Bedeutung und nimmt neben anderen Qualitätsaspekten wie Sicherheit und Zuverlässigkeit einen hohen Stellenwert bei Softwareprodukten ein. Sie erhöht nicht nur die Akzeptanz und Zufriedenheit der Kunden, sondern wirkt sich auch positiv auf den „Return on Investment“ (ROI) des Unternehmens aus [10]. Dabei erfordert die Realisierung von Usability-Kriterien eine verzahnende Anwendung von Usability Engineering und Software Engineering bei der Entwicklung von Software.

Der Problematik einer fehlenden Verzahnung beider Disziplinen widmet sich das Forschungsprojekt USEKIT. Es definiert ein Vorgehensmodell, das bei klassischen SW-Entwicklungsverfahren die Berücksichtigung von Usability-Kriterien ermöglicht und eine Integration ihrer Prozesse unterstützt.

Die vorliegende Studienarbeit ist im Rahmen des Projektes USEKIT entstanden und hat die Aufgabe, die Validität des USEKIT-Modells für die Konstruktion von multi­modalen Benutzerschnittstellen zu prüfen. Durch die rasante Entwicklung und dem derzeit verbreitetem Einsatz von Sprachanwendungen in zahlreichen Domänen nimmt hierbei insbesondere die Sprache als Modalität eine besondere Rolle ein.

War der Einsatz von Sprachapplikationen aufgrund der schwachen Erkennungsraten noch vor kurzem undenkbar, erzielt man seit 1997, nach 20 Jahren der Entwicklung, weitgehend Erfolge und einen vermehrten Einsatz von Sprachsystemen aller Art.

Die Konstruktion von Sprachapplikationen birgt dabei im Vergleich zu grafischen Oberflächen enorme Herausforderungen. Neben technologischen Restriktionen sind es Schlüsselfaktoren wie Benutzbarkeit und Akzeptanz aus Sicht der User, die über den Erfolg der Anwendung entscheiden. Längst reicht es nicht mehr aus nur die Lauffähigkeit des Systems zu garantieren, vielmehr ist die Beachtung von Usability-Kriterien gefragt. Nach [13] ist Usability das Ausmaß, in dem ein Produkt durch bestimmte Anwender in einem gewissen Nutzungskontext verwendet werden kann, um Ziele auf effektive, effiziente und zufrieden stellende Weise zu erreichen.

Diese Kriterien stellen gerade für Sprachapplikationen eine hohe Herausforderung dar, weil hier die Sprache als einzige Bezugskomponente zum User über alle Kriterien der Zufriedenheit des Benutzers entscheidet. Um diesen neuen Anforderungen gerecht zu werden, erfordert es geeigneter Vorgehensweisen, die die Aspekte des Usability Engineering (UE) und Software Engineering (SE) vereinen.

Um diesen hohen technischen und benutzerorientierten Anforderungen gerecht zu werden, wird die vorliegende Arbeit geeignete Hilfsmittel und Vorgehensweisen vorstellen. Der Aufbau gliedert sich dabei hauptsächlich in drei Teile, deren Inhalte wie folgt strukturiert sind:

Ausgehend von der Problembeschreibung heutiger Software-Entwicklung, wird das Projekt USEKIT vorgestellt, welches einen Ansatz zur nutzerzentrierten System­entwicklung definiert und damit insbesondere für klein- und mittelständische Unter­nehmen (KMU) eine Lösung für die Ausgangsproblematik einer fehlenden Verzahnung von Software Engineering und Usability Engineering bietet (Kapitel 2).

Interessant für diese Arbeit ist die Entwicklung von Multimodalen Schnittstellen, wobei insbesondere Sprachapplikationen in den Mittelpunkt der Betrachtung rücken. Vor diesem Hintergrund werden im zweiten Abschnitt die Aspekte zu derzeit existierenden Heraus­forderungen sowie eine Darstellung von Vor- und Nachteilen beim Einsatz von Sprachanwendungen die wesentlichen Inhalte bilden. Ferner werden die grundlegenden Komponenten von Speech User Interfaces vorgestellt und in ihrem Kontext kritische Punkte aufgezeigt, die bei der Umsetzung beachtet werden müssen (Kapitel 3).

Das Kapitel 4 „Usability von Multimodalen Interfaces“ bildet den Kernpunkt dieser Arbeit. Nach einer Beschreibung von Qualitätskriterien und Strategien, die zur Steigerung der Akzeptanz und Kundenzufriedenheit entscheidend sind, wird das Verzahnungsinformationsmodell vorgestellt. Als Vorgehens­modell zur nutzer­zentrierten SW-Entwicklung berücksichtigt es im Designprozess Kriterien der Benutzbarkeit und wirkt der oben beschriebenen Problematik entgegen.

Um den Einsatz für die Entwicklung von Sprachsystemen zu garantieren, wird das Modell für diesen Nutzungskontext erweitert und mit den dafür notwendigen Daten in Form von Regeln und Guidelines gefüllt (Kapitel 4).

Schließlich wird die Arbeit mit einer Zusammenfassung der ermittelten Ergebnisse und einem Ausblick für die zukünftige Entwicklung von Software Engineering und Usability Engineering abgeschlossen (Kapitel 5).

Kapitel 2

2 Projekt USEKIT

Das Projekt USEKIT^[1] definiert einen Ansatz zur nutzerzentrierten Software-Entwicklung für unternehmenskritische Anwendungen. Zielsetzung dieses Projekts ist es Wettbewerbsvorteile für Unternehmen zu sichern, indem es eine Methodik für sie bereitstellt, die den Nutzer einer Anwendung in den Mittelpunkt des Software-Entwicklungs-Prozesses stellt.

Dieses Kapitel dient dazu, ausgehend von einer Beschreibung der gegenwärtigen Vorgehensweisen und Problemstellungen bei der Software-Entwicklung, Herausforderungen und Zielsetzungen des Projekts USEKIT zu formulieren. Des Weiteren wird dargestellt, inwieweit dieses Projekt zu Wettbewerbsvorteilen in den Unternehmen beitragen kann.

2.1 Ausgangslage

Gebrauchstauglichkeit (engl. Usability) von Software spielt gegenwärtig eine größere Rolle denn je. Wurde Usability früher lediglich als „nice to have“ - Kriterium bei der Erstellung von Software betrachtet, kommt diesem Aspekt heute, einer Zeit der ständigen Mensch-Maschine-Interaktion, ein hoher Stellenwert zu. Usability ist nicht nur eng verknüpft mit Kundenzufriedenheit, sie hat auch einen wesentlichen Einfluss auf die Effizienz der Arbeitsabläufe, die mit der Software unterstützt werden. Auf diese Weise entsteht ein unmittelbarer Zusammenhang zwischen Usability und dem Return on Investment (ROI) [10].

Zunehmend erkennen auch die Unternehmen in Deutschland die Wichtigkeit von Usability^[2], ein Trend der sich in den USA, bedingt durch die stärker Konsumgüter-orientierte Branchenausrichtung, schon stärker durchgesetzt hat [18]. Längst zeigen sich Kunden nicht mehr nur mit Funktionalität zufrieden, sondern definieren darüber hinaus Merkmale wie Effizienz und Effektivität als wesentliche Aspekte in ihren Anforderungen.

Um diesen hohen Anforderungen an gebrauchstaugliche Software-Produkte sowie der Berücksichtigung weiterer Qualitätsmerkmale, wie Sicherheit und Zuverlässigkeit, gerecht zu werden, erscheint die Integration der Disziplinen Software-Engineering und Usability-Engineering unabdingbar.

Obgleich die Notwendigkeit der Integration beider Disziplinen im Entwicklungs­prozess von Software-Produkten einheitlich angenommen wird, erweist sich die praktische Umsetzung als schwierig. Hindernisse in Form eines fehlenden Verständnisses bzw. einer fehlenden Definition der Schnittstellen zwischen SE und UE, erschweren eine Verknüpfung der Verfahrensweisen beider Disziplinen.

Des Weiteren machen Terminologiekonflikte (keine einheitlichen Definitionen), unterschiedliche konstruktive Methoden sowie eine fehlende Abstimmung bestehender Evaluationsmethoden beider Ingenieurswissenschaften eine Integration nur schwer möglich [8].

Aufgrund dieser Konflikte existiert derzeit kein allgemeingültiges Vorgehen zur Integration der Disziplinen. Stattdessen müssen Unternehmen diese Verbindung immer wieder neu erarbeiten, wobei potentielle Synergieeffekte häufig ungenutzt bleiben [11]. Im folgenden Abschnitt wird deshalb das Projekt USEKIT als mögliche Lösung vorgestellt, die der oben genannten Problematik entgegenwirkt. Neben den Ziel­setzungen werden auch die Wettbewerbsvorteile dieses Projekts genannt.

2.2 Zielsetzungen

Um die Aspekte der Gebrauchstauglichkeit effizient in den SW-Entwicklungsprozess zu integrieren, ist es entscheidend ein Modell zu definieren, das die Kernaspekte des Software-Engineering und Usability-Engineering vereint. Ein standardisiertes integriertes Modell zur nutzerzentrierten Entwicklung würde die Situation der Software-Hersteller wesentlich verbessern, da es sowohl die Anwenderbedürfnisse im gesamten Entwicklungszyklus systematisch beachtet als auch einen Beitrag zur Senkung der Herstellkosten leistet [11]. Positive Effekte würden sich deshalb in einer gesteigerten Kundenzufriedenheit sowie einer gestärkten Marktposition des Unternehmens deutlich machen.

Das Projekt USEKIT verfolgt das Ziel, insbesondere für kleine und mittel­ständische Unternehmen (KMU) Methoden für eine nutzerzentrierte SE zur Verfügung zu stellen, die ihnen auf folgende Weise Wettbewerbsvorteile verschaffen sollen [25]:

- der Entwicklungsprozess wird in seiner Effizienz wegen der Nutzerzentrierung gesteigert (Senkung der Herstellkosten)
- die entwickelte Software zeichnet sich durch hohe Nutzerakzeptanz aus
- die Software unterstützt einen effizienten Arbeitsablauf und führt damit zu Wettbewerbsvorteilen beim Kunden und einem schnellstmöglichen Return on Investment
- die Beachtung der Nutzeranforderungen, der Nutzeraufgaben und des Anwendungskontext als integrativen Bestandteil der Anforderungsphase
- das Management von funktionalen Anforderungen unter Berücksichtigung von Nutzereigenschaften und Nutzeraufgaben sowie unter Beachtung des Anwendungskontext
- die Erkennung und das Management von Abhängigkeiten zwischen funktionalen und nicht-funktionalen Anforderungen (z.B. Usability)
- die Formulierung von interaktions-, benutzer- und produktzentrierten Abnahmekriterien als Bestandteil der Anforderungen, die zur Erkennung von Abweichungen der Anforderungen während der Entwicklung dienen
- den Einsatz von Usability-Techniken unter der Restriktion gegebener personeller, finanzieller und zeitlicher Ressourcen
- die durchgehende Berücksichtigung von Usability als entscheidendes Kriterium im SE-Prozess

Neben projektspezifischen Vorteilen sind durch den Einsatz des USEKIT-Modells auch langfristige Verbesserungen auf übergeordneter Ebene anzuführen. Auf der organisatorischen Ebene werden deshalb folgende Verbesserungen durch die Anwendung von USEKIT genannt [25]:

- Etablierung von Ergonomie als Marketingargument
- Höhere Stabilität der Anforderungen durch Benutzerbeteiligungen
- Aufbau und Verwendung einer Wissensbasis des Usability-Engineering (UE-Knowledge-Management)
- Möglichkeit eines Kontinuierlichen Lernens (Continuous Learning)
- Schaffung eines Bewusstseins und Verbesserung der Motivation für das Usability-Engineering bei allen beteiligten Stakeholdern

Realisiert können diese Zielsetzung durch eine Verzahnung von vorhandenen und beschriebenen Methoden des SE und UE sowie einer entsprechenden Anpassung der Prozesse an die Ressourcen und Anforderungen einer KMU [24].

Zweck dieses Projekts ist daher die Entwicklung und Erprobung eines nutzerzent­rierten Vorgehensmodells, welches dem Bedarf kleiner und mittelständischer Unternehmen nach einem einfach anzuwendenden Methodeninventars zur Förderung der Effizienz der Softwareentwicklung und zur Steigerung der Akzeptanz der entstehenden Produkte gerecht wird.

USEKIT enthält einen Baukasten aus Tools und Methoden, die flexibel angewendet und an die individuellen Rahmenbedingungen eines Software entwickelnden Unternehmens angepasst werden können. Eine besondere Herausforderung liegt dabei in der technischen und organisatorischen Integration des USEKIT-Baukastens in die bestehenden Prozesse eines Unternehmens.

Im Ergebnis dieses Projekts soll deshalb eine Sammlung aus Methoden und Tools entstehen, die problemlos in die Umgebung einer KMU integriert werden kann [11]. Auf diese Weise leistet das Projekt USEKIT einen entscheidenden Beitrag zu einer integrierten Software-Entwicklung, der in einer isolierten Betrachtung weder die Methoden des Software-Engineering noch die Instrumente des Usability Engineering gerecht werden könnten.

Kapitel 3

3 Multimodale Interfaces

Multimodale Systeme haben sich in der letzten Dekade rapide entwickelt, sodass heute ein stärkerer Fortschritt bei der Konstruktion von allgemeinen, robusten Systemen sowie von transparenten Mensch-Maschine-Schnittstellen zu verzeichnen ist, als je zuvor [2]. Die Zielsetzung bei der Entwicklung multimodaler Benutzerschnittstellen ist es, die Fähigkeiten der Anwender besser zu unterstützen und durch die Kombination verschiedener Ein- und Ausgabemodalitäten die Nutzung einfacher und effizienter zu gestalten.

Allgemein versteht man Multimodalen Interfaces als Systemschnittstellen, die den kombinierten Einsatz von multiplen Eingabemodi (auditiv, visuell, haptisch etc.) erlauben, um eine Problemstellung mit Unterstützung der Maschine zu lösen [14]. Dabei unterscheidet man nach [31] grundsätzlich zwei verschiedene Typen:

Eine kombinierte Modalität liegt dann vor, wenn die Informationen parallel aus zwei (oder mehreren) Ein- oder Ausgabemodi bezogen werden können. Dieser Typ ist sehr effizient und kann die Interaktion mit dem System stark verbessern.

Eine sequentielle Modalität ermöglicht den Wechsel zwischen verschiedenen Modi während der Ausführung einer Operation. Der Benutzer kann hier fortwährend den für ihn in einem spezifischen Interaktionskontext geeigneten Modus auswählen.

Im weiteren Verlauf dieser Arbeit werden speziell Spracheingaben als spezifische Form der Benutzerinteraktion in den Mittelpunkt der Betrachtung gezogen. Hierzu werden in diesem Kapitel zunächst allgemeine Aspekte zu Sprachapplikationen und der Aufbau sowie die wesentlichen Komponenten derartiger Systeme dargestellt.

3.1 Speech User Interface

In diesem Abschnitt werden allgemeine Aspekte zu Sprachapplikationen behandelt. Dabei werden allgemein alle Arten von Systemen betrachtet, deren Eingaben oder Ausgaben von Daten über einen akustischen Kanal erfolgen.

Nach einer kurzen Beschreibung der historischen Entwicklung von Sprachsystemen werden die verschiedenen Einsatzmöglichkeiten und eine Eingrenzung der in dieser Arbeit betrachteten Systeme aufgeführt. Darüber hinaus werden Vorteile von Spracheingaben gegenüber andern Modi herausgearbeitet, aber auch Heraus­forderungen und Probleme bei ihrer praktischen Umsetzung diskutiert.

3.1.1 Entwicklung und Einsatzmöglichkeiten

Die ersten Ideen, natürliche Sprache als Kommunikationsmittel zur Interaktion mit Computern einzusetzen, sind bereits in den 60er Jahren entstanden [19]. Damals noch als Vision deklariert, wurde die Entwicklung in den Forschungslabors seither schrittweise vorangetrieben. Bereits in den 80er Jahren reichten das Wissen und die Ressourcen der Maschinen aus, um Systeme zu entwickeln, die einige hundert Einzelwörter erkennen konnten. Die Kapazität heutiger Systeme reicht von einfacher Einzelworterkennung über kommerziell verfügbare Diktiersysteme mit einem Wortschatz von einer Millionen Wörtern bis hin zu hochkomplexen Sprachportalen für die sprecherunabhängige Erkennung von kontinuierlich gesprochener Sprache.

Einen lukrativen Anwendungsbereich stellt die Mobilkommunikation dar, die eine stetig wachsende Verbreitung mobiler Endgeräte und Services zu verzeichnen hat. So sind in diesem Kontext Sprachportale^[3] zu nennen, die als Plattform für vielseitige Angebote eingesetzt werden und die bisher bekannten Dienste sowohl in der Leistungsfähigkeit, als auch in der Komplexität der Inhalte bei weitem übertreffen [19]. Auch die bequeme Art der Interaktion bietet im Vergleich zu traditionellen Inter­aktionsformen wie Tastenmenüs (DTMF) oder graphischen Oberflächen auf kleinen Displays (Handy, PDA, Smartphone) weitere Vorteile.

Weitere Einsatzmöglichkeiten von Sprachapplikationen ergeben sich im Bereich Smart Housing, in dem das intuitive Interaktionskonzept Sprache eine wichtige Rolle einnehmen kann. Sprachinteraktionen können hier zur Steuerung von diversen Geräten (Beleuchtung, Heizung, Fernseher etc.) eingesetzt werden.

Ein anderes Anwendungsgebiet bietet die Automobilindustrie. Neben den Vorteilen der Freiheit und Bequemlichkeit bei Sprachinteraktionen werden hier weiterhin sicherheitskritische Aspekte in den Vordergrund gestellt. Einfache Bedienbarkeit der In-Car-Systeme (Navigations-, Audiosystem, Autotelefon etc.) ohne Ablenkung bzw. Einschränkung der Betroffenen während der Bedienung des Fahrzeugs lauten hier die zentralen Forderungen [19]. Diesen hohen Anforderungen kann die Verwendung von Sprache als Interaktionsmodus ohne weiteres gerecht werden.

Die gesamte Vielzahl existierender Systeme mit Sprachunterstützung kann aufgrund des beschränkten Rahmens nicht in der vorliegenden Arbeit abgedeckt werden. Der Inhalt dieser Arbeit ist aus diesem Grund primär im Kontext der In-Car-Systeme zu betrachten. Zwar können einige Aspekte auch auf andere Sprachapplikationen übertragen werden, diese werden hier jedoch nicht explizit erwähnt.

3.1.2 Nutzen und Chancen

Wie bereits im oberen Abschnitt angedeutet, ergeben sich durch den Einsatz von Sprache erhebliche Vorteile, die mit keiner anderen Interaktionsform realisiert werden können. Im Folgenden möchte ich in Anlehnung an Peissner et al. [19] die wichtigsten Eigenschaften aufzählen, die begründen, warum Sprachinteraktionen in bestimmten Situationen anderen Interaktionsformen vorzuziehen sind:

- Intuitivität

Menschen sind mit der Verwendung von Sprache vertraut, denn sie ist die natürlichste Form der menschlichen Kommunikation und wird eingesetzt, um zwischenmenschliche Informationen auszutauschen. So ist es komfortabler seine Ziele und Bedürfnisse verbal auszudrücken, als sie in Mausbewegungen zu übersetzten.

- Verfügbarkeit

Sprachsteuerung ist überall verfügbar und kann somit für einen mobilen Zugriff auf umfangreiche Inhalte und Funktionalitäten genutzt werden; dabei ist sie unabhängig vom eingesetzten System/Endgerät und kann universell eingesetzt werden.

- Effizienz

Sprache ist ein direktes Steuerungselement und kann für gezielte Aufrufe von Funktionen/Applikationen genutzt werden und somit ein mühseliges Durchlaufen von Listen-/Menüeinträgen zur Erreichung des gewünschten Funk­tionsbereichs vermeiden. Der Einsatz von Spracherkennung in Verbindung mit einer offenen Dialogstrategie ermöglicht dem User sein Anliegen direkt zu formulieren und jedes Element zielbewusst ansteuern.

- Freiheit

Sprachapplikationen sind unabhängig vom Gebrauch der Augen und Hände, sodass diese Elemente für andere Aktivitäten genutzt werden können. Hierbei sind zum Beispiel Situationen interessant, bei denen Augen und Hände auf andere Objekte gerichtet sein müssen oder unterwegs ein schneller Informationszugriff benötigt wird, bei dem die Nutzung eines kleinen Displays zu hohe Anforderungen (z.B. wegen manueller Genauigkeit) an den User stellt. Besonders im Kontext der Fahrzeug­führung, des industriellen Gebrauchs sowie bei Sichteinschränkungen kann die Sprachinteraktion deshalb einen wesentlichen Vorteil bieten.

- Aufmerksamkeit

Aufgaben, deren Bearbeitung visuelle Fähigkeiten erfordern, beanspruchen die menschlichen Kapazitäten in hohem Maße. Eine Dialogführung mittels Sprache stellt für den Menschen dagegen keine große Anstrengung dar; diese erledigt er praktisch „nebenbei“.

- Technische Anforderungen

Sprachapplikationen stellen nur minimale technische Anforderungen an das Endgerät. Wo bei einem Graphical User Interface (GUI) ein Screen, ein Keyboard oder eine Maus benötigt wird, ist bei zur Benutzung eines Sprachservices ein Telefon bzw. ein Lautsprecher und ein Mikrofon ausreichend.

- Vielfältige Einsatzmöglichkeiten

Auskunftssysteme (z.B. Fahr-/Fugplan), natürlich-sprachliche Zugriffe auf Informationen (z.B. Wetter, News), Sprachsysteme im Haus­bereich (z.B. Heizung, Heimgeräte, TV), Sprachsteuerung von In-Car-Systemen (z.B. Audio, Navigation), Support für Menschen mit Behinderungen (z.B. Sehschwäche, Einschränkung in der Mobilität) sind nur wenige der potentiellen Einsatzdomänen von Sprachschnittstellen.

Anhand dieser kurzen Aufzählung von positiven Aspekten in Sprachanwendungen wird ersichtlich, dass sich hinter der verbalen Interaktion ein hohes Potential verbirgt. Dieses kann eingesetzt werden, um einen Dialog mit dem System zu führen, wenn keine technischen Endgeräte wie Screen/Keyboard zur Verfügung stehen oder die zu ihrer Bedienung benötigten Elemente (Hand, Gestik) temporär bzw. dauerhaft behindert sind. Aber auch außerhalb dieser Situationen erweist sich die Verwendung von Sprachsteuerung aufgrund der oben genannten Aspekte als vorteilhaft.

Neben dem erheblichen Potential sind heute aber auch eine Vielzahl ungelöster Probleme und Herausforderungen im Zusammenhang mit Speech-Interfaces zu nennen, die im folgenden Abschnitt behandelt werden.

3.1.3 Probleme und Herausforderungen

Neben den angesprochenen Vorteilen des Interaktionskonzepts Sprache, erweist sich der universelle Einsatz von Speech User Interfaces wegen inhärenter Probleme als zweifelhaft. Diese sind sowohl auf Hindernisse bei der technischen Realisierung, als auch auf Schwierigkeiten bei der Informationspräsentation zurückzuführen. Die nachstehenden Kriterien bilden nach Peissner et al. [19] eine Übersicht über bisher ungeklärte Problemstellungen beim Einsatz von Sprachapplikationen:

- Unrealistische Erwartungen

Die meist idealistischen Erwartungen an die Leistungsfähigkeit der Spracherkennungssysteme führen zu einer falschen Interaktionsstrategie der Anwender. Sie erwarten eine menschenähnliche Dialogführung des Systems, jedoch sind die technischen Möglichkeiten heute weit davon entfernt Sprache zu „verstehen“ und zu interpretieren. In vielen Fällen stellt bereits die reine Erkennung des Userinputs eine große Heraus­forderung dar. Oft sind deshalb Enttäuschung und Frustration beim Nutzer die unweigerlichen Folgen einer gescheiterten Sprachinteraktion, bei der der Kunde sein Ziel nicht erreichen konnte.

- Spracherkennung

Eine wichtige Komponente bei Sprach-Interfaces ist die automatische Spracherkennung. Sie ist häufig Ursache für das Auftreten von Fehlern, da sie sehr anfällig gegenüber Anwendungen mit großem Vokabular bzw. komplexen Benutzeräußerungen ist und leicht durch den Einfluss äußerer Umweltbedingungen (z.B. Fahrgeräusche) belastet werden kann. Nicht selten führt auch die natürliche Variabilität der menschlichen Sprache zu Erkennungsfehlern im System. Oviatt [15] macht hierfür insbesondere zwei Gründe für die sprachliche Variabilität verantwortlich:

(a) Unflüssige Sprechweise (Disfluency)

Unflüssigkeiten sind anerkanntermaßen eine schwere Hürde für robuste sprachgesteuerte Systeme. Sie sind auf Aspekte wie Selbstkorrektur, falsche Satzanfänge, spontane Wortwiederholungen und Füllpausen/Füllsel zurückzuführen

(b) Hyperartikulation in Sprache (Hyperarticulation)

Hyperartikulationen sind zumeist auf Versuche des Benutzers zurückzuführen, übertrieben deutlich zu sprechen, um dem System die Erkennung der Anfrage zu erleichtern. Da sprachverstehende Systeme nicht auf die Erkennung von Hyperartikulation trainiert sind, erschweren Übertonungen, unnötig langsame oder unnatürlich deut­liche Sprechweisen die Identifikation des Benutzerinputs

- Form der Spracheingabe

Aufgrund der technischen Voraussetzungen automatischer Sprach­erkennungssysteme ist eine Einschränkung des zulässigen Benutzer­inputs erforderlich. Diese Restriktionen müssen dem User bekannt gemacht werden, damit eine effektive und möglichst fehlerfreie Nutzung der Sprachschnittstelle möglich ist.

- Individuelle Sprachunterschiede

Eine stabile Spracherkennung wird nicht selten durch interindividuelle Abweichungen in der Aussprache erschwert. Insbesondere Systeme, die von vielen Benutzern bedient werden, sind einer hohen Anzahl unterschiedlicher Dialekte und Sprechweisen ausgesetzt.

- Mangel an visuellem Feedback

Der inhärente Mangel an visuellem Feedback in Sprachinterfaces kann dem Nutzer das Gefühl geben, weniger Kontrolle über das System zu haben. Bei graphischen Interfaces kann ein neuer User das Interface ohne Zeitdruck erkunden und sich dabei Zeit zum überlegen und nachdenken nehmen; bei Sprachinterfaces muss er hingegen Systemfragen beantworten oder Dialoge initiieren, wenn er nicht einer Stille ausgesetzt sein möchte. Schweigende Pausen werden in Konversationen als unangenehm empfunden, woraus für den User der Druck entsteht schnell auf die Systemanfrage einzugehen. Nicht selten entstehen daraus Ver­haspelungen, die zur Enttäuschung der Benutzer die Wahrscheinlichkeit von Erkennungsfehlern stark erhöhen.

Neben dieser Problematik führt der Mangel einer visuellen Anzeige dazu, dass mittels Sprache weitaus weniger Daten zu einem Zeitpunkt über­mittelt werden können. Informationen, die mittels Sprache übertragen werden, sind im Vergleich zu einer visuellen Darstellung wesentlich langsamer transportierbar. Die Eigenschaft der mangelnden Persistenz bei der verbalen Informationsvermittlung erweitert die Herausforderungen, denen Designer bei der Erstellung von Sprachinterfaces ohne visuelle Feedbackkonstrukte gegenüberstehen.

- Darstellung von Informationen

Die akustische Präsentation von Informationen und Daten bei Sprach-Interfaces ist zeitraubend und erfordert eine starke Konzentration bzw. Aufmerksamkeit der Benutzer. Im Gegensatz zu einer grafischen Darstellung, hat der Anwender im Falle einer Sprachausgabe keine Kontrolle über die Reihenfolge der Informationsaufnahme. Zusätzlich ist die akustische Darbietung von Informationen kurzlebig, belastet das Arbeitsgedächtnis und erlaubt keine Vermittlung von großen Datenmengen. Diese Aspekte müssen beim Design der Schnittstelle bedacht und geeignete Lösungskonzepte integriert werden^[4].

- Darstellung der Funktionalität^[5]

Die Illustration vorhandener Systemfunktionen erweist sich unter Einsatz von Sprache als weitaus schwieriger als mit einer grafischen Darstellung. Eine grafische Oberfläche unterstützt das schnelle Erfassen angebotener Informationen und Funktionen; eine akustische Darbietung erfordert eine vergleichsweise zeitraubende sowie mental ansprechende Erfassung, weil der User sich meist den Verlauf/Inhalt der Darstellung merken muss, bevor er den gewünschten Funktionsaufruf starten kann.

- Akzeptanzprobleme

Unbefriedigende Vorerfahrungen mit Spracherkennungssystemen führen zu Vorurteilen bei den Systemanwendern und können die Interaktion mit dem aktuellen System negativ beeinflussen.

Um das negative Ausmaß der angesprochenen Problempunkte so gering wie möglich zu halten, ist es für den Erfolg einer Sprachapplikation entscheidend, sowohl die Zielgruppe als auch den Anwendungskontext im Voraus genau festzulegen.

Aufgrund der erwähnten Schwierigkeiten im Bereich der Spracherkennung, ist es derzeit nicht möglich Sprachinteraktionen universell einzusetzen. Damit erscheint die Anwendung von Sprachapplikationen nur für thematisch eng eingegrenzte Bereiche sinnvoll und kann nicht universell als Alternative zu anderen Benutzerschnittstellen aufgefasst werden [19].

3.2 Technische Komponenten von SUIs

Wie im vorangegangenen Kapitel gezeigt wurde, existieren insbesondere im Bereich der Spracherkennung eine Reihe von Problemstellungen, die einen häufigeren Einsatz von Sprachsystemen einschränken. Auch in Zukunft wird die automatische Spracherkennung (ASR) nicht fehlerfrei funktionieren [22]. Umso wichtiger ist es deshalb, die Schwachpunkte der ASR durch geeignete Techniken und Strategien beim Design von Speech User Interfaces zu kompensieren und somit negative Auswirkungen von Fehlern zu reduzieren.

In diesem Abschnitt möchte ich im Detail auf die technischen Komponenten eines Sprachinterface eingehen und ihr Zusammenspiel im Verarbeitungsprozess der Sprache erklären. Diese Elemente stellen nicht nur eine notwendige Voraussetzung für die Entwicklung von Sprachinterfaces dar, darüber hinaus entscheidet ihre Implementierung über den Erfolg der Anwendung und somit über die Zufriedenheit der Benutzer mit dem System.

3.2.1 Spracherkennungsprozess

Obwohl derzeit kein Standard im Bezug auf die Architektur von Sprachapplikationen existiert und sich die individuellen Lösungen graduell voneinander unterscheiden, gibt es gemeinsame Komponenten, die den Kern eines jeden Systems bilden. Ihr Zusammenspiel kann wie folgt dargestellt werden [3]:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Generelle Komponenten in einem Sprachinterface

Der Prozess einer Spracherkennung erfordert zunächst einen Sprachdetektor (speech detector), der die Benutzersprache identifiziert und genau angibt, wann der User seine Spracheingabe beginnt bzw. beendet. Diese Informationen dienen dem Spracherkennungssystem (speech recognition engine), das nun auf Basis des zugrunde liegenden Wortmusters eine Wort-zu-Wort-Übersetzung der Benutzer­eingabe vornehmen kann. Ist diese Übertragung erfolgt, kann der Sprachparser (natural-language parser) die erhaltenen Daten verarbeiten, indem er jedem Wort bzw. jeder Wortgruppe eine Bedeutung zuordnet.

Die resultierende Interpretation wird an den Dialogmanager (dialog manager) übermittelt, der die Aufgabe hat, die Informationen im Hinblick auf die Taskausführung zu überprüfen. In Abhängigkeit von der Vollständigkeit der erhaltenen Daten entscheidet dieser über den weiteren Fortgang des Dialogs, indem er die entsprechenden Anweisungen über das Wiedergabesystem (prompt player) ausgeben lässt.

Im Folgenden werden die markierten Elemente der oberen Abbildung genauer untersucht und ihre Aufgaben im Detail beschrieben. In diesem Kontext werden auch mögliche Interaktionsstrategien aufgezeigt, die in Abhängigkeit vom Gesamtsystem realisiert werden können und den Erkennungsprozess der Sprache beeinflussen.

3.2.2 Automatische Spracherkennung

Die Spracherkennung (speech/voice recognition) ist ein auf Software basierendes Verfahren der Sprachanalyse, bei dem ein computerbasiertes System mittels automatischer Spracherkennung (ASR) eingegebene Sprachinformationen des Benutzers hinsichtlich seiner gesprochenen Worte sowie deren Bedeutung untersucht.^[6]

Wichtig ist dabei die Unterscheidung zwischen einer simplen Erkennung und dem tieferen Verständnis der eingegeben Informationen. Letztere Fähigkeit besitzt die Spracherkennung nicht und so bleibt ihre Aufgabe auf die digitale Konvertierung sowie die Identifikation bekannter Wörter in der Benutzersprache beschränkt.

Die Erkennung und Selektion einzelner Wörter aus dem Input des Benutzers erfolgt dabei auf Grundlage statistischer Modelle, die sowohl auf dem akustischen als auch auf dem sprachlichen Level eingesetzt werden. Das Zusammenspiel der Elemente zeigt dabei die nachstehende Abbildung (veränderte Darstellung aus [9]):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Spracherkennung

Wurde eine Spracheingabe ausgeführt, so ermittelt das akustische Modell im ersten Schritt Wortkandidaten aus dem Systemvokabular, die mit höchster Wahrscheinlichkeit zu der gesprochenen Symbolfolge gehören.^[7] Um diesen Vergleich angehen zu können, liegt das Vokabular des Systems in Lautschrift vor [30].

Im zweiten Schritt schränkt das abgelegte Sprachmodell die Menge möglicher Wortkandidaten ein. In Abhängigkeit von der Sprachumgebung, die sich je nach System aus den zwei bzw. drei vorangegangenen und bereits erkannten Wörter ergibt, werden linguistische Wahrscheinlichkeiten für denkbare Satzhypothesen getroffen und somit die Auswahl passender Wörter eingegrenzt.

Unter erneuter Anwendung eines detaillierten akustischen Modells werden schließlich die Endkandidaten bestimmt und die gesamte Benutzereingabe als Text extrahiert. Dieser dient nun als Eingabe für den Interpretationsprozess, der durch die Übergabe der Textdaten an die nächste Komponente initialisiert wird.

Trotz enormer Verbesserungen auf dem Gebiet der Spracherkennung, steht man in der Praxis einer Vielzahl von Problemen gegenüber, sodass selbst hoch entwickelte Technologien derzeit noch nicht fehlerfrei funktionieren. Als Ursachen hierfür können unterschiedliche Faktoren genannt werden:

Neben sprachinhärenten Eigenschaften (z.B. Koartikulation^[8] ) sind hierbei verstärkt Störgeräusche aus der Umgebung sowie Unregelmäßigkeiten in der Sprache des Users zu nennen. Inhaltliche Selbstkorrekturen, erneute Satzanfänge sowie auf­einander folgende Wieder­holungen von Wörtern können in diesem Zusammenhang als weitere Problemfelder identifiziert werden [16]. Zuletzt kann die Verwendung von Füllwörtern („äh“, „hm“) und die sprachliche Variabilität der Nutzer im laufenden Dialog als häufig auftretende Ursache für hohe Fehlerraten beim Erkennungs­prozess des Userinputs aufgeführt werden (vgl. Kapitel 3.1.3).

Wäre eine Spracherkennungsmaschine entwickelt genug, um alle vorher genannten Fehlerursachen problemlos zu behandeln, so können dennoch Konflikt­situationen, wie Usereingaben außerhalb des Erkennungsbereichs des Systems auftreten, an denen die Technologie scheitern kann.

Insgesamt bleibt die Spracherkennung derzeit trotz steigendem Fortschritt eine unvollkommene und sensible Technologie. Diese Tatsache muss bei ihrem Design berücksichtigt und Fehler- bzw. Präventionsmaßnahmen (vgl. Kapitel 4.1.1) eingebunden werden, um der Enttäuschung des Systemanwenders entgegenzuwirken und die Akzeptanz des Sprachinterfaces zu erhöhen.

3.2.3 Dialog Management

Das Dialog Management ist die zentrale Komponente einer Sprachapplikation, die die Steuerung der gesamten Interaktion zwischen User und Sprachsystem umfasst. Ihre Realisierung hat einen starken Einfluss auf die Funktionalität sowie auf die Ein-/Ausgabespezifikationen der einzelnen Module des Sprachsystems, weswegen ihrem Design ein hoher Stellenwert zukommt.

Zu den wichtigsten Aufgaben eines Dialog Managers kann man allgemein Aspekte der Planung und Problemlösung in einer Mensch-Maschine-Interaktion zählen, die sich in Abhängigkeit vom Dialogstadium unterscheiden können.

Eine grobe Übersicht bietet die nachstehende Abbildung (veränderte Dar­stellung aus [9]):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Dialog Manager

In der frühen Phase einer Konversation kann sich das Aufgabenfeld des Managers auf die Sammlung von Informationen sowie die Beseitigung von Unklarheiten in der Anfrage des Users konzentrieren, um eine vollständige Anfrage an das angebundene Datenbanksystem stellen zu können. Hierzu muss der Dialog Manager durch Formulierungen von verfeinerten Nachfragen in der Lage sein, Zweideutigkeiten in der Anfrage des Benutzers aufzulösen, die aufgrund von Erkennungsfehlern oder unvollständigen Daten auftreten können [29].

In einer späteren Phase der Konversation kann sich der Aufgabenfokus des Dialog Managers ändern. Wurden dem Benutzer die angefragten Informationen aus der Datenbank bereitgestellt, kann es in einem nächsten Schritt nötig sein, in eine Verhandlung mit ihm zu treten. Enthält der Output der Datenbank beispielsweise eine große Anzahl an Elementen, so kann das System dem User zusätzliche Einschränk­ungen in seiner Anfrage anbieten, um seine Auswahlmöglichkeiten auf ein annehmbares Maß zu reduzieren. Der Dialog Manager muss also in der Lage sein, kontextbezogene Anfragen zu formulieren, um die Menge des Outputs einzuschränken und die resultierenden Informationen dennoch präzise am Userprompt auszurichten.

Neben diesen Operationen unterstützt das Dialog Management weitere Handlungen, um den Austausch des Benutzers mit dem System zu erleichtern. So informiert und führt es den Nutzer mit kontextbezogenen An-/Nachfragen und initiiert Sub-Dialoge, um eine Klarstellung bzw. Bestätigung der Nutzeranfrage zu erreichen. Des Weiteren assistiert es bei auftretenden Fragestellungen und bietet plausible Alternativen, wenn die gewünschten Informationen nicht verfügbar sind.

Allgemein liegt das übergeordnete Ziel eines Dialog Managers darin, eine aktive Rolle bei der Leitung der Konversation einzunehmen, um einen erfolgreichen Abschluss des Anwenders zu erreichen [29]. Das Design des Dialog Managements hängt dabei in besonderer Weise von der zu realisierenden Dialogstrategie ab, die je nach Charakteristika nicht nur Auswirkungen auf die Realisierung, sondern auch auf das Zusammenspiel der einzelnen Komponenten der Sprachanwendung haben kann. Die Wahl des richtigen Dialogansatzes hängt im Wesentlichen von der anvisierten Nutzergruppe und der geplanten Domäne ab [20].^[9]

3.2.4 Sprachausgabe

Das Ausgabesystem einer Sprachapplikation ist die Komponente des Interfaces, die den Output der angefragten Informationen an den User transportiert. Die Wiedergabe der Daten wird dabei allgemein in einem zweistufigen Prozess erzeugt, bevor sie in natürlich klingender Sprache an den Benutzer ausgegeben wird.

Den groben Ablauf der Spracherstellung zeigt hierzu die nachstehende Abbildung (veränderte Darstellung aus [9]):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Prompt Player

Ausgehend von den auszugebenden Informationen, die vom Dialog Manager extrahiert werden, wird zunächst eine Sprachgenerierung initiiert. Hierbei werden die Daten mit einem Natural Language Generator (NLG) in korrekt strukturierte Sätze geformt und der Output aus verschiedenen Komponenten zusammengesetzt.

Auf einer einfachen Ebene kann der Output durch simple Konkatenation einzelner Wörter erzeugt werden. Diese Art kann den Anforderungen einfacher Anwendungen bzw. Domänen genügen. Bei anspruchsvollen Applikationen kann ein komplexer Generationsprozess notwendig sein, bei dem die Wiedergabe durch vorangehende Planung erzeugt wird, um abgelegte Audiosequenzen einzubinden, Informationen zu verschachteln, redundante Aussagen zu eliminieren und einen natürlich klingenden Text ohne Wiederholungen zu erzeugen.

Diese in der ersten Stufe erzeugten textuellen Informationen dienen nun als Eingabe, um den zweiten Prozess der Sprachgenerierung anzustoßen. Dabei werden die Textdaten vom Speech Synthesizer verarbeitet und ein Output in Sprachform erzeugt. Hierbei sind zwei grundsätzliche Typen der Sprachausgabe zu nennen, die sich zwar nicht inhaltlich, jedoch im Bezug auf die Sprachqualität unterscheiden:

Eine flexible Art der Sprachgeneration erfolgt unter Einsatz von text-to-speech (TTS). Hierbei wandelt das System die auszugebenden Informationen schrittweise in eine synthetische Sprache um (formant synthesis).

Die Generierung mittels TTS hat den Vorteil, dass neue Wörter und Phrasen einfach in die Synthese hinzugefügt und auf diese Weise dynamische Inhalte problemlos in die Ausgabe integriert werden können. Gerade bei Anwendungen mit häufig wechselndem Sprachinhalt kann sich diese Variante als vorteilhaft erweisen.

Zum Nachteil wirkt sich bei dieser Variante jedoch die ungenügende Qualität der Sprache aus. Obwohl in der Vergangenheit starke Verbesserungen zu verzeichnen sind, bleibt das Ergebnis der TTS im Hinblick auf Klarheit, Verständlichkeit, Prosodie und Höfflichkeit der verbalen Ausdrücke vergleichsweise bescheiden.

Demgegenüber steht die Erzeugung von Sprache durch Konkatenation von vorgespeicherten Audiosequenzen (concatenative synthesis).

Dem Vorteil einer natürlich klingenden Sprache stehen hier der enorme Aufwand und die eingeschränkte Flexibilität ihres Einsatzes gegenüber. Grund hierfür ist die komplexe Erstellungsprozedur, wonach alle Ausgabeinformationen zunächst aufgenommen und in einzelnen Audiosegmenten (Worte) gespeichert werden müssen. Auf diese Weise können nur statische Daten beachtet und dynamisch entstehende Inhalte nicht ausgegeben werden.

Ein weiteres Problem entsteht bei der Gestaltung der Intonation für gesondert abgelegte Worte. Da der Tonfall eines Wortes in Abhängigkeit von der Position im Satz variieren kann, müssen hier verschiedene Fälle bei der Spracherzeugung beachtet werden. Es wäre dabei jedoch zu aufwendig jede mögliche Betonung für alle Begriffe zu speichern und ferner zu komplex eine kontextbedingte Auswahl der Intonation zu treffen [4], weshalb sich diese Form der Synthese nur bedingt für Applikationen mit großen Datenmengen eignet.

Neben diesen beiden Extremen bietet sich eine Mixform der Sprachgenerierung an. Hierbei könnten aufgenommenen Sequenzen für statische Daten zusammengesetzt und synthetische Sprachfolgen für dynamische Informationen eingespielt werden.

Obwohl Nass et al. in ihrer Studie [12] nachweisen konnten, dass die Nutzer allgemein den durchgehenden Einsatz synthetischer Sprache einer vermischten Form vorziehen (Kompetenz und Glaubhaftigkeit der durchgehenden Synthetiksprache wurde im Experiment stärker eingestuft), ist letztere Variante eine in modernen Sprachapplikationen angewandte Technik.

So empfehlen auch die Autoren aus [5], dass die Sprachausgabe als Konkatenation von Sprachsequenzen zu ge­nerieren und somit der synthetischen Sprachbildung vorzuziehen ist, falls bei der Systementwicklung die Möglichkeit einer Wahl zwischen diesen Formen besteht. Aufgrund der hohen Sprachqualität und der natürlich klingenden Sprechweise entsteht dadurch eine höhere Benutzerzufriedenheit, die als notwendige Bedingung für eine langfristige Akzeptanz der Sprachapplikation angesehen werden kann.^[10]

Kapitel 4

4 Usability von Multimodalen Interfaces

Nachdem im vorangegangenen Kapitel allgemeine Aspekte zu Sprachapplikationen und ihrer technischen Realisierung erläutert wurden, steht in diesem Abschnitt das Thema „ Usability “ im Mittelpunkt der Betrachtung.

Zunächst werden hierzu wichtige Qualitätskriterien erläutert, die bei der Entwicklung von Sprachsystemen zu beachten sind. Im zweiten Abschnitt wird ein Vorgehens­modell vorgestellt, welches das Verständnis der Gebrauchstauglichkeit beim Design von Schnittstellen fördern und die Integration von Software Engineering und Usability Engineering erleichtern soll. Ausgehend von den identifizierten Qualitätskriterien wird dieses Modell schließlich für den Fall der Sprachapplikationen erweitert und ihr Inhalt mit konkreten Usability-Regeln gefüllt.

4.1 Qualitätskriterien von Sprachapplikationen

Dieser Abschnitt dient zur Vorstellung wichtiger Qualitätskriterien, die bei der Gestaltung benutzerfreundlicher Sprachapplikationen zu beachten sind. Dabei existieren derzeit viele Beobachtungen und Guidelines, die aus verschiedenen Studien und Experimenten hervorgegangen sind.

Damit nicht alle Regeln spezifisch angesprochen und ihre Hintergründe individuell beleuchtet werden müssen, werden in diesem Abschnitt lediglich die wesentlichen Inhalte der Usability-Kriterien dargestellt. Um hier eine sinnvolle Darstellung zu ermöglichen, wurden die Richtlinien in Form einer Clusterbildung zu Kategorien von Usability-Kriterien zusammengefasst, die in den nachstehenden Teilabschnitten als Qualitätskriterien vorgestellt werden.

4.1.1 Fehlermanagement

Das Erkennen und Managen von auftretenden Fehlern im Systemdialog sind heute, wie in der Vergangenheit, zwei wesentliche Aspekte, die beim Design von Speech User Interfaces (SUI) beachtet werden müssen. Dabei ist die Bewältigung dieser Probleme nicht zwingend als ausschließliche Aufgabe des Systems aufzufassen. Sie kann alternativ ebenso vom jeweiligen Benutzer durchgeführt werden, falls die Sprachanwendung entsprechende Möglichkeiten hierfür vorsieht und erlaubt.

Derzeitige Sprachapplikationen haben aus technologischer Sicht noch nicht das Qualitätsniveau erreicht, um die Berücksichtigung eines Fehlermanagement außen vor zu lassen. Insbesondere die Schwachstellen und Probleme der automatischen Spracherkennung (ASR)^[11] sind in diesem Kontext zu nennen, die trotz enormen Fortschritts erhebliche Mängel und ungelöste Konflikte aufweisen.

Wie die Untersuchung in [23] zeigt, sind bei einer Versuchsgröße von n=1278 etwa die Hälfte aller aufgetretener Fehler auf Erkennungsfehler zurückzuführen. Daneben bilden auch durch den User bedingte Fehler, wie Anfragen außerhalb des System­bereichs (Out-of-domain requests) sowie unbegründete Abbrüche des laufenden Dialogs (Interruption of call) Hauptgründe, die einen erfolgreichen Interaktions­abschluss mit einem Sprachsystem verhindern (Vgl. Tabelle 1 [23]).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Häufigkeitsverteilung von Fehlerunrsachen in gescheiterten Dialogen

Wie diese Auflistung zeigt, sind die wesentlichen Ursachen für das Auftreten von Dialogfehlern im Bereich der Spracherkennung zu suchen. Dabei machen die diesem Bereich angehörigen Fehlerursachen (Recognition error und Out-of-domain request) gemeinsam einen beachtlichen Anteil von 63 % aller aufgetretenen Fehler aus.

Wichtig ist hierbei jedoch die Erkenntnis, dass nicht alle Erkennungsfehler zwingend und unmittelbar zum Scheitern eines Dialogs führen müssen. Beachtet man beim Design von Sprachapplikationen geeignete Behandlungs- und Ausweichstrategien, so können negative Auswirkungen von Dialogfehlern vermieden und die Akzeptanz der Benutzer erhöht werden.

Diesen Sachverhalt belegt die Studie [20], in der der Zusammenhang zwischen der ASR-Performanz und einigen subjektiven Maßen des Bedienkomforts^[12] analysiert wurde. Diese Untersuchung zeigt, dass die Bedeutung der Sprachqualität für die Akzeptanz und Benutzerfreundlichkeit meist stark überschätzt wird.

Zwar ist eine möglichst zuverlässig funktionierende Spracherkennung ein wichtiges Merkmal einer guten Sprachanwendung, in den meisten Fällen besteht hierbei jedoch keine bzw. eine lediglich schwache Verknüpfung zum empfunden Bedien­komfort des Systems [20]. In diesen Fällen sind es andere Qualitätskriterien, die die Benutzbarkeit und die Akzeptanz der Applikation maßgeblich beeinflussen.

Eine wichtige Rolle nimmt in diesem Kontext die Gestaltung der Benutzerschnittstelle ein, die durch eine Integration entsprechender Maßnahmen die Prävention bzw. die Behandlung von Fehlern ermöglichen kann. Aus diesem Grund werden im nächsten Abschnitt Maßnahmen zur Behandlung von auftretenden Fehlern vorgestellt.

Da die Mehrheit der Fehler im Bereich der automatischen Spracherkennung liegt, wird die Konzentration der weiteren Betrachtung der Managementstrategien primär auf diese Kategorie gelegt.

4.1.1.1 Erkennungsfehler

Wie bereits im oberen Abschnitt erwähnt, ist die Mehrheit auftretender Fehler bei der Mensch-Maschine-Kommunikation auf Erkennungsfehler zurückzuführen. Weil die automatische Spracherkennung auch in naher Zukunft nicht fehlerfrei funktionieren wird, ist es eine wichtige Aufgaben des SUI-Designs die Schwächen zu identifizieren und sie durch geeignete Maßnahmen zu kompensieren.

Einerseits kann ein stabiles SUI-Design das Auftreten von Konflikten präventiv vermeiden; ebenso kann es passende Korrekturmaßnahmen zur Verfügung stellen, um die negativen Konsequenzen eingetretener Fehler zu minimieren.

Bevor konkrete Strategien zur Behandlung und Prävention von Fehlern vorgestellt werden, wird zunächst eine Typisierung von Erkennungsfehlern vorgenommen. Dabei unterscheidet man grundsätzlich folgende Kategorien von Fehlern [7]:

- Rejection Error (Zurückweisungsfehler)

Zurückweisung einer Benutzeräußerung, die in einer aktiven Grammatik hinterlegt ist, d.h. eine zulässige und korrekte Benutzeräußerung wird nicht erkannt (z.B. „Ich habe Sie nicht verstanden“).

- Substitution Error (Verwechslungsfehler)

Eine zulässige und korrekte Benutzäußerung wird vom System miss­interpretiert. Das System erkennt eine andere als vom Benutzer kund­gegebene Ansage, worauf eine nicht intendierte Aktion ausgeführt wird.

- Insertion Error (Einfügefehler)

Das System reagiert auf Hintergrundgeräusche, Husten oder Räuspern des Anwenders und führt dadurch unerwünschte Funktionen aus.

- Deletion Error (Löschungsfehler)

Das System ignoriert eine sprachliche Benutzeräußerung und reagiert nicht auf seine Eingabe.

In Abhängigkeit vom Fehlertyp existieren derzeit verschiedene Ansatzpunkte, um den negativen Auswirkungen auftretender Fehler entgegenzuwirken. Dabei verteilen sich die Erkennungsfehler in der Praxis häufig auf die beiden erstgenannten Typen, weshalb der Fokus bei den im Folgenden vorgestellten Behandlungsstrategien auf diese Kategorien gelegt wird.

4.1.1.2 Management von Erkennungsfehlern

In Fehlersituationen ist es wichtig geeignete Korrekturmechanismen zur Verfügung zu stellen und damit die negativen Konsequenzen von Erkennungsfehlern möglichst gering zu halten. Geeignete Managementstrategien können in derartigen Fällen behilflich sein und werden deshalb im folgenden Abschnitt dargestellt:

(1) Deeskalationsstrategien ^[13]

Unter Deeskalationsstrategien subsumiert man allgemein jene Techniken, die es ermöglichen die Effekte auftretender Fehler zu kontrollieren und zu minimieren. Nach [28] kann man hierunter die Technik der progressiven Assistenz anführen. Danach wird im Konfliktfall schrittweise eine systeminitiierte Dialogführung^[14] eingesetzt, um den Benutzer erfolgreich durch eine Anwendung zu führen. Ausgehend von der Idee, dass nach einer wiederholten Zurückweisung des Userinputs kein Spracherkennungsfehler des Systems vorliegen kann, sondern der Anwender Probleme im Umgang mit der Applikation besitzt, wird sukzessiv eine Systemführung eingeleitet und vermehrt Hilfe zur Zielerreichung angeboten.

Statt der Wieder­holung unveränderter Fehlermeldungen, wird der Output des Systems mit dieser Technik schrittweise informativer und spezifischer gestaltet, bis das System die gesamte Initiative der Dialog­führung übernimmt. Wie auch das nachfolgende Beispiel aus [20] zeigt, ist es wichtig den Inhalt der Fehlermeldung zu variieren und zunehmend zu verfeinern, um dem Benutzer ein Gefühl der Hilfe zu geben:

1 Wie bitte?
2 Ich habe Sie leider nicht verstanden. Um zu erfahren welche Befehle zur Verfügung stehen, sagen Sie „Menü“ oder „Hilfe“
3 Ich konnte Sie leider nicht verstehen, sagen Sie „X“, „Y“ oder „Z“
4 Es liegen Probleme mit der Spracherkennung vor…

[evtl. Hinweis auf alternative Bedienmöglichkeiten, z.B. DTMF oder Verbindung mit einem menschlichen Operator]

Deeskalationsstrategien, wie der Ansatz der progressiven Assistenz sind entscheidend, um Missverständnisse zwischen dem Nutzer und System abzufangen und die Interaktion zu einem erfolgreichen Ende zu führen [20]. Falls die Möglichkeit besteht, sollten sie deshalb immer in den Dialog der Sprachapplikation integriert werden.

(2) Explizite Bestätigungsfragen

Erkennt die Spracherkennungsmaschine eine Benutzeräußerung falsch und führt eine ungewünschte Aktion aus, so ist es zunächst wichtig, dass der Benutzer bemerkt, dass ein Erkennungsfehler vorliegt. Dies kann durch die Anwendung von expliziten Bestätigungsfragen im Systemprompt garantiert werden, wodurch die vom User formulierten Kernaussagen zunächst als Frage wiederholt werden, bevor das Sprachsystem mit der Bearbeitung fortfährt. Dabei muss der Inhalt der Benutzeranfrage nicht immer als separate Fragestellung wiederholt werden; in vielen Fällen genügt es, wenn das System die wesentlichen Informationen ­der User­eingabe auf eine natürliche Art am Anfang des Prompts bestätigt.

Die nachstehenden Beispiele verdeutlichen nochmals die verschiedenen Möglichkeiten der expliziten Bestätigung (Si = System, Bi = Benutzer):

Abbildung in dieser Leseprobe nicht enthalten

Explizite Bestätigungsfragen der zweiten Art sollten möglichst vermieden werden, da sie vom Anwender oft als zeitraubende und unnötige Dialogschritte empfunden werden [20].

In kritischen Situationen, d.h. wenn Erkennungsfehler schwerwiegende Konsequenzen nach sich ziehen oder der Benutzerinput nicht mit aus­reichend hoher Gewissheit zugeordnet werden kann, ist diese Technik jedoch ein geeignetes Hilfsmittel, um dem Auftreten von Verwechslungsfehlern vorzubeugen. Durch diese Art der Rückmeldung kann der User den aktuellen Systemzustand bzw. die Ausführung des Sprachsystems beurteilen und im Fehlerfall korrigierend eingreifen, um sein gewünschtes Ziel erfolgreich zu erreichen.

(3) Unterstützung der Fehlerkorrektur

Mit der Strategie der expliziten Bestätigungsfrage wurde zuvor eine Möglichkeit beschrieben, wie man das Auftreten von Erkennungsfehlern auf natürliche Weise minimieren kann. Durch eine geeignete Formulierung des Systemprompts erhält der User die Gelegenheit die vom System erkannte Anfrage zu überprüfen und zu bestätigen. Liegt in einer Situation keine Übereinstimmung zwischen der vom User geäußerten und vom System identifizierten Anfrage vor, so ist es entscheidend, dem Benutzer entsprechende Verbesserungsmöglichkeiten zur Verfügung zu stellen und eine Fehlerkorrektur durch ihn zu unterstützen.

Menschen besitzen die Fähigkeit Fehler in einem gesprochenen Dialog schnell zu identifizieren und ohne Schwierigkeiten zu korrigieren [4], weshalb man ihnen insbesondere bei fehlerkritischen Eingaben Maßnahmen bereitstellen sollte, mögliche Erkennungsfehler direkt zu korrigieren. Idealerweise sollten sie nach erhaltenem Feedback des Systems in der Lage sein, den Fehler mit einer einzigen Äußerung und ohne Wieder­holung der ursprünglichen Eingabe zu korrigieren [20].

Eine notwendige Voraussetzung ist dabei, dass die Anwender eines Systems wissen, wie sie auftretende Fehler berichtigen können. Dieses Wissen kann bei Sprachapplikationen etwa durch eine kurze Systemeinführung (Up-Front-Introduction) sichergestellt werden.

Neben den hier vorgestellten Strategien zur erfolgreich Behandlung und Prävention von Fehlern, existiert in der Praxis eine Vielzahl von weiteren Techniken des Fehlermanagements. Aufgrund des beschränkten Umfangs dieser Arbeit konnten jedoch nicht alle Strategien erwähnt werden, so dass an dieser Stelle auf weiterführende Lektüren^[15] verwiesen sei.

4.1.2 Navigations- und Dialogablauf

Dieses Qualitätskriterium umfasst alle Aspekte, die die Wahl einer geeigneten Dialogstrategie, die Strukturierung der Inhalte sowie die Gestaltung grundlegender Steuerungsfunktionen betreffen. Die Inhalte der einzelnen Aspekte werden in den folgenden Abschnitten behandelt.

4.1.2.1 Dialogstrategien

Die Wahl der Dialogstrategie ist entscheidend für die Bedienbarkeit einer Sprach­applikation. Bei der Gestaltung stehen dem Designer grundsätzlich zwei Strategien zur Verfügung, die er für seine Anwendung realisieren kann.

Zunächst gibt es die systeminitiierte oder direkte Dialogführung, die sich durch eine starke Benutzerführung auszeichnet. Das System übernimmt in diesem Fall die Kontrolle über die Interaktion und fragt schrittweise alle Informationen, die zur Ausführung einer Transaktion relevant sind, durch vordefinierte Fragestellungen ab.

Die Autoren von [29] treten in diesem Zusammenhang den Vergleich mit einer Touch-Tone-Implementierung eines Interactive Voice Response Systems (IVR) an, bei der der Nutzer seine Auswahl nach einer Aufzählung möglicher Optionen per Tastenauswahl treffen kann. Auch bei der systeminitiierten Dialogführung werden dem Benutzer zunächst alle verfügbaren Auswahlmöglichkeiten in Form eines Menüs präsentiert oder gezielte Abfragen nach Informationen formuliert. In Abhängigkeit des zu erreichenden Ziels kann dieser dann die gewünschte Systemfunktion auswählen und ihre Ausführung per Spracheingabe initiieren.

Probleme ergeben sich bei diesem Ansatz, wenn die Anwendung eine große Auswahl auszuführender Optionen beinhaltet. In diesem Fall muss der Benutzer eine Vielzahl an Menüpunkten durchlaufen, um sein Zielfunktion zu erreichen.

Ein weiterer Nachteil ergibt sich dann, wenn das System heterogene Nutzergruppen unterstützen muss. Zwar bietet sich diese Art der Dialogführung für unerfahrene Anwender an, weil diese Schritt für Schritt zum ihrem Ziel geführt werden; erfahrene User oder Experten leiden jedoch an der vergleichsweise langsamen Interaktionform, so dass für diese Personengruppen andere funktionelle Möglich­keiten für eine schnellere Aufgabenerfüllung bereitgestellt werden müssen.^[16]

Als Vorteil sehen Peissner et al. [20] den geringen Lernaufwand für die Bedienung derartiger Systeme, da dem Nutzer stets alle möglichen Aktionen und Sprachbefehle dargeboten werden. Insofern kann diese Strategie erfolgreich eingesetzt werden, wenn unerfahrene User in Kontakt mit der Applikation treten oder eine sequentielle Abfolge von Informationspakten zur Ausführung einer Systemfunktion benötigt wird. Zuletzt ist die systeminitiierte Dialogführung den anderen Strategien auch aus technischer Sicht vorzuziehen. Durch die begrenzte Menge freier Nutzeräußerungen bleiben die Anforderungen an das System der Spracherkennung gering, so dass man in diesem Fall von niedrigen Fehlerraten ausgehen kann.

Diesem Extrem steht der benutzerinitiierte Dialogansatz gegenüber, der dem User völlige Freiheit im Bezug auf seine Äußerungen gewährt. Gemäß dem Prinzip Command & Control hat er die Möglichkeit alle verfügbaren Funktionen des Systems zu beliebigen Zeitpunkten aufzurufen, ohne sich dabei an festgelegten Menü­strukturen zu orientieren. Das System nimmt während des Dialogs eine passive Stellung ein und meldet sich lediglich dann, wenn eine Bestätigung oder Klärung des Benutzerinputs notwendig ist. Ermöglicht wird diese Art der Dialogführung, weil einzelne Wörter oder in die Grammatik eingebundene komplexe Äußerungen vom Spracherkennungssystem als Befehle erkannt werden [20].

Im Vergleich zum systeminitiierten Ansatz, stellt diese Art der Dialogführung einen höheren Aufwand für den Nutzer da, weil ihm vor seiner Eingabe eine Auflistung aller möglichen Befehle verwehrt bleibt. Konflikte treten dann auf, wenn der User sich im Unklaren darüber ist, welche Fähigkeiten bzw. Funktionalitäten des Systems er in bestimmten Situationen beanspruchen kann. In derartigen Fällen kommt es schnell zur Frustration des Anwenders, weil das System standardmäßig nicht auf lange Pausen in der Eingabe oder auf falsche Befehle des Benutzers reagieren kann.

Trotz dieser Hemmnisse können benutzerinitiierte Ansätze weitaus effektiver genutzt werden, da eine strikte Folge der Menüstruktur nicht zwingend eingehalten werden muss. Stattdessen kann der Benutzer seine Zielfunktion direkt initiieren, wodurch die Flexibilität und individuelle Steuerbarkeit der Applikation erhalten bleibt.

Neben den zuvor beschriebenen Strategien, existiert auch eine Mischform, die als Mixed-initiative Dialog bezeichnet wird. In Anlehnung an die Mensch-Mensch-Kommunikation, bei der im Verlauf eines Dialogs idealtypisch ein Wechsel der Dialoginitiativen zwischen den Gesprächspartnern erfolgt, versucht dieser Ansatz die Vorteile der systeminitiierten und benutzerinitiierten Dialogführung zu vereinen.

Machen erfahrene oder geübte Anwender vom System Gebrauch, so bietet sich ein benutzergeführter Dialog an, damit eine direkte Befehlausführung ohne mühseliges Durchlaufen langer Menüs gestartet werden kann. Der benutzerinitiierte Dialog kann auch dann passend sein, wenn der Benutzer zusätzliche Informationen vom System benötigt oder falsche bzw. falsch erkannte Eingaben korrigieren will.

Oft ist aber auch ein systeminitiierter Ablauf wünschenswert. Dies ist genau dann der Fall, wenn im Dialogablauf eine Konfliktsituation entsteht, die z.B. auf (wiederholte) Erkennungsfehler des Systems, auf Unklarheit der Benutzereingabe oder auf In­formationsmangel des Benutzers zurückzuführen ist. In diesen Fällen übernimmt das System die Initiative und führt den Benutzer schrittweise durch den Dialog.

Wie die obigen Ausführen zeigen, ist die Wahl des richtigen Dialogansatzes wesentlich von der anvisierten Nutzergruppe abhängig. Ziel des Dialogdesigns ist es dabei möglichst alle Benutzergruppen zu berücksichtigen und entsprechende Maßnahmen bereitzustellen. Nur ein flexibles Dialogdesign kann hierbei den heterogenen und gegensätzlichen Bedürfnissen gerecht werden.

Abschließend zeigt die Abbildung aus [19] die zu unterscheidenden Benutzergruppen eines Dialogs (Novice User, Power User) und ihre spezifischen Anforderungen an das System.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Benutzergruppen eines Dialogs

4.1.2.2 Strukturierung der Inhalte

Neben der Auswahl einer geeigneten Dialogstrategie ist für die Bedienbarkeit eines Systems die Strukturierung der angebotenen Inhalte entscheidend. Insbesondere bei menübasierten Sprachapplikationen ist es dabei von besonderer Bedeutung, dass die Gestaltung und Ausführung der Inhalte in einer dem Benutzer intuitiven und verständlichen Weise erfolgen.

In der Praxis bietet sich zur Strukturierung der System­funktionen meist eine hierarchische Gliederung an. Hierbei ist es wichtig, ein klar erkennbares Ordnungsprinzip zu realisieren und die Inhaltsstruktur derart anzulegen, dass häufig genutzte Benutzerziele möglichst schnell und einfach erreicht werden können [20].

Gleichzeitig ist zu beachten, dass die Navigationsstruktur die Fähigkeiten des Users nicht überfordert. Besonders Sprachapplikationen stellen hohe auditorische und kognitive Anforderungen an den Nutzer, weshalb die Gestaltung der Menüinhalte in geeigneter Weise umgesetzt werden muss. Entscheidend ist in diesem Kontext die Anzahl der vom System angebotenen Funk­tionen, die dem Benutzer zu seiner Ziel­erreichung angeboten werden. Abhängig von der Applikation und der Formulierung der Auswahloptionen kann hier eine Menge von fünf bis sieben Items als oberes Richtmaß für eine Auswahlebene definiert werden. Ist dieses Maß aufgrund des großen Funktionsumfangs eines Systems nicht realisierbar, so müssen logisch zusammenhängende Inhalte in einem Cluster erfasst und in Submenüs geordnet werden. Auch in diesem Fall gilt, dass die Anzahl der Submenüs beschränkt bleibt, so dass weder Breite noch Tiefe der Navigationsstruktur den Benutzer überfordern.

Um alle genannten Kriterien bei der Dialog- und Navigationsstruktur zu realisieren, ist es hilfreich sich an den Erwartungen potentieller Nutzer eines Systems auszurichten. Die Erwartungen sowie bereits existierende Prozesse aus der realen Welt geben entscheidende Hinweise, wie eine benutzerfreundliche Struktur der Schnittstelle generiert und die Akzeptanz erhöht werden kann.

4.1.2.3 Navigationsfunktionen

Die benutzerfreundliche Gestaltung von Navigations- und Dialogabläufen stellt hohe Anforderungen an den Designer. Um den Erwartungen der Anwender gerecht zu werden, sollten dabei die nachstehend vorgestellten Steuerungsfunktionen beachtet und falls möglich bei der Implementierung des Systems realisiert werden.

Die wichtigste Funktionalität, um dem Benutzer die Kontrolle über einen Sprach­dialog zu ermöglichen, bietet „ Barge-In “. Diese Funktion gibt dem Anwender die Gelegenheit laufende Ansagen des Systems jederzeit zu unterbrechen und den Zeitpunkt seiner Eingabe selbst zu wählen.

Unterstützt das System diese Funktion, so gibt sie dem Benutzer die Möglichkeit die Interaktion zu beschleunigen, indem bereits bekannte Ansagen des Sprachsystems übersprungen werden können. Je nach Erfahrungsgrad des Nutzers können somit zeitaufwendige Sprachinteraktionen mit Barge-In verkürzt und Erkennungsfehler schnell und einfach korrigiert werden.

Ist eine solche Funktion nicht im System implementiert, so müssen dem Benutzer klare und verständliche Anhaltspunkte geliefert werden, wann er mit seiner Anfrage beginnen bzw. fort­fahren kann. Diese Navigationsfunktion wird als „ Turn-Taking“ bezeichnet und ist eine notwendige Bedingung, um die Interaktion zu erleichtern. Sie ist ein unverzichtbares Feature, um dem Anwender mitzuteilen, wann das System für die Aufnahme seiner Eingaben bereitsteht.

Weitere grundlegende Steuerungsfunktionen, die den Fluss der Interaktion positiv beeinflussen sind beispielsweise „ Abbrechen “, „ Weiter “, „ Wiederholen “ und „ Zurück “. Diese Funktionen geben dem Benutzer eine starke Kontrolle über den Dialog und verbessern die Steuerbarkeit eines Sprachdialogs in hohem Maße.

Gleichzeitig helfen sie auftretenden Erkennungsfehlern entgegenzuwirken und sind damit im Kontext der Fehlerprävention interessant. Hat ein User die Anfrage des Systems nicht verstanden oder ist eine Fehleingabe erfolgt, so besteht mit diesen Schlüsselwörtern die Möglichkeit einzelne Schritte zu wiederholen und Folgefehler zu vermeiden. Somit können unerwünschte Systemprozesse, die aufgrund von Erkennungsfehlern initiiert wurden, abgebrochen und die gewünschte Ausführung gestartet werden. Schließlich kann auch die Wiedergabe umfangreicher Inhalte kontrolliert und auf die persönlichen Bedürfnisse angepasst werden [20].

4.1.3 Informationsdarstellung

In diesem Abschnitt werden Kriterien beschrieben, die im Zusammenhang mit der Informationsdarbietung stehen und damit die Akzeptanz der Benutzer direkt beeinflussen. Unabhängig davon, welche Form der Sprachausgabe^[17] eingesetzt wird, müssen im Vorfeld Festlegungen getroffen werden, die neben der Wahl passender Bezeichnungen (Wording) auch äußere Merkmale („Ästhetik“) und die inhaltliche Ausgestaltung der Sprache betreffen.

Diese spezifischen Problembereiche sind bei der Interaktion mit dem Sprachsystem zu beachten und werden im Folgenden näher betrachtet.

[...]

---

^[1] Das Projekt USEKIT wird durch das Bundesministerium für Bildung und Forschung (BMBF) unter dem Kennzeichen 01|SC23 gefördert. Das Projektkonsortium wird von der PSIPENTA Software Systems GmbH geleitet und setzt sich aus den Forschungsinstituten Fraunhofer IESE, Institut für Technologie und Arbeit und dem Unternehmen DaimlerChrysler AG zusammen. Weitere Informationen erhalten Sie unter http://www.usekit.de.

^[2] Eine detaillierte Evaluation über die Wichtigkeit von Usability für Softwareunternehmen zeigt der Branchenreport Usability 2003 in [21].

^[3] Unter Sprachportalen werden Systeme verstanden, die über Telefon den Zugang zu Informationswelten schaffen. Nähere Informationen zu Sprachportalen finden man unter [27].

^[4] Eine Möglichkeit zur effizienten Darstellung von großen Informationsmengen wird in Kapitel 4.1.2 vorgestellt

^[5] Mögliche benutzerfreundliche Techniken zur Darstellung der Funktionalität bei Sprachschnittstellen werden in Kapitel 4.2.1 erläutert.

^[6] Diese Definition ist eine abgewandelte Definition von „Spracherkennung“ aus [32].

^[7] Die Wahrscheinlichkeit für jedes Wort wird dabei über Hidden-Markow-Modelle ermittelt; hierauf wird jedoch nicht näher eingegangen, weil die Betrachtung im Rahmen der Arbeit zu weit führen würde. Für interessierte Leser sei deshalb auf die Literatur zum Thema „Speech Recognition“ verwiesen.

^[8] Danach ist die akustische Realisierung eines Lautes abhängig von den vorangegangenen und den nachfolgenden Lauten, was dazu führt, dass die Aussprache des gleichen Wortes in Abhängigkeit von der Satzstellung variieren kann.

^[9] Derzeit existieren in der Praxis zwei grundlegende Strategien, deren Inhalte und Unterschiede ausführlich in Kapitel 4.2.1 behandelt werden.

^[10] Um eine Vorstellung über die Unterschiede in den Sprachqualitäten zu erhalten kann eine Online-Demo des Unternhemnes AT&T unter [33] abgespielt werden. AT&T ist aktiv an Innovationen im Breich der automatischen Spracherkennung und Text-to-Speech Produkten beteiligt; für ihre Leistungen wurde es in der Vergangenheit bereits mit mehreren Awards (Technology of the year, Best Desktop TTS Solution etc.) ausgezeichnet.

^[11] Nähere Ausführungen zur automatischen Spracherkennung wurden im Kapitel 3.2.2 erläutert.

^[12] Getestet wurden in der genannten Studie die Kriterien Anstrengung, Zeitaufwand, Frustration, Nutzen und Spaß mit der Bedienung des Systems.

^[13] Dieser Begriff wird von Fischer in [6] geprägt.

^[14] Details hinsichtlich einer systeminitiierten Dialogstrategie werden in Kapitel 4.1.2 erläutert.

^[15] Detailliertere Ausführungen zu Fehlerbehandlungsstrategien werden in [20] und [4] dargestellt.

^[16] Strategien und Möglichkeiten, um eine Interaktion mit erfahrenen Usern zu beschleunigen, werden im Abschnitt 4.2.1.3 vorgestellt.

^[17] Die zwei Arten der Sprachausgaben (Text-to-Speech, Recorded Speech) wurden bereits im Abschnitt 3.2.4 vorgestellt und gegenübergestellt.