Die Meinungen gehen auseinander. Fest steht: Damit diese Technologie von Usern angenommen wird, müssen die Anwendungen entsprechend entwickelt werden.

Was sind Voice-User-Interfaces und was war Conversational doch gleich? Mit Sicherheit hatte der ein oder andere von euch bereits ein Gespräch mit einem Sprachassistenten. Falls nicht, nehmt einfach mal euer Smartphone zur Hand und fragt Siri, S-Voice, Cortana und Co. nach dem Wetter. Damit diese Systeme auf die unterschiedlichsten Fragen und Formulierungen reagieren können, muss der Nutzungskontext entsprechend verknüpft werden. Genau das ist einer der grundlegenden Unterschiede eines CUIs zu einer grafischen Oberfläche (Graphical-User-Interface, kurz GUI).

Einem Conversational-UI könnt ihr eure Fragen stellen und bekommt die entsprechenden Antworten. Bei Verwendung eines GUIs dagegen, müsst ihr die Antwort suchen. Wie der Name schon sagt, spielt das Wort Konversation natürlich auch eine Rolle. Durch das Verständnis von natürlicher Sprache kann bei der Interaktion der Eindruck einer echten Konversation entstehen. Im Idealfall sind Voice-UIs Konversationsteilnehmer und haben Charakter.

Eine der offenen Plattformen, welche die Entwicklung solcher CUIs ermöglicht, ist Amazons Alexa. Jeder mit einem Amazon-Account hat die Möglichkeit, dieses System über Anwendungen, sogenannten Skills, zu erweitern. Für die Nutzung benötigt ihr die entsprechende Hardware, zum Beispiel einen Amazon Echo. Auch bei diesem System wird die oben genannte Verknüpfung schnell deutlich.

„Alexa, brauche ich morgen in Nürnberg einen Regenschirm?“.

Bleiben wir bei dem „Wetter-Beispiel“. Stellt euch vor, ihr möchtet wissen, ob ihr morgen einen Regenschirm benötigt. Ihr müsst euch nicht den kompletten Wetterbericht ansehen oder anhören. Stellt ganz einfach die eigentliche Frage:

„Alexa, brauche ich morgen in Nürnberg einen Regenschirm?“.

Antwort:
„Morgen wird in Nürnberg kein Regen erwartet.“

Zunächst gibt es ein paar Begrifflichkeiten zu klären, bevor wir uns ansehen, wie Alexa grundlegend funktioniert. Folgende sind auch immer Teil eines Skills.

Technisch gesehen ist ein Intent eine Funktion. Im Wetter-Skill könnte es beispielsweise einen Intent geben, der für alle Anfragen bezüglich des Niederschlags zuständig ist. Semantisch ist ein Intent die Essenz der Konversation, oder auch die Absicht des Nutzers.

Utterances sind erwartete Formulierungen der Nutzer, über die ein Intent verwendet werden kann. Utterances werden explizit mit einem bestimmten Intent verknüpft. Bei unserem Wetterbeispiel wäre das „brauche ich morgen in Nürnberg einen Regenschirm?“. Genauso könntet ihr mit „wird es morgen in Nürnberg regnen?“ danach fragen. Zwei unterschiedliche Utterances, die den gleichen Intent ansprechen.

Slots sind eine Art Parameter. Unter Angabe von Slots haben Nutzer die Möglichkeit, ihre Anfragen zu parametrisieren beziehungsweise zu spezifizieren. In unserer oben genannten Utterance sind „morgen“ und „Nürnberg“ Slots, die man durch andere Zeit- oder Ortsangaben ersetzen kann, zum Beispiel „brauche ich am 10. Juni in New York einen Regenschirm?“.

Jeder Skill ist aus zwei Komponenten zusammengesetzt, für die wir Entwickler selbst Hand anlegen müssen. Zum einen das Interaction-Model, in dem hauptsächlich die Intents, Utterances und Slots festgelegt und verknüpft werden. Darüber bildet das Interaction-Model das eigentliche User-Interface ab. Man kann diesen Teil auch als „CUI-Frontend“ bezeichnen. Es befindet sich innerhalb der Alexa-Plattform und hilft dabei, eingegangene Sprachbefehle entsprechend auszuwerten und zuzuordnen.

Wird eine Spracheingabe nun über das Echo-Gerät an die Alexa-Plattform gesendet, wird diese mit Hilfe von Natural-Language-Processing (NLP) in Text umgewandelt. Enthaltene Informationen werden analysiert und über das Interaction-Model ausgewertet.

Im Anschluss schickt Alexa diese Informationen in Textform an die im Model hinterlegte Serveradresse. Dort befindet sich der zweite Teil eines Skills, die eigentliche Logik beziehungsweise das „CUI-Backend“.

Amazon bietet mit Amazon-Web-Services (AWS) eine komfortable und schnelle Möglichkeit, diese Logik für einen eigenen Skill zu entwickeln und bereit zu stellen. Natürlich ist es auch möglich, benutzerdefinierte Server zu verwenden.

Die ausgewerteten Daten der Spracheingabe (wie zum Beispiel angesprochener Intent und Werte der Slots) müsst ihr hier verarbeiten. Je nachdem, was euer Skill tun soll, müsst ihr die entsprechenden Daten aufbereiten und ebenfalls in Textform zurück an die Alexa-Plattform senden. Diese wandelt den Text zurück in Audio und veranlasst das Alexa-Device, die Antwort über den Lautsprecher auszugeben.

Zusätzlich zur Sprachausgabe ist es auch möglich, visuelle Komponenten, sogenannte Skill-Cards, über die Alexa-App auf das Smartphone des Users zu senden. Diese Cards sind jedoch statisch und ihr habt nicht die Möglichkeit, die vordefinierten Amazon-Layouts dieser Cards zu ändern.

Wie bei grafischen Oberflächen, gilt es auch bei der Entwicklung von VUIs einiges zu beachten. Klar, ihr könnt euch eine bestehende Smartphone- oder Web-App vornehmen und versuchen, alle Funktionen der grafischen Oberfläche eins zu eins durch ein Sprachinterface zu ersetzen. Spätestens beim ersten User-Test wird wahrscheinlich klar, dass das nicht funktionieren kann. VUIs bieten viele Möglichkeiten. Ihr solltet euch jedoch immer die Frage stellen, welchen Mehrwert ihr euren Usern mit einem Sprachinterface bieten könnt.

Noch wichtiger als bei der Entwicklung von GUIs ist hier das frühe Einbeziehen potentieller Nutzer in den Entwicklungsprozess. Ihr könnt euch viele Wochen den Kopf zerbrechen, welche Formulierungen (Utterances) User wohl für euren Skill verwenden. Fest steht, jeder Mensch denkt, spricht und formuliert unterschiedlich. Daher ist es wichtig, möglichst viele Eventualitäten abzudecken. Vielleicht fragt ihr euch, ob auch kleinste Wortunterschiede spezifiziert sein müssen, oder wie viele Utterances pro Intent nötig sind. Ich habe diese Frage während eines Amazon-Alexa-Workshops gestellt und bekam als Antwort „You can never have enough utterances“.

Frühe Userbefragungen und -Tests können nicht nur neue Formulierungen und Use-Cases erschließen. Wichtig ist auch festzustellen, was für eure Skills nicht funktioniert. Was wird von Usern schlecht oder überhaupt nicht angenommen – Stichwort „fail fast“.

Neben dem, was euer Skill akzeptieren und verstehen kann, ist es ebenfalls wichtig zu überlegen, wie ihr das Verstandene nutzt und eure Antworten zurückgebt. User sind schnell gelangweilt, wenn sie bei gleicher Fragestellung immer ein und dieselbe Antwort zu hören bekommen. Wird ein Skill regelmäßig verwendet, muss man dem User nicht bei jedem Start den kompletten Willkommensgruß ausgeben und die Beispielsätze vorkauen. Stattdessen könntet ihr je nach Regelmäßigkeit der Nutzung ein „Willkommen zurück“, oder „Lange nicht mehr gehört“ verwenden. Für mehr Abwechslung ist es beispielsweise möglich, mehrere Antwortsätze zu definieren, um für jeden Durchlauf einen der Sätze randomisiert auszugeben. Und: Verpasst eurem Skill Charakter! Lasst Witz, Sarkasmus und Ironie einfließen, wenn es die Zielgruppe erlaubt. Genauso gut könnt ihr das Humorlevel eures Skills für den User einstellbar machen (à la „TARS Humor Level runter auf 40 Prozent”), um darüber dynamisch Witz in eure Ausgaben einzubauen.

Steckt man etwas Aufwand und Kreativität in die Entwicklung, können selbst simple Skills dauerhaft begeistern. Nehmt euch die Zeit, eure Skills ansprechend zu gestalten und umzusetzen. Denn letzten Endes haben wir als Entwickler auch Einfluss drauf, wie gut diese Technologie angenommen wird.