Ein benutzerfreundliches System darf nicht "egoistisch" von der ablenken:

Auf APL-USL-Wegen dem Computer entgegen

09.10.1981

Wenn auch zur Zeit vielleicht nicht eben im Brennpunkt der Diskussion, bleibt sie - nicht zuletzt auch in Zeichen breit vorrückender Mini- und Tischcomputerinstallationen - eine Frage von fortdauernder Aktualität: Wie verschaffen wir den zahllosen Fachspezialisten in den Betrieben, die zwar keine Programmierkenntnisse und -interessen haben, dafür jedoch Sachverstand, Erfahrung, Einfallsreichtum und Aufgeschlossenheit, den von ihnen oft dringend gewünschten direkten Zugang zu mehr oder weniger leistungsfähigen Rechenanlagen und den darin schlummernden Informationen?

Eine Frage, der Dr. Albrecht Blaser vom Heidelberger IBM-Wissenschaftszentrum auf dem "Forum 81" für Wissenschaft und Verwaltung in Darmstadt kürzlich interessante Aspekte abgewann (siehe zu dieser Veranstaltung auch CW Nr. 39).

Blaser erinnerte zunächst an den atemberaubenden Preisverfall der letzten Jahre, der erst so recht die Möglichkeit geschaffen habe, einen Endbenutzer für das autonome, möglichst ohne Hilfestellung durch DV-Experten ablaufende Lösen seiner spezifischen Anwendungsprobleme alle nötigen Dienstleistungen zu wirtschaftlich tragbaren Bedingungen anzubieten. Damit die Sache aber auch wirklich klappt (das Abfragen einer Datenbank zum Beispiel), sind drei Prinzipien zu berücksichtigen:

- Die kreative, produktive Arbeit soll möglichst früh beginnen, also sind wenigstens die zum Einstieg in das System nötigen Lernvorgänge für den Anfang so knapp wie möglich zu halten.

- An das System sollte man einfach herankommen können, und dann sollten besser keinerlei rein vom System her bedingte Details und Probleme also solche, die nicht auch etwas mit dem Benutzer selber oder mit seiner Anwendung zu tun haben - Aufmerksamkeit beanspruchen: Das System darf nicht "egoistisch" von der eigentlichen Anwendung ablenken.

- Die Systeme sollten in der Lage sein, sich wachsenden Ansprüchen und Fertigkeiten der Benutzer dynamisch anzupassen.

Fast wie eine allgemeine Anweisung zum Erstellen benutzerorientierter, durchschaubarer Programmabläufe hören sich Blasers Empfehlungen en detail an: Da ist davon die Rede, daß jeder Zugriff auf Daten wie auf Programme in einer verständlichen Terminologie ermöglicht werden müsse und dem Benutzer nicht "gekünstelt" erscheinen dürfe. Der Anwender müsse leicht ausdrücken können, was der Rechner nun eigentlich für ihn tun solle, während das "Wie" dann Sache der Maschine bleiben könne.

Gerade für unerfahrene Endbenutzer wird es wichtig sein, daß das System sie gegebenenfalls aktiv (von sich aus) zur Eingabe der jeweils benötigten Informationen oder Anweisungen auffordert - mittels "Prompting" also, wie dieser Vorgang so schön auf Neudeutsch heißt. Auch soll der Benutzer über "Menüs" jederzeit erfahren können, welche Aktionen er als nächste wahlweise starten kann - und welche ihm vielleicht gerade verwehrt sind.

Im gleichen Zusammenhang betonte Blaser auch die Wichtigkeit von Erläuterungen und Hilfestellungen, die jederzeit abrufbar sein und die den Benutzer über Begriffe und Wahlmöglichkeiten informieren sollten, die er noch nicht voll durchschaut. Dabei lernt er ja auch gleich, das System beim nächsten Mal noch geschickter zu nutzen.

Stark variierende Anforderungen

Laut Blaser basieren die heutigen wie die zukünftigen Anwendungen immer mehr auf Datenbank-/Datenkommunikationssystemen, und daher sei die dreifache Rolle, die der Benutzer gegenüber solchen Systemen spielen könne, besonders intensiv zu studieren. Am bekanntesten von ihnen ist wohl Rollentypus I - die "konventionelle Rolle des parametrischen Benutzers von transaktionsartigen Anwendungsprogrammen" beziehungsweise (falls diese Formulierung erklärungsbedürftig sein sollte) die Rolle des einfachen Sachbearbeiters, der etwa in der Bank Buchungen ausführt oder bei der Lufthansa Plätze reserviert.

Rolle II ist die des Anwendungsprogrammieres, der auf der Basis von bekannten Regeln und kompletten, wohlverstandenen Daten Programme erstellt, die immer wieder die gleichen, meist abteilungsintern oder lokal bedeutsamen Aufgaben bearbeiten. Typisch ist für diese Rolle, daß Entscheidungen vorprogrammierbar sind oder aber auf der Operations-Steuerungs-Ebene als Routineentscheidungen gefällt werden - beispielsweise beim Erstellen von Berichten jeglicher Art.

Rolle III schließlich ist die des Problemlösers, der Entscheidungen vorzubereiten oder gar selber zu fällen hat und der es immer wieder neu mit einmalig auftretenden, noch unstrukturierten Problemen zu tun bekommt, von denen er die Fülle aller relevanten Regeln und Zusammenhänge zumindest nicht exakt kennt. Oft liegen manche Daten auch gar nicht vollständig vor, oder es zeigt sich erst während des weiteren Gangs der Handlung, welche Informationen eigentlich auch noch ganz wichtig (gewesen) wären.

Kennzeichnend für die Arbeitsbedingungen dieses Problemlösers ist weiterhin, das das Ziel oft "unterwegs" neu definiert werden muß, will er nicht ganz in Problemstellungen ohne Lösungsmöglichkeit schlittern oder daß (aus dem gleichen Grunde) gewisse einschränkende Bedingungen neu definiert werden müssen. Bei all diesen Arbeiten, bemerkte Blaser, "fließt dann seine ganz persönliche Einstellung zum Problem in die Lösung ein." Wobei diese Lösung im einen Fall eine Investitionsentscheidung oder eine Budgetplanung sein kann, im anderen vielleicht die Wahl eines geeigeneten Standorts für die neue Filiale.

Will man vor allen den Benutzern der Gruppen II und III bei ihren Problemen helfen, so bedarf es der Organisation und Bereitstellung der notwendigen Datenbanken und genereller Programmbibliotheken sowie nicht zuletzt auch der didaktisch ansprechenden Aufbereitung der zugehörigen, erläuternden Texte. Eine Arbeit wie der Referent sagte, die "gute DV-Kenntnisse" erfordere und deshalb bei der DV-Abteilung anzusiedeln sei. Und dazu seine Sprachempfehlung APL samt APL-Programmierhilfen.

"Das heute am besten getestete System"

Blasers Ausführungen gut ergänzend, stellte sein Heidelberger IBM-Kollege Dr. Hubert Lehmann ein experimentelles System zur Abfrage und Analyse von Daten einer Datenbank in eingeschränkter natürlicher Sprache vor: "USL" (User Speciality Language). Es handelt sich dabei laut Lehmann um das bislang von allen vergleichbaren Systemen am ausführlichsten getestete Konzept, wobei die Benutzer ihre Probleme in zwei von fünf Studien tatsächlich mit dem System USL lösen konnten. Diese zwei Studien, hob Lehmann in Darmstadt hervor, umfaßten immerhin 8000 Fragen, und weitere Studien, die über die Explorationsphase nicht hinauskamen, endeten mit Fehlerraten (das heißt, die gewünschte Antwort kam nicht) zwischen 38 und 47 Prozent. Dazwischen liegen Studienresultaten bei denen zwischen acht und 13 Prozent Fehler gezählt wurden, wobei als Fehler allerdings sogar die Versager zählten, an denen eigentlich allein der Benutzer schuld hatte.

Was ist nun dieses USL-System, von dem übrigens bereits eine deutsche, eine englische und eine spanische Version existieren? USL zeichnet sich vor allem dadurch aus, daß es Anfragen in eingeschränkter natürlicher Sprache sowohl in syntaktischer wie in semantischer Hinsicht eingehend analysiert und das Ergebnis der Aufdröselei in Ausdrücke von IBMs Datenbanksprache SQL übersetzt; Ausdrücke, die dann das "System R", ein experimentelles, relationales Datenbanksystem aus dem IBM-Forschungszentrum in San José, weiterverarbeitet.

650 Grammatikregeln

Zur syntaktischen Analyse arbeitet das USL-System mit einem Schatz von 650 grammatikalischen Regeln und einem Wörterbuch von etwa 450 Strukturwörtern wie "sein", "welcher", "von" (hat nichts mit blauem Blut zu tun) und anderen. Außerdem verfügt es noch über ein anwendungsabhängiges Vokabular, das zwischen 100 und 1000 Nomina, Verben und Adjektiva umfaßt.

Ist die syntaktische Analyse eines Abfrage-Satzes abgeschlossen, beginnt USL mit der semantischen Untersuchung, wofür dem System an die 70 sogenannte Interpretationsroutinen zur Verfügung stehen. Von ihnen her gewinnt das System die zur Erzeugung des korrektem SQL-Ausdrucks nötigen Informationen; nach Auswertung dieses Ausdrucks durch "Systeme" wiederum erscheint auf dem Bildschirm dann eine Tabelle als Antwort auf die ursprüngliche Frage.

Die "Väter" des USL-Systems wollen mit ihrem Produkt vor allem DV-fremde, fachlich aber gut beschlagene Benutzer ansprechen und ihnen eine Möglichkeit zur besseren und schnelleren Nutzung vorhandener Daten geben, erläuterte Lehmann. Dabei fanden sie in mehr als 20 Jahren Entwicklungszeit heraus, daß sprachliche Entschlüsselungsprobleme sich im Kontext einer gegebenen Datenbank leichter lösen lassen als - ohne ein solches "Stützkorsett" - bei der viel problematischeren Analyse gewöhnlicher Texte der natürlichen Sprache. Das heißt praktisch, ein beschränktes Entgegenkommen an die Belange eines Computers zahlt sich im Erfolg sichtlich aus.

Apropos Entgegenkommen: Dazu gehört weiterhin, bemerkte Lehmann noch, daß die natürlichsprachliche Schnittstelle zum Datenbanksystem "anwendungsabhängig" gestaltet wird, soll der Rechner sich nicht hoffnungslos in einem Gestrüpp unüberschaubarer Semantik verheddern. Und dann ist "Entgegenkommen" halt immer auch eine Zweibahn-Straße: Es gilt letztlich stets noch zu prüfen, ob der angesprochene Benutzer den Umgang mit der Neuschöpfung nicht vielleicht doch als "unangenehm einschränkend" empfindet und sie dann vielleicht emotionell ablehnt. Was dann ja nicht so ganz der Sinn der Sache wäre.