Theoretischer Hintergrund und Modellierung

Die objekt-orientierte Analyse und Modellierung sind heute zu unverzichtbaren Werk-zeugen in der Software-Entwicklung geworden. Fast alle Programmiersprachen wie z.B.

Java, C++, C#, J# oder PHP, die in der Praxis f¨ur die Anwendungsentwicklung ein-gesetzt werden, erm¨oglichen den objekt-orientierten Entwurf von Softwarearchitekturen und die objekt-orientierte Programmierung bzw. Implementierung der einzelnen Kom-ponenten. Selbst grafische Multimedia-Autorensysteme wie Macromedia Flash werden heute durch objekt-orientierte Skriptsprachen (z.B. ActionScript 3.0) erg¨anzt.

Weiterhin wurde ¨uber die grafische Notation

”UML“ eine standardisierte Modellierungs-sprache zur visuellen Abbildung objekt-orientierter Modelle von Arbeits- und Gesch¨ afts-prozessen oder Informationsarchitekturen geschaffen. Dabei ist die semi-formale Anwen-dung von UML als visuelles Werkzeug und Dokumentation im Entwurfsprozess genauso m¨oglich wie die Anwendung zu einer hochpr¨azisen und formal eindeutigen Spezifikation f¨ur die automatische Generierung von Quellcode oder f¨ur automatisierte Testmethoden.

UML ist damit zu einer lingua franca innerhalb des Software-Engineerings geworden und ist aus der Entwicklungspraxis in vielen Unternehmen und aus Forschung und Leh-re nicht mehr wegzudenken.

Die direkte Anwendung von objekt-orientierten Ans¨atzen im Bereich der Mensch-Com-puter-Interaktion ist dagegen weitaus weniger verbreitet. Obwohl das Konzept der

” Ob-jekt-Orientierung“ maßgeblich von der Gestaltung von User Interfaces inspiriert und mitgepr¨agt wurde (siehe Abschnitt 5.1.3), wird sie heute vor allem als ein Paradigma der Programmierung und nicht der Oberfl¨achengestaltung betrachtet. Vielfach wird der Begriff

”Objekt-orientierte Benutzungsschnittstelle“ auch mißverstanden, weshalb hier

zun¨achst eine kompakte Beschreibung und Abgrenzung des Verst¨andnisses von OOUIs innerhalb von ZOIL erfolgen soll.

Der Begriff des object-oriented user interface wurde 1983 von Larry Tesler nach sei-nem Wechsel vom Xerox PARC zu Apple gepr¨agt, wo er maßgeblich f¨ur die Entwick-lung des Macintosh-Vorg¨angers

”Lisa“ verantwortlich war. In [Tesler 1983] lieferte er eine informelle Beschreibung der Eigenschaften eines object-oriented user interface vor dem Hintergrund seiner Erfahrung mit objekt-orientierten Benutzungsschnittstellen und Programmiersprachen, z.B. bei der Entwicklung von Smalltalk, Object Pascal oder dem Lisa-UI. Collins greift diese Beschreibung auf und interpretiert sie in [Collins 1995] wie folgt:

1. Users see objects and choices displayed graphically.

2. The syntax of commands is

”object-action“.

3. Users get immediate feedback from actions.

4. The interface is modeless.

5. The interface displays objects in WYSIWYG form.

6. Objects and actions are consistent.

Collins erg¨anzt dazu seine eigene Definition, die die von Tesler genannten Eigenschaften allgemeing¨ultiger und abstrakter formuliert.

1. Users perceive and act on objects.

2. Users can classiy objects based on how they behave.

3. In the context of what users are trying to accomplish, all the interface objects fit together into a coherent overall representation (user’s conceptual model)

Weiterhin sollen diese Definitionen hier auch um die Gestaltungsprinzipien f¨urdirect ma-nipulation interfaces von Shneiderman erweitert werden [Shneiderman 1997]. Diese sind f¨ur sich genommen zwar keine hinreichenden Kriterien f¨ur

”Objekt-Orientierung“ (siehe unten), werden innerhalb von ZOIL aber als Erweiterung der notwendigen Kriterien f¨ur OOUIs verstanden.

• Continuous representation of the objects and actions of interest

• Physical actions or presses of labeled buttons instead of complex syntax;

• Rapid incremental reversible operations whose effect on the object of interest is immediately visible.

Anhand dieser Beschreibung und Definition lassen sich OOUIs von anderen Konzep-ten abgrenzen, mit denen es in der Praxis oft zu Verwechselungen und Vermischungen kommt. Dies ist durchaus nachvollziehbar, da Teilaspekte von OOUIs an vielen Stellen in herk¨ommliche GUIs eingeflossen und daher in der Praxis schwer abzugrenzen sind. Den-noch steht bei OOUIs ein Gesamtkonzept im Hintergrund, das von vielen Betrachtern aufgrund seines eher abstrakten Charakters ¨ubersehen wird. Daher wird im Folgenden versucht, typische Mißverst¨andnisse in der Form von

”Faustregeln“ auszur¨aumen:

• ”Icons bedeuten nicht OOUI!“: Die Verwendung von Icons als Objekte zur Re-pr¨asentation von Funktionen oder Daten auf der Oberfl¨ache wird h¨aufig mit

” Ob-jekt-Orientierung“ gleichgesetzt. Dabei ist die alleinige Verwendung von Icons daf¨ur nicht ausreichend. In Abschnitt 5.1.3 und 5.1.5 wird genauer behandelt wer-den, dass daf¨ur die konsistente Organisation der Objekte und der Funktionalit¨at in hierarchischen Beziehungen, Klassen und ¨uber Vererbung in einemmodel-world interface mit einem konsistenten conceptual model entscheidend ist. Die alleinige grafische Notation mit Icons leistet Objekt-Orientierung nur auf einer visuellen und nicht auf einer logischen Ebene.

• ”Direkte Manipulation bedeutet nicht OOUI!“: Das Gef¨uhl einer

”direkten Mani-pulation“ durch den Benutzer kann mithilfe von objekt-orientierten Benutzungs-schnittstellen wegen ihrer Konsistenz und ihrer F¨ahigkeit die semantische und ar-tikulatorische Distanz zu minimieren (siehe Kapitel 3.2.4) besonders gut erreicht werden. Deswegen wird hier

”direkte Manipulation“ als Gestaltungsprinzip f¨ur OOUIs verstanden. Dennoch k¨onnen auch nicht-objektorientierte L¨osungen ein

¨ahnliches Gef¨uhl der

”Direktheit“ vermitteln, ohne dass dazu notwendigerweise OOUI-Konzepte eingesetzt werden.

• ”Widgets bedeuten nicht OOUI!“: Die objekt-orientierte Gestaltung des User In-terface darf nicht mit der objekt-orientierten Programmierung des User InIn-terface verwechselt werden. Heutige UI-Toolkits stellen dem Programmierer eine ganze Pa-lette von UI-Elementen oderwidgets wie z.B.buttons,checkboxes odersliders ¨uber eine Klassenhierarchie (z.B. Java Swing) objekt-orientiert zur Verf¨ugung.Widgets sind dabei aber nur die elementaren Grundbausteine einer Benutzungsschnittstelle und sagen nichts ¨uber deren ¨ubergeordnete Architektur, Konsistenz und logische Struktur aus. Collins und Constantine et al. weisen ¨ubereinstimmend auf die Ge-fahren eines widget-driven design hin, das auf der falschen Annahme basiert, dass bereits die Verwendung von widgets und die Einhaltung derer Styleguides aus-reicht, um ein gutes User Interface gew¨ahrleisten zu k¨onnen². Im Gegensatz zur

2siehe [Collins 1995] und [Constantine und Lockwood 1999]. Constantine et al. schreiben:

”The goal

OO-Programmierung von UIs mit widgets adressieren OOUI-Ans¨atze dagegen das Gesamtkonzept des UI und verfolgen nach Collins damit insbesondere die Errei-chung einer umfassenderen

”coherent overall representation“.