Human Engineering

Julian Reschke zeigt, was Software anwenderfreundlich macht, und berichtet von den Erfolgen bei der Normierung von Standard-Dateiformaten.

Auf der pausenlosen Suche nach bislang stief-mütterlich behandelten Themen bin ich diesen Monat auf ein Thema gestoßen (oder besser: gestoßen worden), das wenig mit den programmtechnischen Details zu tun hat, die Sie sonst in dieser Kolumne finden. Jeder spricht von anwender-freundlicher Software und »Human Engineering«: Doch wer kümmert sich schon um den geplagten Käufer, der nicht so recht weiß, wie er denn nun die sechs Programmdisketten auf seiner Hard-, RAM- oder gar Floppy-Disk unterbringen soll? Ist es einzusehen, daß man sich von mehreren großformatigen blauen Scheinen trennt, um dann stundenlang damit beschäftigt zu sein, dieses neue »professionelle« Softwarepaket zur Arbeit zu bewegen? Ich sehe es zumindest nicht ein.

Zur Freude des Schreibers gibt es natürlich auch in dieser Beziehung gute Beispiele. Ausgerechnet die Tastatur-Fans vom amerikanischen Softwarehaus Mark Williams demonstrieren bei ihrem auf fünf Disketten verteilten C-Compiler, wie man es richtig macht (siehe Bild 1,2 und 3). Das Installationsprogramm stellt zunächst selbständig fest, wie denn die aktuelle Hardwarekonfiguration aussieht. Selbstredend sind nachträgliche Änderungen möglich. Das zu benutzende Laufwerk läßt sich frei einstellen, Ordner erzeugt dabei automatisch das Programm. Nach dem Start der Installation fordert es nacheinander zum Einlegen der richtigen Diskette auf.

Leider sind solch vorbildliche Installationsprogramme ziemlich rar. Im allgemeinen muß man sich damit zufriedengeben, daß man Zugriffspfade innerhalb einer Textdatei frei setzen kann (hat man Pech, dann spielt dabei die Tiefe der Einrückung eine entscheidende Rolle). Den Vögel schießen die Autoren des Manuals zu Minix-ST ab (siehe unten): Sie fordern doch glatt

Execute the next 4 lines for 12.USR, 03.USER, 14.ACK1, 05.ACK2
: Insert the diskette in drive 0
# /etc/mount /dev/fd /user
# cpdir -msv /user /usr
# /etc/umount /dev/fd0
# mkdir /usr/src

zur viermaligen Ausführung der folgenden vier Anweisungen aufgefordert — tatsächlich folgen aber fünf Befehle. Des Rätsels Lösung: die letzte Zeile soll man tatsächlich nur einmal durchführen. Nichts gegen präzise Anweisungen, aber wer würde sich dabei nicht auf die Schippe genommen fühlen?

Und dann gibt es natürlich noch die Programme, die man gar nicht installieren kann: Da wird munter eine VDI-Workstation für VDI-Device 0 geöffnet. Der Haken: Den VDI-Device 0 gibt es nicht, und das neue (seit mittlerweile einem Jahr bei Atari erhältliche) AMC-GDOS quittiert den Programmfehler mit einer Alert-Box.

Womit wir auch schon bei Arnd Beissner, dem Programmierer von AMC-GDOS, angelangt wären. Er bittet darum, sich bei Anfragen zu AMC-GDOS direkt an Atari Deutschland zu wenden — die Beantwortung der vielen Zuschriften macht es ihm zur Zeit fast unmöglich, AMC-GDOS weiterzuentwickeln.

Zurück zum Thema »Human Engineering«. Viele ST-Software benutzt zwar GEM, aber vermittelt den Eindruck, daß die Programmierer die eigentliche GEM-Philosophie noch nicht recht durchschaut haben. Da sieht man einen Haufen überladener Dropdown-Menüs — von Icons, Fenstern und Übersichtlich aufgebauten Dialogboxen keine Spur. Liegt es nur daran, daß Dropdown-Menüs so viel leichter zu programmieren sind?

Dabei hat Digital Research von Anfang an [1] genau erklärt, was es mit Dialogen, Menüs und Icons auf sich hat:

• Menüs repräsentieren Aktionen (Laden, Speichern, Drucken...).
• Icons stellen Objekte (Datei, Drucker...) dar.
• Dialogboxen sind für weiterführende Einstellungen adjektivischen Charakters zuständig.

Selbst unter Berücksichtigung all dieser Kriterien sieht eine durchschnittliche GEM-Anwendung noch immer nicht so gut aus wie ein entsprechendes Macintosh-Programm. Woran liegt’s?

Zunächst ist augenfällig, daß bei Mac-Software auch in den Dialogen mit Proportionalschrift gearbeitet wird. Dies läßt sich nur mit großem Aufwand nachempfinden — und angesichts der völlig anderen Behandlung von Text-Edit-Feldern unter GEM (mit Maske) ist es fraglich, ob man tatsächlich Proportionalschrift braucht.

Anders sieht es mit den Buttons aus. Der Macintosh bietet hauptsächlich drei verschiedene Button-Klassen:

• Exit-Buttons: Sie sehen ähnlich aus wie auch auf dem ST.
• Radio-Buttons: Bei diesen Buttons steht der Text neben einem Kreis, der bei Anwahl ausgefüllt wird.
• Standard-Buttons: Auch hier steht der Text neben dem Knopf, der bei Selektion durchgekreuzt wird.

Gerade die beiden letzten Typen geben sehr viel genauer die Philosophie wieder, die hinter der ganzen Formularbehandlung steckt:

• Radio-Buttons sind ein Bild für die Stationstasten an einem altmodischen Radio: Es kann immer nur ein Knopf gedrückt sein.
• Standard-Buttons hingegen stehen eher für Ankreuzfelder auf einem Formular. Daher gibt auch ein angekreuztes Feld mit nebenstehender Beschriftung die Bedeutung besser wieder.

In diesem Fall kommt man leider nicht mehr mit den üblichen Formular-Routinen des AES aus. Mit dem Objekttyp »G_USERDEF« hat Digital Research aber glücklicherweise einen Weg freigehalten, eigene Erweiterungen einzubauen! Wie wäre es bei der Gelegenheit mit voll über die Tastatur steuerbaren Dialogboxen?

Kein Atarium ohne Diskussion um Standards. Auf der jüngsten CeBIT ist endlich die Kommunikation unter den Softwareentwicklern von alleine in Gange gekommen (da Atari selbst offenbar keinen Bedarf dafür sieht). Erster Diskussionspunkt waren Standard-Dateiformate, ohne die der Datenaustausch zwischen verschiedenen Programmen ja bekanntlich mühselig ist. Die Bemühungen des »Normungsausschusses« haben sich zunächst auf die Standardanwendungen beschränkt — mit meiner Meinung nach guten Resultaten:

• Für Pixelgrafiken wurde das GEM-IMG-Format als Standard bestätigt. Über eine Erweiterung im Dateikopf soll dabei in Zukunft auch die Farbpalette zu speichern sein.
• Für Vektorgrafiken hat man sich auf das GEM-Metafile-Format geeignet. Auch die Erweiterungen bis hinauf zur GEM-Version 3.1 (Splines) sind erlaubt. Zusätzlich möchte man das DXF-Format von AutoCAD für 3D-Grafiken unterstützen.
• Für Datenbanken und Tabellenkalkulation wurde der De-facto-Standard »DIF« (Data Interface Format) bestätigt.
• Für Textdateien ist zusätzlich zum ASCII-Format das 1st Word Plus-Format zulässig. Kleine Erweiterungen sollen auch verschiedene Fonts und Farben zugänglich machen — wenn man denn auch GST davon überzeugen kann...

Selbstverständlich ist daneben die Verwendung eigener spezieller Formate weiterhin zulässig. Lediglich sollte einem Datenaustausch zwischen verschiedenen Programmen nichts im Wege stehen. Durch die Wahl der Formate wird überdies erreicht, daß auch eine gewisse Kompatibilität zu anderen Betriebssystemen, insbesondere zu MS-DOS, gewahrt bleibt.

Das ST-Magazin wird in loser Folge die genauen Formate, ihre Spezifikation und entsprechende Anwendungsbeispiele vorstellen. Für Entwickler wird zur Zeit eine entsprechende Dokumentation vorbereitet, die Sie dann bei uns anfordern können. Hoffen wir, daß die Arbeit des »Normungsausschuß« schon bald reiche Früchte trägt. Das ST-Magazin wird Programme, die diese Formate unterstützen, im Rahmen von Software-Tests mit einem besonderen Prädikat versehen.

Fazit: Wer sich bislang an die tatsächlichen Standards gehalten hat (nämlich die von Digital Research definierten), wird auch in Zukunft keine nennenswerten Anpassungsprobleme bei seinen Programmen haben! (uh)

Literatur:

[1] Chris Lusby Taylor: »The objects of GEM«

Julian F. Reschke

---

---