Kritik an OOUIs

Neben den hier diskutierten Vorteilen von OOUIs und deren Modellierung sollen hier auch die Kritiker dieses Ansatzes zu Wort kommen:

Constantine et al. kritisieren den Begriff OOUI als zu beliebig, da er sich einer sauberen Definition entzieht [Constantine und Lockwood 1999]. Die von Collins oben angef¨uhrte Definition wird dabei abgelehnt, da sich deren ersten beiden Aussagen auf die Benut-zer und nicht auf Benutzungsschnittstellen beziehen und somit eher Aussagen ¨uber die menschliche Natur und Kognition machen. Dabei wird insbesondere die zweite Aussa-ge (”User classify objects based on how they behave.“) in Frage gestellt, weil nach der Meinung von Constantine et al. eine Klassifizierung von Objekten durch den Menschen anhand vieler Eigenschaften und Faktoren stattfindet, die ¨uber das beobachtete Ver-halten hinausgehen. Weiterhin wird die dritte Aussage (

”All the interface objects fit together into a coherent overall conceptual model.“) als eine Aussage kritisiert, die f¨ur jedes gut-organisierte User Interface jeglicher Art G¨ultigkeit hat.

Neben solchen definitorischen Fragen setzen sich Constantine et al. auch mit der Frage auseinander, ob die in OOUIs auf der Oberfl¨ache durchscheinenden objekt-orientierten Hierarchien imconceptual model der richtige Weg zur Unterst¨utzung des Benutzers sind.

Constantine et al. halten diese besonders anf¨allig f¨ur eine schlechte Gestaltung der Benut-zungsschnittstelle, da nicht die zu erledigenden Benutzeraufgaben im Zentrum stehen, sondern das auf der Benutzungsschnittstelle abgebildete Modell, das nicht notwendiger-weise den Interessen des Benutzers entspricht.

”Only a programmer whose mind has been warped by too many years of small talk with object-oriented programming systems would conceive of interaction in this way.“

”An obsessive preoccupation with making everything object-oriented can lead the user interface designer astray. For one thing, work is behavior. It is made up of actions, steps, and activities interconnected by other activities.

At its heart, work is operations, not objects, which is one reason why use cases are so effective for modeling work.“

Weiterhin wird auch die

”Object-Action“- bzw.

”This do!“-Grammatik in OOUIs kriti-siert (siehe o.g. OOUI Definition von Tesler), die vom Benutzer erst die Auswahl eines Objektes und dann die Auswahl der darauf auszuf¨uhrenden Operation verlangt. Con-stantine et al. fordern, dass

”Action-Object“- und

”Object-Action“-Grammatik immer gemeinsam angeboten werden sollten, da die Pr¨aferenz f¨ur einen der beiden Ans¨atze abh¨angig vom Benutzer sei. Als m¨ogliche Erkl¨arung f¨ur die unterschiedlichen Pr¨ aferen-zen f¨uhren sie die Muttersprache des Benutzers an:

”In English, we say ’Copy this page!’ but ’This page copy!’ rings false in the ear. To speakers of languages like German, where verbs are often deferred to the very end of sentences, the object-action grammar might well feel more natural in a wider variety of contexts.“

Ein weiterer Kritikpunkt bezieht sich auf das in der GUI-Programmierung allgemein angewendetemodel-view-controller pattern, das f¨ur eine Trennung zwischen der internen Information (den Datenmodellen und Datenobjekten), deren Darstellungsformen (ver-schiedene Sichten und Interface-Objekte) und deren Koordination ¨uber Controller und Kontrollobjekte sorgt. Diesespattern sorgt dabei f¨ur die M¨oglichkeit, sowohl Darstellun-gen als auch Datenmodelle unabh¨angig voneinander zu ver¨andern, ohne dass daf¨ur das jeweilige sichtbare bzw. unsichtbare Gegenst¨uck ver¨andert werden muss. Das Durch-scheinen des objekt-orientierten model in die OOUI-Benutzungsoberfl¨ache bzw. view erscheint demgegen¨uber als ein technologischer R¨uckschritt.

Neben der Kritik von Constantine et al., werden die Vor- und Nachteile direkt manipu-lativer Benutzungsschnittstellen (ohne expliziten Bezug auf OOUIs) auch von Markus Dahm in [Dahm 2006] thematisiert. Dabei nennt Dahm die wichtigsten Gr¨unde gegen die Verwendung direkter Manipulation:

• Die zu bearbeitenden Objekte m¨ussen auf der Oberfl¨ache gesucht werden. Wer weiß, wie die zu bearbeitenden Dateien heißen, kann ihren Namen direkt eingeben, um sie beispielsweise zu kopieren.

• Die zu bearbeitenden Objekte m¨ussen nach bestimmten Schemataausgew¨ahlt wer-den, die schriftlich formuliert werden m¨ussen. Beispielsweise sollen alle Dateien, deren Namen mit

”.tmp“ aufh¨ort, gel¨oscht werden.

• Die grafische Darstellung ist aufw¨andig und verbraucht einiges an Rechenzeit. Was bei einem B¨urorechner keine Rolle mehr spielt, kann bei einem spezialisierten Ger¨at wie einem Smartphone durchaus zu langen Wartezeiten f¨uhren.

Diskussion der genannten Einw¨ande

Die hier genannten Einw¨ande gegen OOUIs und der direkten Manipulation sind zwei-fellos grunds¨atzlich berechtigt und sollten daher im Kontext von ZOIL weiter diskutiert werden. Dabei k¨onnen einige der genannten Punkte im Rahmen dieser Arbeit bereits adressiert werden, andere bed¨urfen aber einer intensiveren Betrachtung innerhalb der weiteren Forschungsarbeit.

Die erw¨ahnte Kritik von Constantine et al., dass sich objekt-orientierte User Interfaces anstatt auf Benutzeraufgaben und Arbeitsabl¨aufe auf Objekte und auf deren Hierar-chien konzentrieren, erscheint als gewichtiger Einwand. Dabei erlaubt die Betrachtung von knowledge work und production work im Sinne von Collins und die Diskussion der Automatisierung von Arbeitsprozessen in Kapitel 3.1.3 aber auch eine andere Sichtweise.

W¨ahrend die Kritik von Constantine et al. besonders im Bezug auf Systeme zur Au-tomatisierung bestimmter abgegrenzter Arbeitsprozesse (also production work wie z.B.

Buchungsvorg¨ange, das Versenden von Serienbriefen oder Bestellvorg¨ange) ihre Berech-tigung hat, liegt der Schwerpunkt innerhalb von ZOIL bei h¨ochst variablen Aufgaben der Wissensarbeit und der damit verbundenen Suche und Navigation in komplexen In-formationsr¨aumen. Dabei entzieht sich die Wissensarbeit wegen ihrer hohen Variabilit¨at weitgehend einer Modellierung durch klar definierte Workflows. Sequentielle Abfolgen von”operations“ oder vordefinierte Sichten auf den Datenraum k¨onnen daher auf Dauer keine optimale Unterst¨utzung des Benutzers gew¨ahrleisten. Eine Automatisierung der Wissensarbeit oder deren Modellierung durch den Designer der Oberfl¨ache im Vorfeld kann daher kaum oder gar nicht geleistet werden.

Einem ZOIL-System kommt die Rolle eines visuellen Werkzeugs, das der kreativit¨atsf¨ or-dernden Unterst¨utzung des Benutzers und nicht der Automatisierung seiner Aufgaben dient. Die Verrichtung der Wissensarbeit an sich, muss weiterhin durch den Benutzer ge-schehen. Bildhaft ausgedr¨uckt ¨ubernimmt ZOIL die Rolle einer

”Werkstatt“, in der alle notwendigen Werkzeuge und Rohmaterialien angeboten werden, um das zu erstellende Werkst¨uck in einzelnen flexiblen Arbeitsschritten herzustellen. ZOIL verfolgt nicht das Ziel einer schnellen Repetition gleicher Arbeitsschritte, um eine effiziente Massenferti-gung im Sinne einer FertiMassenferti-gungsstraße zu erreichen.

W¨ahrend bei der Fertigungsstraße die zu erf¨ullende Aufgabe im Zentrum steht und nur eine Orientierung in

”vorw¨arts“ oder

”r¨uckw¨arts“ notwendig ist, muss die Orientierung in der Werkstatt dagegen gezielt zwischen Werkzeugen, Rohmaterialien und angefangenen oder fertiggestellten Werkst¨ucken erfolgen. Die objekte-orientierte Abbildung des

Infor-mationsraums in ZOIL alsmodel-world interface mit einem konsisten conceptual model stellt daf¨ur eine besonders gute Grundlage dar. Anstelle der Automatisierung komplexer Arbeitsvorg¨ange in m¨oglicherweise inad¨aquaten Prozessketten erlaubt die Verwendung von OOUIs dem Benutzer sich in

”kleinen Schritten“ der zu erledigenden Gesamtaufga-be zu n¨ahern und dabei flexibel auf neue Erkenntnisse und ver¨anderte Bedingungen zu reagieren. ¨Uber die Modellierung von notwendigen Operationen innerhalb des objekt-orientierten Modells des Informationsraums und ¨uber eine sorgf¨altige Auswahl der Vi-sualisierungsm¨oglichkeiten und deren modulare Erweiterbarkeit kann dabei trotzdem gew¨ahrleistet werden, dass die dazu notwendige Grundfunktionalit¨at angeboten wird.

Die Einw¨ande von Constantine et al. gegen die

”object-action“-Grammatik in OOUIs und die Forderung nach dem Angebot beider M¨oglichkeiten widersprechen den von Ra-skin gestellten Forderungen an das

”Humane Interface“ [Raskin 2000]. Raskin stellt da-bei explizit die Forderung nach der

”object-action“-Grammatik auf, da nur diese die nicht-modale Interaktion mit dem System erlaubt. Weiterhin stellt er das Prinzip der

”Monotonie“ auf, das die Verwendung zweier alternativer Interaktionsm¨oglichkeiten zur Erreichung der gleichen Funktionalit¨at ablehnt und somit den Vorstellungen von Con-stantinte et al. widerspricht.

”In general, the noun-verb paradigm is preferred. Verb-noun methods should be limited to palette selections intended for immediate use.“

”If I am correct, the use of a product based on modelessness and monotony would soon become so habitual as to be nearly addictive, leading to a user population devoted to and loyal to the product.“

Angesichts dieses Widerspruchs wird nur die weitere Forschungsarbeit und die Evalua-tion von unterschiedlichen L¨osungsans¨atzen mit Benutzerun Klarheit in dieser Frage bringen.

Abschließend soll hier noch auf Dahms Einw¨ande gegen die direkte Manipulation wegen der Notwendigkeit zur langwierigen Suche und des Fehlens einer M¨oglichkeit zur gezielten Auswahl von Objekten nach bestimmten Schemata eingegangen werden. Diese Einw¨ande sind f¨ur die klassische Desktop-Metapher v¨ollig zutreffend. Daher werden innerhalb von ZOIL (wie in Kapitel 4.3.4 illustriert wurde) dynamic queries angeboten, die dieses Manko auf elegante Art und Weise ausgleichen und eine Filterung und Selektion von Objekten nach beliebigen Kriterien mit hoher Effizienz erm¨oglichen.