Technische Universität Braunschweig | ||
---|---|---|
Institut für Wirtschaftswissenschaft | ||
Abteilung für Arbeitswissenschaft | ||
Prof. Dr.-Ing. J.-H. Kirchner |
aus: Friedrich Dorsch (Hrsg.): Psychologisches Wörterbuch, Verlag Hans Huber, 11. Aufl. 1987.
Der große Brockhaus, 1953.
aus: Friedrich Dorsch (Hrsg.): Psychologisches Wörterbuch, Verlag Hans Huber, 11. Aufl. 1987.
Für den Begriff egozentrisch kann hier die Übersetzung ins Deutsche genügen. Für Intuition werden zwei Erklärungen gegeben. Offenbarungen und Eingebungen ungeklärten Ursprungs werden hier nicht betrachtet. Es wird im folgenden von Intuition im Sinn der zweiten Erklärung gesprochen als ein auf Erfahrung basierendes Erkennen und Verstehen.
Im gleichen Sinn wird die Intuition auch in [6fus] betrachtet und ausführlich erläutert.
Die angestrebte intuitive Bedienbarkeit von Programmen bedeutet also, daß die vorhandene Erfahrung des Anwenders für die Bedienung ausreichen soll.
Vorhandene Erfahrungen sind die Grundlage der Intuition. Es sollen hier Vorerfahrungen anhand von Beispielen betrachtet werden. Durch die hohe Entwicklungsgeschwindigkeit sind für die Benutzer und Entwickler der Gegenwart auch Beispiele von Bedeutung, die bereits als veraltet gelten.
Bild: Minimaler Benutzerdialog.
Der Benutzer gibt dem Computer Anweisungen in Form von Befehlstexten. Die Anweisungen müssen Zeichen für Zeichen korrekt eingegeben werden. Hilfestellungen gibt es nur im Handbuch. Nach der Bearbeitung einer Anweisung gibt das System die Meldung READY. aus und wartet auf weitere Kommandos.
Ein Programm prog1 wurde von einem Diskettenlaufwerk geladen und gestartet. Das Programm gibt ein Fragezeichen aus um anzuzeigen, daß eine Eingabe vom Benutzer erwartet wird.
Das Beispiel bezieht sich auf einen frühen Schreibtischcomputer für Büroanwendungen [cbm].
Das erste Beispiel zeigt eine minimale Benutzerschnittstelle. Geprägt von unzureichender Rechnerleistung ist das Programm auf das absolut Notwendige reduziert.
Der Benutzer muß wissen, wie das Programm zu bedienen ist, es gibt nicht die geringste Hilfestellung. Ergonomie ist kein Thema.
Der Entwickler hat nur die Aufgabe, ein funktionierndes Programm zu erstellen. Es sind alleine die technischen Probleme zu berücksichtigen.
Auf solche Programme folgten die ersten Regeln, die die Bedienung der Programme vereinfachen sollten: jedes Programm soll zuerst eine Meldung ausgeben, die beschreibt, was es macht, vor jeder Eingabe soll kurz angegeben werden, was eingegeben werden soll.
Auf der Basis der Textdarstellung wurden Verbesserungen der Bedienung eingeführt. Der verfügbare Platz auf dem Monitor wird weitgehend ausgenutzt für Anzeigen und Eingabefelder.
Für den Benutzer entfällt die Notwendigkeit, die Bedienung komplett auswendig zu lernen oder zu notieren. Es werden zusammengehörige Informationen auch gemeinsam angezeigt und mit einer kurzen Beschreibung versehen. Die Eingabe orientiert sich an Erfahrungen des Büroalltags: dem Ausfüllen von Formularen bzw. Karteikarten. Die möglichen Aktionen werden zusammen mit der Aufrufmöglichkeit angezeigt.
Die Aufgaben des Entwicklers wurden erweitert. Ein Programm muß nicht mehr nur funktionieren. Die Eingaben müssen geordnet und sinnvoll zu Eingabemasken gruppiert werden. Die erweiteren Eingabe- und Korrekturmöglichkeiten müssen ebenfalls programmiert werden.
Eingabemasken und ähnliche Techniken sind bereits eine deutliche Verbesserung für den Benutzer. Solche Programme werden noch häufig verwendet. Die Textdarstellung setzt den Gestaltungsmöglichkeiten jedoch enge Grenzen.
Bild: Texteditor [qed].
Texteditor mit graphischer Benutzeroberfläche. Alle typischen Bedienungselemente sind vertreten, z.B. Fenster, in denen hier die Texte dargestellt werden, Icons für Drucker, Papierkorb, Mülleimer, geladene Texte usw. Zusätzlich kann der Benutzer jeder Funktionstaste eine Folge von Standardfunktionen zuordnen, entsprechend den eigenen Bedürfnissen. Der hier dargestellte Textausschnitt ist Teil eines Programms. Programme werden in dieser Darstellung entwickelt, die nicht geeignet erscheint, dem Benutzer die Möglichkeiten und Erfordernisse der Softwareentwicklung zu erläutern. |
Graphische Benutzeroberflächen wurden geschaffen, damit der Benutzer weitere Alltagserfahrungen im Umgang mit dem Computer verwenden kann. So wurden Bedienungselemente Gegenständen des Arbeitsalltags nachempfunden.
Dem Benutzer zeigt sich ein völlig verändertes Bild. Es ist außerdem ein zusätzliches Eingabegerät, die Maus (oder etwas gleich leistungsfähiges), notwendig. Die Grundideen solcher Oberflächen wie z.B. point and click (Draufzeigen und Knopfdrücken) müssen dem Benutzer vermittelt werden. Die Bedienung soll alltägliche Handlungen nachahmen. Wenn z.B. ein Icon für einen Text mit der Maus auf den Papierkorb bewegt wird, gilt das als Anweisung zum Löschen des Textes.
Der Entwickler hat weitere Aufgaben zu übernehmen. Die graphischen Bedienungselemente müssen entworfen und in das Programm eingebunden werden, die Eingaben per Maus müssen berücksichtigt werden, .... Alle neuen Möglichkeiten erzeugen einen erhöhten Arbeitsaufwand. Der Entwickler hat also die Verantwortung für die Gestaltung der Benutzeroberfläche, die Auswahl der Bedienungskonzepte und die internen Programmfunktionen.
Die graphischen Möglichkeiten müssen mit Bedacht eingesetzt werden. Die Graphik darf nicht Selbstzweck sein. Auch hier gilt häufig less is more (weniger ist mehr). Wichtig ist eine klare, übersichtliche Gliederung der Oberfläche und eine eindeutige Zuordnung der Bedienungselemente. Zu jedem Rechnersystem mit graphischer Oberfläche gibt es style guides, Ratgeber für die Gestaltung. Es können nicht alle Fälle in diesen Ratgebern behandelt werden, jedoch sollten passende Ratschläge auch angenommen werden.
Bild: Oberfläche eines Entwicklungssystems [m2d2].
Aufgabe dieses Programms ist es, dem Entwickler eine Übersicht über das aktuelle Projekt zu geben, einen schnellen Zugriff auf die Werkzeuge zu ermöglichen und ihre Anwendung zu vereinfachen. Am linken Rand stehen die Icons für die Entwicklungswerkzeuge. In der Mitte werden die Teile des aktuellen Projektes angezeigt. Das Programm in Bearbeitung besteht aus mehreren Modulen, jedem ist eine Zeile zugeordnet. Zu einem Modul gehören mehrere Dateien. Jeder Datei ist ein Rechteck in einer Zeile zugeordnet. Ist das Rechteck leer, ist die Datei nicht vorhanden (wird nicht benötigt). Zwischen den Modulen bestehen Abhängigkeiten. Das Programm kann diese berücksichtigen und bestimmte Werkzeuge entsprechend steuern. |
Die Arbeit mit einem Texteditor ist eine wesentliche Erfahrung der Entwickler. Die meiste Zeit wird mit dem Erstellen von Programmtexten verbracht. Der im Texteditor sichtbare Textausschnitt zeigt ein Beispiel in der Programmiersprache Modula-2 [m2].
Auch die Arbeit der Entwickler kann durch entsprechende Programme erleichtert werden. Der Texteditor ist zwar das am häufigsten benötigte Werkzeug, aber nicht das einzige. Ein Programm besteht (ab einer bestimmten Größe) aus mehreren Programmtexten (Modulen). Ein Entwicklungssystem soll dabei helfen, die Übersicht zu behalten.
Für den Benutzer bildet ein Programm eine Einheit mit bestimmten Eigenschaften. Mancher Benutzer sieht nicht nur ein Programm als Einheit, mitunter wird der Computer mit allen Programmen, dem Betriebssystem und der Hardware als Einheit gesehen.
Der Entwickler ist es gewohnt, Programme in Module zu zerlegen bzw. aus Modulen aufzubauen. Die Module wiederum enthalten Prozeduren, die aus Anweisungen bestehen. Aus der eigenen Erfahrung sehen Entwickler Programme (und Computer) grundsätzlich anders als Benutzer.
Bild: Subjektive Sichtweise (aus [booch]).
Wenn Zwei dasselbe betrachten, sehen sie noch lange nicht das gleiche.
Die unterschiedliche Vorerfahrung beeinflußt die Sichtweise von bestehenden Programmen und auch die Vorstellung, wie neue Programme gestaltet werden sollten. Entwickler werden Gestaltungskonzepte bevorzugen, die sie in der Vergangenheit erfolgreich angewendet haben. Als Teil der Alltagserfahrung üben die Entwicklungswerkzeuge ebenfalls einen Einfluß auf die Entwickler aus.
Für die Benutzer erscheinen Konzepte vorteilhaft, die sich in ihrem Arbeitsalltag bewährt haben. Dazu gehört die Arbeit mit und ohne Computer.
Wenn ein neues Programm erstellt werden soll, werden die Entwickler ganz selbstverständlich ihrer egozentrischen Intuition folgen und an den Interessen der Benutzer (die ihre eigene, ebenfalls egozentrische Intuition haben) vorbei arbeiten. Damit das Ergebnis mehr den Vorstellungen der Benutzer entspricht, muß eine Kommunikation zwischen Benutzern und Entwicklern stattfinden [komm].
Die Kommunikation ist Gegenstand von zahlreichen Untersuchungen. Es wurden in der Psychologie verschiedene Modelle entwickelt, die unterschiedliche Aspekte der Kommunikation beschreiben sollen. In der Abbildung soll ein Kommunikationsmodell vorgestellt werden.
Bild: Kommunikationsmodell nach [komm2].
Ein zu übermittelnder Inhalt wird vom jeweiligen Sender mittels eines Codes (hier: Sprache) zum Empfänger übertragen. Die Teilnehmer müssen den Code vollständig beherrschen, damit eine fehlerfreie Kommunikation möglich wird. Der Empfänger muß die empfangene Information dekodieren, um darauf reagieren zu können, sich eine Meinung zu bilden und sein Verhalten entsprechend zu steuern. Das resultiernde Verhalten kann in einer Antwort bestehen, die er (nun als Sender) kodiert und übermittelt.
Störungen können in jeder Phase auftreten. Besonders komplex (und deshalb hier nicht ausführlich zu behandeln) sind Meinungsbildung und Verhaltenssteuerung.
Dieses Modell betont die Übertragung der Information in Anlehnung an nachrichtentechnische Systeme. Modelle, die soziale und kognitive Aspekte der Kommunikation näher beschreiben, sind zu komplex, um in diesem Rahmen behandelt zu werden.
Ergänzt am 21. März 2002, von Hinnerk Rümenapf
Zu den Grundvorraussetzungen einer Kommunikation zählt die Bereitschaft, auf den Partner einzugehen und seinen Äußerungen eine Bedeutung zuzugestehen. Gegen den Willen eines Beteiligten ist keine Kommunikation möglich.
Ursachen für eine Verweigerungshaltung können sein:
Eine ablehnende Haltung äußert sich oft im Ignorieren des Inhalts von Äußerungen. Mitunter wird auf begründete Argumente nur mit einem "wissenden" Grinsen oder Inhaltsleeren "Killerphrasen" wie "Das geht hier nicht", "Das will man nicht", "Das kannst Du hier nicht machen" geantwortet. Mit solchen Methoden wird eine sachlich/inhaltliche Diskussion abgewürgt.
Die "Härte" solcher Reaktionen hängt auch von den jeweiligen wirtschaftlichen Umständen ab. Je schlechter die wirtschaftliche Lage ist, um so größer ist die Wahrscheinlichkeit derartiger Verhaltensweisen. Wenn Angst um den Arbeitsplatz mit ins Spiel kommt, kann es bis zum Mobbing kommen.
Auch bei bestem Willen der Beteiligten treten Störungen der Kommunikation auf. Mögliche Ursachen dafür sind (ohne Anspruch auf Vollständigkeit):
In diesem Abschnitt werden Vorgehensweisen erläutert, die die Probleme der Erstellung benutzergerechter Software verringern sollen. Eine vollständige Lösung kann kein Verfahren bieten, aber eine Verringerung der Auswirkungen.
Bei der Entwicklung müssen Schwerpunkte gesetzt werden. Ein Programm in allen Punkten optimal zu gestalten, ist ein unrealistischer Anspruch. Die Auswahl beginnt mit der Gestaltungsrichtung.
Die Wahl der Gestaltungsrichtung hat einen großen Einfluß auf das Ergebnis. Zu Beginn des Projektes getroffene Entscheidungen beeinflussen alle folgenden. Einmal getroffene Grundsatzentscheidungen lassen sich später nur schwer revidieren. Getreu dem Motto Das Wichtigste zuerst kann mit der zeitlichen Abfolge der Entwicklungsschritte ein Schwerpunkt gesetzt werden.
Schwerpunkt durch die zeitliche Abfolge der Entwicklungsschritte:
Ein Programm muß zum einen mit dem Benutzer in Verbindung treten, zum anderen mit dem Rechnersystem, auf dem es abläuft. Dazwischen stehen die programminternen Funktionen für Ein- und Ausgabe sowie interne Berechnungen.
Die Schnittstellen sind jedoch grundverschieden. Die Systemschnittstelle ist eindeutig definiert und exakt beschrieben (Zumindest sollte es so sein). Für die Benutzerschnittstelle gibt es keine eindeutigen, unumstößlichen Regeln. Die Benutzer und die Aufgaben der Software sind zu verschieden. Hinweise und Anregungen geben die bereits erwähnten style guides und die Literatur zur Software-Ergonomie.
Die Entwicklung von Software durchläuft mehrere Phasen. Im sequentiellen Phasenmodell ist Benutzerbeteiligung nur bei der Analyse und der Spezifikation vorgesehen. Implementation und Test werden von den Entwicklern alleine durchgeführt, getestet wird die Übereinstimmung des Programms mit der Spezifikation.
In der Analyse wird der ist-Zustand betrachtet, der durch neue Software verändert werden soll. Die Ergebnisse werden zur Spezifikation der Anforderungen an das Programm verwendet. Die Implementation ist das Umsetzen dieser Anforderungen in ein Programm. Der Test soll sicherstellen, daß alle gestellten Anforderungen erfüllt werden. Die erfolgreiche Integration des Programms in den Arbeitsablauf beendet das Projekt.
Kommunikationsschwierigkeiten und unklare Vorstellungen der Auftraggeber führen zu einer ungenauen Spezifikation. Während der Implementation und des Tests interpretieren die Entwickler die Spezifikation aus ihrer eigenen Sicht. Die Benutzer finden dann bei der Integration des Programms ihre ursprünglichen Vorstellungen und Erwartungen nicht wieder, was zu vielfältigen (und teueren) Nachbesserungswünschen führt.
Im Phasenmodell mit Rückkopplung gehört zu jeder Phase eine Bewertung der bisherigen Ergebnisse. Geschieht die Bewertung mit Beteiligung der Benutzer, können bereits frühzeitig Korrekturen vorgenommen werden. Frühzeitige Korrekturen sind billiger als späte Nachbesserungen [heeg].
Die Phasen Analyse und Spezifikation müssen auch unter Einbeziehung der Rückkopplung sorgfältig ausgeführt werden. Je näher die erste Version am Endprodukt liegt, um so weniger Schleifendurchläufe sind notwendig, und um so günstiger und schneller wird die gesamte Entwicklung.
Prototypen werden in der Industrie schon lange verwendet. Bevor ein Produkt die Marktreife erreicht, werden Prototypen erstellt, um die Funktionsfähigkeit zu testen und einen Eindruck vom Produktaufbau zu erhalten. Am Prototyp erkannte Verbesserungsmöglichkeiten werden in das Endprodukt eingebracht.
Ein Software-Prototyp soll Teile des Verhaltens eines möglichen Endproduktes verdeutlichen, insbesondere die Benutzeroberfläche. Andere Qualitätsmerkmale, die nicht mit dem Prototyp überprüft werden sollen, werden außer acht gelassen (korrekte Funktion, Effizienz, Dokumentation, Fehlersicherheit, ...).
Prototyping unterstüzt die Entwicklung nach dem Phasenmodell mit Rückkopplung. Nicht alle Arten des Prototyping sehen nach jeder Phase eine Bewertung vor:
Allen Arten gemeinsam ist die Idee, durch ein konkretes Anschauungsobjekt (den Prototyp) die Bewertung des Entwicklungsstandes für Benutzer zu vereinfachen, oder sogar erst möglich zu machen.
Das schnelle Prototyping ist eine Verbesserung der Spezifikationsphase. Implementation und Test entsprechen dem sequentiellen Phasenmodell. Im inkrementellen Prototyping wird die Gesamtentwicklung in mehrere aufeinanderfolgende Einzelentwicklungen zerlegt. Bei diesen Einzelentwicklungen wird nach dem sequentiellen Phasenmodell vorgegangen. Im evolutionären Prototyping findet ein ständiger Wechsel der Phasen statt. Auf jede Bewertung folgt eine weitere Spezifikation, eine teilweise Implementation, deren Ergebnis als neuer Prototyp getestet und bewertet wird. Die sequentielle Struktur wird hier weitgehend verlassen.
Die genannten Arten schließen sich nicht gegenseitig aus, es sind verschiedene Kombinationen denkbar.
Die Verbesserung der Benutzerfreundlichkeit bedeutet einen Mehraufwand für die Entwickler. In den Beispielen hat jede Verbesserung mehr Entwicklungsarbeit gefordert. Prototyping, besonders das evolutionäre Prototyping, erfordert eine enorme Flexibilität der Entwickler. Benutzerbeteiligung verliert den Sinn, wenn die technischen Gegebenheiten fehlen, die Vorstellungen der Benutzer auch umzusetzen.
Die Entwickler müssen an anderer Stelle entlastet werden, um mehr auf die Benutzer eingehen zu können. Durch bessere Entwicklungswerkzeuge kann die Programmierung vereinfacht werden. Bereits bestehende Werkzeuge (vgl. Abb. qed, m2d2, orcs) werden erweitert. Die Programmierung soll sich von dem Arbeiten mit einer Textdarstellung zu einem graphischen Entwurf entwickeln. Mit graphischen Dialogeditoren sollen außer dem Aussehen der Dialoge auch die Beziehungen der Bedienungselemente untereinander und zu Programmfunktionen modelliert werden [smalltalk].
Bild: Dialogeditor [orcs].
Ein Programm zum Erstellen und und Verändern von Dialogboxen. Standardelemente können zu Dialogen kombiniert werden. Das Aussehen des Dialogs kann graphisch gestaltet werden. Die Standardbedienungselemente zeigen ein Standardverhalten, das mit erhöhtem Programmieraufwand verändert werden kann. Die Beziehungen zwischen den Bedienungselementen können in diesem System nur sehr eingeschränkt beschrieben werden. |
Auch die Programmiersprachen werden weiterentwickelt. Konzepte, die seit Jahren wenig Beachtung fanden, werden aufgegriffen und weiterentwickelt. So hat die objekt-orientierte Programmierung einen enormen Aufschwung erlebt.
Dem Entwickler werden mehr und mächtigere Funktionen zur Verfügung gestellt, von vorgefertigten Standard-Dialogen zur Auswahl von Dateien oder Zeichensätzen bis hin zu kompletten Datenbanksystemen.
Alle diese Ansätze sind mit einem enormen Aufwand bei der Erstellung von Entwicklungssystemen verbunden. Spezialisierte Entwickler müssen viel Zeit darauf verwenden, anderen Entwicklern die Arbeit zu vereinfachen. Entsprechend kostspielig werden diese Entwicklungssysteme sein.
Eine weitere Vereinfachung ist durch die Verlagerung der Entwicklungsschwerpunkte zu erreichen. Die Mehrarbeit für die Benutzerschnittstelle wird (wenigstens teilweise) an anderer Stelle eingespart. Meistens geht das zu Lasten der Geschwindigkeit und des Speicherbedarfs im Vertrauen auf neue, leistungsfähigere Rechner.
Bisher war nur von Benutzern und Entwicklern die Rede. Weder Benutzer noch Entwickler sind jedoch (im allgemeinen) Spezialisten für Graphik-Design. Gerade graphische Benutzeroberflächen können durch die Mitwirkung von Graphik-Designern stark verbessert werden [design].
Vorstellbar wäre eine Arbeitsgruppe von Benutzern, Entwicklern, Designern und Psychologen, die gemeinsam ein Programm gestalten. Nach Art des schnellen Prototyping könnten mehrere Prototypen entworfen werden (wie es in der Industrie nicht unüblich ist). Nach einer vergleichenden Bewertung der Prototypen würde die Spezifikation für das Programm entworfen. Sie kann Elemente verschiedener Prototypen enthalten. Für die weitere Entwicklung bietet sich das evolutionäre Prototyping an.
Wichtig ist vor allem die Bereitschaft aller Beteiligten zur Kommunikation und Zusammenarbeit.