Grafische Benutzeroberflächen gelten heute als Inbegriff der modernen, anwenderfreundlichen Datenverarbeitung. Im PC-Bereich sind sie längst eine Selbstverständlichkeit geworden und inzwischen wird im sogenannten Unix-Streit über fast nichts anderes gesprochen. Im Großrechner-Bereich jedoch, wo immer noch der Großteil der Datenverarbeitung stattfindet, ist von Bedienerfreundlichkeit bislang kaum die Rede. Dort deutet so mancher Profi angenehme Oberflächen immer noch als Krücken für DV-Analphabeten. Anderer Meinung ist hier Albert Höcherl von der Datenzentrale in Baden-Württemberg. Er hat eine Möglichkeit gefunden, PC-Bediener-Komfort auch an Großrechner-Terminals zu realisieren. Alfred Heuser von der Baugesellschaft Bilfinger setzt dagegen auf eine künftige Standardoberfläche unter Unix, während sich Alfred Baumann von der IOT Gedanken darüber macht, welche Qualitäten der Anwender von grafischen Oberflächen erwarten kann.
Alfred Heuser,
EDV-Leiter bei der weltweit tätigen Baugesellschaft Bilfinger und Berger AG in Mannheim.
Grafische Oberflächen setzen wir derzeit nur im Konstruktionsbereich für Computer Aided Design (CAD) ein und zwar ausschließlich unter Unix.
Nach unserer DV-Strategie ist der Einsatz des zentralen Rechenzentrums vor allem für den kaufmännischen Bereich vorgesehen, während wir bei der dezentralen Datenverarbeitung auf Unix setzen. PCs verwenden wir nur für Anwendungen, bei denen noch keine geeignete Unix-Software auf dem Markt ist.
Wir halten grafische Oberflächen für eine Basistechnologie der Zukunft - nicht nur für CAD. Aus diesem Grund findet in diesem Bereich unser nächster Technologiesprung statt.
Allerdings haben wir im letzten Jahr kräftig in Unix investiert, so daß der Schritt zu den grafischen Oberflächen bei uns erst in vier bis fünf Jahren ansteht.
Diese Situation gibt uns jedoch Zeit, gelassen darauf zu warten, welche Oberflächen-Standards sich aus dem derzeitigen Unix-Streit herauskristallisieren.
Heute werden in den verschiedenen Umgebungen noch unterschiedliche Oberflächen benutzt, was für den Benutzer langfristig nicht zumutbar ist. Deswegen orientieren wir uns in eine Richtung, die möglichst umfassend ähnliche Oberflächen zu bieten verspricht. Ich denke, im Unix-Bereich kann man in dieser Beziehung recht optimistisch in die Zukunft blicken.
In der IBM-Welt der Mainframes zeigt sich hier jedoch eine Kluft. So verspricht die Office-Division der IBM zwar die Unterstützung von AIX, doch in bezug auf Oberflächen sehe ich kein Eingehen auf irgendwelche Standardisierungs-Vorschläge, wie sie etwa von der Open Software Foundation kommen. IBM stellt offensichtlich ihr SAA-Projekt in den Vordergrund. Hier stehen sich zwei Welten gegenüber, die wohl so schnell nicht zusammenfinden.
Innerhalb der SAA-Welt scheint es jedoch - glaubt man den Ankündigungen der IBM - Anstrengungen zu geben, die Anwendungen in eine einheitliche Oberfläche zu integrieren. Für uns wäre ein solcher Weg nur akzeptabel, wenn er sich auf die Unix-Welt ausdehnen ließe. Doch SAA gehört zur IBM-Welt, und der traue ich ganz einfach nicht. Zu viele von Big Blue groß ankündigte Projekte sind inzwischen gestorben. Der Weg über Unix ist deshalb aus meinem Blickwinkel in jedem Fall vorzuziehen.
Im Großrechnerbereich wird es auch bei uns künftig nicht die volle Window-Funktionalität geben, wenn wir nicht unsere seit Jahren festgelegten Dialoganwendungen mit Masken und Benutzerführung aufgeben wollen. Langfristig sehen wir im Großrechner vor allem eine Back-end-Maschine für Datenbankanwendungen. An den Arbeitsplätzen werden dagegen Unix-Systeme stehen, die über eine Emulation auf den Host zugreifen.
Doch man muß die Diskussion um Benutzeroberflächen auch im Zusammenhang mit der Hardware betrachten. Ich glaube, der Trend geht hier - unabhängig von Unix - in Richtung der grafikfähigen X-Terminals, die in einem Netz auf der Basis von Standard-Protokollen wie TCP/IP arbeiten.
Alfred Baumann,
Berater beim Institut für Organisationsforschung und Technologieanwendung in München
Grundsätzlich profitiert jeder Computerarbeitsplatz von einer grafischen Benutzeroberfläche. Über den größeren Bedienkomfort beim Anwender ergeben sich für den Betrieb Einsparungen für Sculungsmaßnahmen und eine bessere Ausnutzung der Softwarefunktionaltität. Dabei variiert der Nutzeffekt der grafischen Oberfläche je nach Anwendung und Qualifikation der Benutzer.
Von den Vorteilen einer grafischen Benutzeroberfläche ziehen Anwender, die mit mehreren Programmen arbeiten, in höherem Maße Nutzen als solche, die nur mit einer Aufgabe betraut sind. Ausschlaggebend ist das einheitliche "look and feel" unter dem das Erlernen verschiedener Anwendungen erleichtert wird. Einen weiteren Vorteil bieten die erweiterten Möglichkeiten zum Datenaustausch durch die Clipboards mit deren Hilfe Texte, Grafiken und Tabellen in Mischdokumente integriert werden können.
Für Computerlaien, wie es Führungskräfte in der Regel sind, tritt zudem ein "Veredelungseffekt" ein. Den Anwendern wird zum Beispiel bei Apple/Macintosh-Rechnern eine symbolisierte Schreibtisch-Oberfläche (Desktop) als Arbeitsumgebung offeriert, innerhalb derer sie sich durch ihre Büroerfahrung zurechtfinden können.
Außerdem existiert noch eine zunehmende Zahl von Arbeitsplätzen, die sozusagen eine natürliche "Nähe" zum Prinzip grafischer Benutzeroberflächen aufweisen. Auf immer mehr PCs und Workstations werden Anwendungen wie Computer Aided Design (CAD) und Desktop-Publishing (DTP) realisiert. Grafische Oberfläche und Anwendung kooperieren hier geradezu zwangsweise. Ein pragmatisches Beurteilungskriterium für die Qualität von Oberflächen verbirgt sich hinter der Frage: Welche Anwendungen laufen darauf? Nach diesem Kriterium schneiden die meisten Olberflächenkonzepte reichlich schlecht ab, egal ob sie nun MS-Windows, 2 Presentation Manager, Motif oder Open Look heißen. Lediglich für das Macintosh User Interface existiert eine umfangreiche Palette von Anwendungsprogrammen. Die Hardware dafür ist jedoch teuer und liegt abseits der sogenannten Industriestandards.
Für DOS-Rechner lassen sich zwar bereits für wenige hundert Mark Programmaufrufsysteme erwerben, die dem Anwender die spartanische Betriebssystem-Oberfläche erspart, doch von einer grafischer Oberfläche muß mehr erwartet werden. Von einer solchen läßt sich im technisch anspruchsvollen Sinne erst sprechen wenn sie über mehrere Anwendungsprogramme hinweg eine einheitliche Benutzerschnittstelle mit
mausgesteuertem Fenstersystem bietet. Zu den technischen Anforderungen gehört auch, daß die Oberfläche die Möglichkeit des Multitasking bieten kann. Oberflächen wie Motif bieten darüber hinaus die Möglichkeit der verteilten Ressourcennutzung.
Ein zentrales Kriterium für die Qualität einer Oberfläche liegt jedoch in den Fähigkeiten der Selbstbeschreibung, der Erlernbarkeit und der effizienten Bedienung.
Von besonderer Bedeutung sind Oberflächen im Unix-Umfeld. Das relativ einfache Betriebssystem MS-DOS läßt sich durchaus auch von einem Nicht-Computerspezialisten bedienen. Bei dem Multiuser-/Multitasking-System Unix mit seinen über zweihundert Bourne-Shell-Kommandos mit all ihren Attributen ist das nicht mehr der Fall. Eine grafische Oberfläche wäre hier mehr als nur hilfreich, zumal der Erfolg des Unix-Betriebssystems mit der Standardisierung einer Benutzeroberfläche eng verbunden ist.
Albert Höcherl,
Fachbereichsleiter der Datenzentrale Baden Württemberg
Das Thema Benutzeroberfläche hat viel mit dem gesetzlichen Auftrag der Dezentrale zu tun, landeseinheitliche DV-Verfahren - und damit auch einheitliche Benutzeroberflächen und Masken - für den kommunalen Bereich zu entwickelt. Diese Verfahren werden nahezu flächendeckend über die sieben regionalen Rechenzentren von den 1111 Gemeinden und Städten sowie von den 35 Landkereisen in Banden-Württemberg eingesetzt.
Die Diskussion um einheitliche Masken beginnt bei ihrer Erstellung. Ein wichtiger Schritt war hier für uns die Umstellung von Batch- auf Dialog-Verarbeitung. Dafür haben wir uns ein Runtime-System zugelegt, das sich in unsere bisherige Entwicklungs-Software, die schon über eine angenehme Oberfläche verfügt, einbinden ließ. Außerdem erspart die Arbeitsweise des Runtime-Systems den Programmierern die genaue Kenntnis des Transaktions-Monitors CICS, mit dem wird arbeiten.
Für den Programmierer bleiben die CICS-Anweisungen hinter Makros verborgen, so daß er nur die gewünschten Funktionen eingeben muß. Die Übersetzung in CICS-Befehle und die Dialogablaufsteuerung übernimmt dann ein Precompiler beziehungsweise das Runtime-System. Zum einem blieb also die vertraute Entwicklungs-Oberfläche erhalten und zum anderen war kein besonderer Schulungsaufwand für CICS nötig
Oftmals besteht der Wunsch, ständig benötigte Informationen über ein Fenster konstant am Bildschirm zu halten. Ermöglicht wird der Entwurf solcher PC-ähnlicher Masken mit dem Map-Handler-System (MHS), das zu dem bei uns eingesetzten Runtime-System gehört. Anwender können dann Fenster und Pull-down-Menüs auf ihr 3270-Terminal holen wenn auch nicht mit der Maus.
Unter CICS muß man in einem solchen Fall den Schirm oder das Menü verlassen, sich die benötigte Information über ein zweites Menü anzeigen lassen, um schließlich wieder ins Ausgangsmenü zurückzublättern. Das ist umständlich und birgt die Gefahr, die eben geholte Information beim Zurückblättern wieder zu vergessen.
Der Map-Handler arbeitet mit einem logischen Bildschirm von beliebiger Größe, in dem die Entwickler Masken und Fenster definieren können. Später werden die Fenster vom Anwender über Kommandos, wie man sie auch vom PC her kennt, aufgerufen. Wir setzen diese Technik allerdings noch nicht ein, aber das ist nur noch eine Frage der Zeit.
Bisher werden unsere Masken noch an das Masken-Handling-System BMS von CICS weitergereicht. Anders als das BMS, bietet der Map-Handler MHS die Möglichkeit, die Informationen für das 3270-Terminal so als Maske zu erzeugen, wie sie später zu sehen sein sollen. Im PC-Bereich wird dieses Prinzip Wysiwig (What you see is what you get) genannt. Von dem Verzicht auf das CICS-BMS erwarten wir neben der komfortablen Programmierung von Fenstern eine Verbesserung der Performance.
Die Anwender haben heute sowohl mit zentralen Dialogverfahren zu tun als auch mit Anwendungen vor Ort am Abteilungsrechner oder PC. Die Oberfläche für den Bediener sollte auf allen Ebenen dieselbe sein. Deshalb dürfen wir was die Masken und Menüs betrifft, nicht systembezogen arbeiten.
Kompatibilität und Portabilität unserer Anwendungen wird auch von den Kunden erwartet, in deren Rechenzentren gerade im Midrange-Bereich die verschiedensten Architekturen eingesetzt werden. Die am Großrechner entstandenen Masken sollen aber auch auf Abteilungsrechner portierbar sein. Wir wollen den Anwendern auf möglichst allen Rechnerebenen die gleichen Oberflächen-Masken zur Verfügung stellen.
Am PC sind Pull-down-Menüs und Fenster längst eine Selbstverständlichkeit. Doch die riesigen Datenmengen, die im kommunalen Bereich anfallen, lassen eine PC-Anwendung hier nicht zu. Auch die hohen Anforderungen an den Datenschutz verlangen, daß die Anwendungen größtenteils weiterhin zentral gefahren werden.
Im Bereich der Abteilungsrechner sind Oberflächen und Menütechniken eng auf das (Betriebs-) System bezogen. Jede Entscheidung für eine bestimmte Oberfläche würde daher die Portabilität einschränken. Unsere Entscheidung für eine Window-Benutzeroberfläche - auch für die Midrange-Rechner - fällt daher unter der Prämisse von Großrechner-Anwendungen.
Daher setzen wir ein Runtime-System ein, das uns gezielt für den jeweiligen Betriebssystem- oder Rechnertyp diesselben Menüs zur Verfügung stellt. Der Map-Handler, mit dem wir das Runtime-System ergänzen, sorgt zudem für die technische Steuerung der Menüs, ohne das jeweilige Anwendungsprogramm zu belasten. Vor allem braucht es den Bediener nicht zu kümmern, ob seine Anwendung auf einem Mainframe oder einem Abteilungsrechner abläuft. Sowohl dem Programmierer als auch dem Endanwender soll es egal sein können auf welcher Architektur die Anwendung letztendlich läuft.