Zoomable-User-Interfaces

Inhaltsverzeichnis

1 EINLEITUNG
1.1 MOTIVATION
1.1.1 Enterprise-Resource-Planning-Systeme
1.1.2 Produktionsprozess
1.2 PROTOTYP
1.3 ABSCHNITTSÜBERSICHT

2 ZOOMABLE-USER-INTERFACES UND AKTUELLER STAND
2.1 USER-INTERFACE
2.1.1 Historische Entwicklung
2.1.2 User-Interface - Erwartungsanalyse
2.1.3 User-Interface - Typen
2.1.4 Interfacedesign
2.2 ZOOMABLE-USER-INTERFACE
2.2.1 Anforderungen an ein ZUI
2.2.2 Features
2.2.3 Kognition und der Aufmerksamkeitspunkt
2.2.4 Quantifizierung
2.2.5 Räumliche Fähigkeit
2.2.6 Kürzester Pfad
2.2.7 Vor- und Nachteile eines ZUI
2.2.8 Gesten
2.3 EINSATZ VON TEXT UND BILD

3 ENTWURF UND IMPLEMENTIERUNG
3.1 RINGAUSWAHL
3.2 ENTWURF
3.2.1 Zoomen
3.2.2 Pannen
3.2.3 Verschieben von Objekten
3.2.4 Objekt-Gleiten
3.2.5 Rekursive Verschachtelung von Objekten
3.2.6 Ringauswahl
3.2.7 Workspace-Snapshots
3.2.8 Selektion
3.2.9 Klassendiagramm
3.3 IMPLEMENTIERUNGSASPEKTE
3.3.1 Windows-Presentation-Foundation (WPF) - Bibliothek
3.3.2 Transformationsmatrizen
3.3.3 Implementierte Features
3.3.4 Nicht implementierte Features

4 SCHLUSSFOLGERUNGEN

GLOSSAR

LITERATURVERZEICHNIS

ANHANG

Abbildungsverzeichnis

Abbildung 1: Vorgegebenes Prozess-Schaubild

Abbildung 2: Bildschirmfoto des Prototyps

Abbildung 3: Erwartungen des Anwenders und der Oberfläche

Abbildung 4: Eine Sequenz von Sichten beim Zoom in Daten

Abbildung 5: Linsen

Abbildung 6: Fisheye-Linse über einer Landkarte

Abbildung 7: Suchfenster

Abbildung 8: Lesezeichen

Abbildung 9: Pad++-Tour mit ovalem Dokument-Layout

Abbildung 10: Eine Dialog-Box mit einer informationstheoretischen Effizienz von 0

Abbildung 11: Kurvenverlauf

Abbildung 12: Die Komponenten aus Fitts’ Gesetz im eindimensionalen Fall

Abbildung 13: Zooming- und Panning-Schritte, um zur Zielposition zu gelangen

Abbildung 14: Zwei Funktionen, deren Funktionswerte einander ähneln

Abbildung 15: Elternmenü und überdeckendes Submenü

Abbildung 16: Zentralprojektion

Abbildung 17: Verschieben

Abbildung 18: Verschieben

Abbildung 19: Wurf

Abbildung 20: Aktion

Abbildung 21: Schiefe Ebene

Abbildung 22: Reibung

Abbildung 23: Ableitungen

Abbildung 24: Verlauf des Weges über die Zeit

Abbildung 25: Ring bestehend aus mehreren Auswahloptionen

Abbildung 26: Klassendiagramm der Prototypklassen

Abbildung 27: Semantische Zoomstufen

Abbildung 28: Möglichkeiten rekursiver Verschachtelung

Abbildung 29: Piccolo-Übersichtsportal

Abbildung 30: Ein vollständiger Binärbaum

Abbildung 31: Ein Binärbaum der Höhe 3

Abbildung 32: Balancierter bis vollständiger Binärbaum

Abbildung 33: Wurzelbaum

Abbildung 34: Ein voller k-närer Baum

Abbildung 35: Klasse, abstrakte Klasse und Interface

Abbildung 36: Instanz einer Klasse ist Eigenschaft einer anderen Klasse

Abbildung 37: Vererbung

Abbildung 38: Von Interface abgeleitete Klasse implementiert deren Methoden

Abbildung 39: Eine Klasse benutzt eine Andere

Abbildung 40: Aggregation – Ganze-Teile-Hierarchie

Abbildung 41: Komposition – Teile sind vom Ganzen existenzabhängig

Tabellenverzeichnis

Tabelle 1: Eigenschaften von kognitiv Bewusstem und kognitiv Unbewusstem

Tabelle 2: Heuristiken für das Platzieren mentaler Operationen

Tabelle 3: Haftreibungskoeffizienten

Tabelle 4: DISK-System

Tabelle 5: Snapshot-System.

1 Einleitung

1.1 Motivation

1.1.1 Enterprise-Resource-Planning-Systeme

In diesem Abschnitt werden die begrifflichen Grundlagen von Enterprise-Resource-Planning (ERP) - Systemen erläutert.

Es wird nun definiert, worum es sich bei einem ERP-System handelt.

„Unter dem Begriff Ressource, die zur Begriffsbildung von Enterprise-Resource-Planning-Systemen beigetragen hat, werden natürliche oder gesellschaftliche Quellen der Grundlagen der Reproduktion verstanden, z. B. Bodenschätze. Der Begriff Enterprise Resource Planning hat sich aus dem ursprünglichen Planungskonzept für Stücklistenauflösung, Material Requirement Planning entwickelt, das dann zu Manufacturing Resource Planning erweitert wurde. Der Begriff ERP weist darauf hin, dass nicht nur Ressourcen aus der Fertigung betrachtet werden. Ein Enterprise-Resource-Planning-System deckt Funktionen aus mehreren Unternehmensbereichen ab. Als alternativer Begriff, insbesondere im deutschen Sprachraum, wird die Bezeichnung Betriebliche Anwendungssoftware oder Anwendungssystem verwendet. Dieser Begriff konnte sich jedoch bei Anbietern und Anwendern nicht durchsetzen. Wesentliches Merkmal von ERP-Systemen ist die Integration verschiedener Funktionen, Aufgaben und Daten in ein Informationssystem. Als minimaler Integrationsaufwand ist eine gemeinsame Datenhaltung anzusehen.“

[Gronau04, Abschnitt 1.1, S. 3-4]

„ERP-Systeme funktionieren wie das zentrale Nervensystem, das tendenziell die Fähigkeit aufweist, die Summe der Fähigkeiten der einzelnen Teile zu übersteigen (ein Phänomen, das wir als Bewusstsein bezeichnen). Sie bilden gewissermaßen das Bewusstsein des Unternehmens. ERP-Systeme verknüpfen insbesondere Informationen über Finanzen, personelle Ressourcen, Produktion und Vertrieb. Sie umfassen Lagerverwaltungssysteme, Kundendatenbanken, Auftragsverfolgungs-systeme, Kreditorenbuchhaltung und vieles andere mehr. Sie bieten je nach Bedarf auch Schnittstellen für Zulieferer und Kunden.“

[ERP08]

Ein ERP-System verknüpft also Information aus verschiedenen Bereichen eines Unternehmens und verwaltet sie zentral.

Motivation

1.1.2 Produktionsprozess

Das praktische Ziel der Diplomarbeit ist die Darstellung eines betriebswirtschaftlichen Prozesses in einem sogenannten Zoomable-User-Interface (siehe Abschnitt 2). Das entsprechende Prozess-Schaubild ist dabei vorgegeben (siehe Abbildung 1). Das Unternehmen OR Soft Jaenicke GmbH möchte dadurch eine neuartige Herangehensweise zur Bedienung von ERP-Systemen untersuchen. Bei dem Prozess handelt es sich um einen Produktionsprozess:

„Der Produktionsprozeß ... ist der Vorgang der betrieblichen Leistungserstellung, bei dem Produktionsfaktoren (input) eingesetzt, kombiniert und zu Ausbringungsmengen (output) transformiert werden.“

[Produktion09]

Ein Produktionsprozess ist also ein zeitlich ablaufender Vorgang der Erstellung von sowohl Sachgütern als auch Dienstleistungen im Betrieb. Dieser Prozess umfasst mehrere Teilprozesse.

Der umzusetzende Prototyp soll als Bedienbarkeitsstudie der Thematik innerhalb eines Zoomable-User-Interfaces dienen. Es wird kein Datenmodell angeschlossen. Die Aktionen, die der Anwender tätigen kann, sind wirkungslos und dienen lediglich zur Untersuchung der Bedienungsweise im Vergleich zur bisherigen Bedienung von ERP-Systemen. Abbildung 1 zeigt das Prozess-Schaubild.

Abbildung in dieser Leseprobe nicht enthalten

Nachfolgend soll der vorgegebene Produktionsprozess erläutert werden. Angenommen ein Betrieb stellt Produkte aus Materialien her. Nun kann die Situation eintreten, dass weniger Produkte vorrätig sind, als der Kunde bis zu einem Termin benötigt (Kapazitätskonflikt). Dann muss der Betrieb kalkulieren, in welcher Zeit er die fehlenden Produkte produzieren kann, und dabei auch betrachten, ob er genügend Materialien dafür besitzt (Materialkonflikt). Der Produktionsvorgang spiegelt sich in den Produktionsaufträgen wider (Auftragsvorrat). Ist es unmöglich den Termin einzuhalten, kann entweder die bereits produzierte Menge geliefert oder der Termin des Kundenauftrages verschoben werden. Diese Betrachtungen zu einem Kundenauftrag auf mehrere Kundenaufträge erweitert, ergibt ein einfaches Planungsszenario.

Im Prozess-Schaubild (siehe Abbildung 1) sind die Bestandteile Auftragsvorrat, Plantafel, Kapazitätskonflikte und Materialkonflikte als Knoten dargestellt. Die Kanten sind beschriftet, um dem Anwender zu verdeutlichen, mit welchen Aktionen die Konflikte behoben bzw. Auftragsvorräte eingeplant werden können.

1.2 Prototyp

Der zu dieser Arbeit gehörende Prototyp ist unter folgendem Link zu finden: http://www.iks.hs-merseburg.de/ZUI/ZUI_Prototype.zip Mirror: http://prot]otype.zui.bplaced.com/ZUI_Prototype.zip

Es wird empfohlen, den Prototypen vor der Lektüre zu betrachten, da die Bedienungsweise dieser Art von Interface für die meisten Leser ungewohnt und schwer vorstellbar sein dürfte. Auf die Feinheiten des Prototyps wird in Abschnitt drei näher eingegangen.

Abbildung 2 zeigt den Arbeitsplatz mit den manipulierbaren Objekten und den seitlichen Bedienfunktionen.

Abbildung in dieser Leseprobe nicht enthalten

1.3 Abschnittsübersicht

Abschnitt zwei gibt einen Überblick über die Thematik des User-Interface und behandelt anschliel3end die spezielle Ausprägung des Zoomable-User-Interface (ZUI). Im dritten Abschnitt geht der Autor auf den Entwurf und die Implementierung eines Prototyps unter Einhaltung des ZUI-Paradigmas ein. Schlussfolgerungen, Fragen und Ausblicke werden abschliel3end in Abschnitt vier dargelegt.

2 Zoomable-User-Interfaces und aktueller Stand

Dieser Abschnitt behandelt zunächst User-Interfaces im Allgemeinen und anschliel3end Zoomable-User-Interfaces im Speziellen. Bei beiden Themen wird auf die entsprechenden Grundlagen eingegangen.

2.1 User-Interface

In diesem Abschnitt werden ein kurzer Abriss der Entwicklung des User-Interfaces gegeben, die Erwartungen an ein User-Interface erläutert, Interface-Typen aufgezählt und Design-Aspekte beleuchtet.

2.1.1 Historische Entwicklung

Eine Anwendung setzt sich üblicherweise aus den drei Schichten des sogenannten Model-View-Controller (MVC) - Musters zusammen. Dies ist ein Muster, das die Softwarearchitektur einer Anwendung beschreibt. Es besteht aus den Schichten Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller). Die Model-Schicht enthält die persistenten Daten, meist als Datenbank realisiert. View ist die Schicht, die für die Interaktion mit dem Anwender zuständig ist. Zum Beispiel das Fenster auf dem Monitor. Die Controller-Schicht ist die „Logik“ (bzw. Algorithmik) hinter dem Softwaresystem.

Die View-Schicht könnte man also auch als User-Interface (UI) bezeichnen. Für die vom User wahrnehmbare Schicht der Anwendung gibt es synonyme Bezeichnungen: Benutzerschnittstelle, Bedienoberfläche, Anwendungsoberfläche, Softwareoberfläche, Dialogmaske, Dialogschnittstelle, Graphical-User-Interface (GUI), Human-Computer-Interface oder Mensch-Maschine-Schnittstelle.

Die Mitte der 60 er-Jahre eingetretene Softwarekrise [Krise08] führte zu einem Umdenken in der Softwareentwicklung: Es wurde klar, dass die bisherigen Methoden nicht ausreichten, der einsetzenden Komplexität der Softwaresysteme Herr zu werden. Es bildete sich der Begriff Software-Engineering. Also eine „zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.“

[Balzert01, S. 36]

Als Beispiele für heute verwendete Techniken des Software-Engineering können das Entity-Relationship-Model (ERM), Object-Oriented-Design (OOD), Unified-Modelling-Language (UML) oder Extensible-Markup-Language (XML) genannt werden. User-Interfaces sind vom Software-Engineering bis heute nur ungenügend berücksichtigt worden (XForms, XUL, UIML).

Beginnend mit dem Pionier der elektronischen Datenverarbeitung, Herman Hollerith, wurden zunächst Lochkarten in der elektronischen Datenverarbeitung (EDV) eingesetzt. Hollerith nutzte Lochkarten dazu, die Datenmengen der amerikanischen Volkszählung 1890/1891 zu bewältigen. Eine Lochkarte ist mit einer heutigen Batch -Datei vergleichbar, bei der ein Befehlsskript abgearbeitet wird. Bis in die späten 50 er-Jahre kamen in der EDV Lochkarten zum Einsatz. Bildschirm und Tastatur wurden erstmals 1960 verwendet [Rose85, S. 48]. Ab den frühen 60 er-Jahren kamen dialogisierte Anwendungen auf, die jedoch nur ein Aufsatz auf die bisherigen Batch-Aufrufe waren [Chlebek06, S. 29].

User-Interface

Grafische Benutzeroberflächen hielten mit der Einführung der Computermaus und grafischer Betriebssysteme wie Mac OS, X-Windows, MS Windows und Kool-Desktop-Environment (KDE) in den 80 er-Jahren Einzug [GUI08]. Sie lösten die vorherige Benutzerschnittstelle Kommandozeile ab. Grafische Benutzeroberflächen wurden erst durch die Entwicklung der Computermaus angestoßen, mit der man einen Mauszeiger auf dem Monitor positionieren konnte und dieser eine intuitive Alternative zu dem bisherigen Cursor darstellte. Das erste GUI wurde erstmals 1973 im Computer Xerox Alto verwendet [Icon08]. Erst bei GUIs erlangten Anwendungen reaktive Fähigkeiten. Das heißt, dass nicht nur eine Ausgabe stattfand (s. o.), sondern auch auf Eingaben reagiert wurde. Es gab also erstmals eine Ereignisbehandlung von Benutzeraktionen. Dies ist der Unterschied zu den bisherigen dialogisierten Anwendungen. Die rein prozeduralen Programme forderten nur an vordefinierten Stellen Eingaben.

Man begann grafische Steuerelemente zu entwickeln. An sie wurden bestimmte Aktionen gekoppelt. GUIs blieben nur Aufsätze über den eigentlichen Funktionalitäten der Anwendungen. Sie wurden nicht für die Bedürfnisse der Anwender entworfen. Nun bahnt sich nach der Softwarekrise eine neue Komplexitätskrise an. Die Aufbereitung der Daten für die Darstellung wird aufwändiger und die Interaktionsmöglichkeiten des Anwenders werden vielfältiger [Khazaeli05]. Diese Komplexitätskrise kann mit geeigneten User-Interface-Entwürfen, die nicht nur Aufsatz über Funktionalität sind, verhindert werden. Ein Interface sollte redundante und unwichtige Information vor dem Anwender verbergen und ihn kontextabhängig anleiten.

[Abschnitt nach Chlebek06, S. 27-33]

User-Interface

2.1.2 User-Interface - Erwartungsanalyse

Der Anwender eines Softwaresystems nimmt das Verhalten des User-Interfaces (UI) wahr und reagiert entsprechend seinen Annahmen über die Funktionalität der Software darauf. Er gelangt aufgrund seiner Erfahrung mit anderen Softwaresystemen zu diesen Annahmen oder interpretiert das Verhalten. Man kann die Erwartungshaltungen von Anwender und Oberfläche wie folgt abgrenzen: [nach Chlebek06, S. 37-38]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Erwartungen des Anwenders und der Oberfläche. Quelle: [Chlebek06, S. 37].

User-Interface

Aktionserwartung

Die Oberfläche erwartet Aktionen des Anwenders.

Reaktionserwartung

Der Anwender erwartet auf seine Aktion eine Reaktion der Anwendung.

Konvergenzerwartung

Der Anwender erwartet auf dieselbe Aktion dieselbe Reaktion wie zuvor.

Erfahrungs- und Funktionserwartung

Der Anwender erwartet aufgrund des Eindrucks, den die Anwendung vermittelt, eine entsprechende Funktionalität.

[nach Chlebek06, S. 37-38]

2.1.3 User-Interface - Typen

Benutzeroberflächen können nach Dialogform, Dialogmitteln oder nach Bedienungsparadigma klassifiziert werden.

Dialogformen

- Angeleiteter Dialog:

Von der Anwendung initiierte Dialoge; zum Beispiel grafische oder gesprochene

Auswahlmenüs.

- Formular-Dialog:

Die Anwendung gibt auszufüllende Formulare vor; spezielle Form des angeleiteten

Dialogs.

- Systeminitiierter Dialog:

Die Anwendung informiert über ein Ereignis und bietet Möglichkeiten an, darauf zu reagieren. Ebenfalls spezielle Form des angeleiteten Dialogs.

- Offener Dialog (nicht angeleiteter Dialog):

Der Anwender stellt an die Anwendung eine Anfrage und diese grenzt die Antwort- möglichkeiten ein.

User-Interface

Dialogmittel

Die Möglichkeiten zur Dialogführung, die dem Anwender zur Verfügung gestellt sind.

- Command-Line-Interpreter (CLI):

Eine Kommandozeile, in die der Anwender Befehle eingibt.

Beispiel: Unix Command-Shell.

- Text-User-Interface (TUI):

Bezeichnet grafische Benutzeroberflächen, die im Textmodus präsentiert werden.

Beispiel: Norton Commander.

- Graphical-User-Interface (GUI):

Eine grafikbasierte Benutzerschnittstelle, die Dialogfenster und in ihnen enthaltene Steuerelemente, wie Buttons, Slider oder Eingabefelder, bietet; beispielsweise die Benutzeroberfläche von Windows.

- Voice-User-Interface (VUI):

Schnittstellenkommunikation über gesprochene Befehle.

- Haptische User-Interfaces (HUI):

Außer den Wahrnehmungssinnen Sehen und Hören als Formen der Ausgabe spricht ein HUI auch den Tastsinn an. Benutzt werden HUIs in Simulatoren zur Nachahmung von Bewegungskräften.

Bedienungsparadigma

Es kann zwischen ablauforientierten und gegenstandsorientierten User-Interfaces unterschieden werden. Ein ablauforientiertes User-Interface bezeichnet eine hinter-einander erfolgende Ausführung von Schritten, etwa die Aneinanderreihung von Formularen in wirtschaftlich orientierten Anwendungen. In einem gegenstands-orientierten User-Interface werden Objekte direkt manipuliert. Dadurch werden Funktionen ausgelöst, etwa eine Funktion in einer Textverarbeitung.

[nach Chlebek06, Abschnitt 2.3]

User-Interface

2.1.4 Interfacedesign

Dieser Abschnitt beschreibt zum einen, wie man ein Interface entwerfen muss, damit es vom Anwender als Benutzeroberfläche empfunden wird. Zum anderen wird verdeutlicht, dass nicht nur der funktionale Aspekt eines Interfaces eine Rolle spielt, sondern auch das Marken-Image der Software durch ein Interface festgelegt wird.

“Making a computer useful is simple to design a good interface between man and machine.”

[Terry Winograd, 1996]

“I don’t know what percentage of our time on any computer-based project is spent getting the equipment to work right, but if I had a gardener who spent as much of the time fixing her shovel as we spend fooling with our computers, I’d buy her a good shovel. At least you can buy a good shovel.”

[Erasmus Smums]

“If a system’s one-on-one interaction with its human user is not pleasant and facile, the resulting deficiency will poison the performance of the entire system, however fine that system might be in its other aspects.”

[Raskin08, Einleitung]

Ein einfach gehaltenes User-Interface führt also zu effizienter Arbeit am Computer, da man seine Ideen sofort umsetzen kann.

[nach Stapelkamp07, Abschnitt 2.2]

I. Das Interface als Metapher – der wissensvermittelnde Aspekt

Interfaces avancieren zur Kunstform des 21. Jahrhunderts [nach Stapelkamp07, S. 467]. Man denke nur an Apples erfolgreichen tragbaren Mediaplayer iPod, der sich hauptsächlich durch seine revolutionäre Bedienung verkauft. Der iPod gewann 2002 den „red dot design award“, eine international anerkannte Auszeichnung für gutes Design [IDR08]. Bislang wird ein Interface zu Unrecht nur nach seiner Benutzerfreundlichkeit analysiert, obwohl man es mittlerweile auch als Kunstform betrachten kann. Die Möglichkeiten des Interfacedesigns geben dem Designer die Fähigkeiten an die Hand, seiner Kreativität freien Lauf zu lassen.

Bedingt durch den immer intensiver werdenden Umgang mit Computern, der schon Grundschülern im Unterricht gelehrt wird [LO08], ist ein Umdenken bisheriger Interface-Strukturen vonnöten. Systeme und Informationsräume werden immer komplexer und diese Flut von Information muss auf ein dem Anwender verständliches Maß herunter gebrochen werden.

„Die gotische Kathedrale machte den Menschen des Mittelalters die Unendlichkeit vorstellbar. Das moderne Interface tut nichts anderes. ... Johnson sieht in ... kulturellen Funktionen, die im Kern denen des Computer-Desktops bzw. den Absichten aller Benutzeroberflächen gleichgesetzt werden können, eben die Übersetzung komplexer Zusammenhänge in überschaubare Strukturen und Reduktion auf das, was, je nach Anforderung, gerade eben als das Wesentliche gilt – das Interface als Metapher. Metapher im Sinne davon, komplizierte Vorgänge zu versinnbildlichen. Die gotische Kathedrale wurde oft als das erste Lichtkunstwerk bezeichnet, wobei das subtile Licht als Abbild Gottes und des Universums gilt. So wie damals die Menschen glaubten, im Anblick eines Kathedraleninnenraumes ihre aktuelle Realität, Verortung und somit Orientierung erkennen zu können, so scheinen wir heute im Blick durch das Fenster des Computermonitors wesentliche Anteile unserer Realität zu sehen und zu verstehen. Eine bessere Metapher als ‚Windows' ist dafür wohl nicht zu finden.“

[Stapelkamp07, S. 468]

Ein Interface sollte dem Anwender den Eindruck eines Handlungsspielraums vermitteln. Es sollte ihm zumindest die Illusion geben, selbst zu manipulieren, anstatt das Interface als Werkzeug zu betrachten, mit dem er vordefinierte Funktionalität abruft. Es besteht ein Defizit von Kriterien zur Bewertung des Interfaces als Kommunikationsform. Bisher existieren lediglich technologische Kriterien. Will man ein Interface aber nicht nur zur Beschreibung von Funktionalität, sondern auch zur interaktiven Wissensvermittlung nutzen, müssen emotionale und sinnliche Kriterien gefunden werden. Wie „fühlt“ das Interface sich an?

[nach Stapelkamp07, Abschnitt 2.2.1]

II. Das Interface als Benutzeroberfläche – der funktionale Aspekt

Bei interaktiven Informationsmedien steht der inhaltliche Aspekt im Vordergrund. Der funktionale Aspekt spielt eine zweitrangige Rolle. Es geht bei Software hauptsächlich darum, dem Anwender Information zu vermitteln. Funktionalität sollte nur Mittel zum Zweck sein – außer natürlich, Funktionalität selbst wird benötigt. Wie er zur Information gelangt, ist unerheblich. Trotzdem werden Interfaces vom Anwender vorrangig funktional verstanden. Somit sind sie dazu verdammt, diese Erwartung zu erfüllen. Der inhaltliche Aspekt wird nebensächlich. Also herrscht beidseitig – sowohl beim Anwender als auch beim Produzenten – das Interesse an reinen Funktionen statt Inhaltsvermittlung. Produzenten glauben, mit einer möglichst langen Feature-Liste ihre Produkte besser verkaufen zu können. Funktionen dürfen aber nicht nur Selbstzweck sein, sondern sollen dem Anwender informationell aufbereitete Inhalte vermitteln. Ein Interface sollte redundante und für den Anwender unerhebliche Information weglassen und ein möglichst weites Funktionsspektrum bieten, während es zugänglich gehalten wird. Es kann mit diesem Paradigma jedoch auch übertrieben werden, was zu einem völligen Blackbox-Verhalten des Systems führt. Es muss beim Design überlegt werden, ob dem Anwender nicht mehr Einblick in einen funktionalen bzw. inhaltlichen Ablauf gegeben werden sollte.

Ein Interface sollte nicht nur Funktionen anbieten, sondern diese idealerweise auch erläutern. Diese Erläuterung wird inhaltsbezogen in die Gestaltung eingebettet. Es ist ratsam, die wissensvermittelnden und funktionalen Aspekte eines Interfaces als gleichrangig zu erachten.

[nach Stapelkamp07, Abschnitt 2.2.2]

III. Das Interface als Bedeutungsträger

Ein Interface ist die Basis für die Interaktion mit dem System. Die Interaktion wird durch eine Assoziation provoziert. Im Sinne des Designleitsatzes von Louis Sullivan („Form folgt Funktion“) sollte die Gestaltung sich aus dem Nutzungszweck ableiten. Das ermöglicht dem Anwender, die Funktion aus der Form des Interface-Elements abzuleiten. Ein Interface kann also seine Bedeutung in sich selbst tragen und somit selbsterklärend sein.

„Als plakatives Beispiel stelle man sich ein Jagdmesser mit einer langen Klinge und Blutrinne vor, das definitiv eine andere Botschaft sendet und beim Empfänger andere Assoziationen freisetzt, als z. B. das bekannte Schweizer Offiziersmesser. Dessen Hersteller werden beim Design stets darum bemüht sein, Produkte fernab jedweder Gewaltaussage zu gestalten. Mit dem Design dieses Produkts soll für den Empfänger, potentiellen Käufer und Anwender, ein Interface wahrnehmbar werden, das die Botschaft ‚harmlos aber praktisch‘ sendet.“

[Stapelkamp07]

Es geht um die Botschaft, die ein Objekt vermittelt. In diesem Fall ein aggressives

Design gegenüber einem nützlichen Design.

[nach Stapelkamp07, Abschnitt 2.2.3]

Zoomable-User-Interface

2.2 Zoomable-User-Interface

In diesem Abschnitt wird das Konzept des Zoomable-User-Interface (ZUI) vorgestellt. Es wird eine Definition gegeben und es werden Vorteile gegenüber der klassischen grafischen Benutzeroberfläche erläutert.

Bis heute werden Benutzeroberflächen nach GUI-Konzepten aus den 70er-Jahren entworfen. Ein dominierendes Konzept ist dabei das WIMP-Paradigma, das in den späten 60ern von Douglas Englebart entwickelt wurde. WIMP steht für Windows, Icons, Menus und Pointer. Die ersten massenproduzierten WIMP-basierten Computer waren Lisa (1983) und Macintosh (1984). Der erste Produktionscomputer, der die Desktop-Metapher verwendete, war der Xerox Star (1981).

[Ge08]

Diese grundlegenden Konzepte haben sich bis heute nicht geändert und finden noch in aktuellen Betriebssystemen und Benutzeroberflächen Verwendung. Zoomable-User-Interfaces bieten einen intuitiveren Ansatz: Mit ZUIs versucht man, die physischen Gegebenheiten des realen Arbeitsplatzes nachzubilden. Der Anwender arbeitet auf einer unendlichen Ebene. Mit verorteten Informationsobjekten kann durch Zooming und Panning interagiert werden. Zooming erlaubt das Fokussieren und Verkleinern von Objekten. Durch Panning kann die gesamte Informationsebene verschoben werden, so dass Inhalte außerhalb des Sichtbereiches erreichbar werden. Es wird also mithilfe von Transformationen die Arbeit mit Objekten des Arbeitsplatzes wie Zetteln, Büchern und Stiften emuliert.

Das ZUI-Paradigma entstand unwesentlich später als das WIMP-Paradigma. Es wurde Ende der 70er-Jahre anhand wissenschaftlicher Prototypen erforscht.

Nun soll definiert werden, was unter einem ZUI zu verstehen ist.

“Zoomable User Interfaces (ZUIs) are a visualization technique that provides access to spatially organized information. A ZUI lets users zoom in and out, or pan around, to view much more information than can normally fit on a single screen.” [CoBe99, S. 3]

“Zoomable User Interfaces are a kind of information visualization application. They display graphical information on a virtual canvas that is very broad and has very high resolution. A portion of this huge canvas is seen on the display through a virtual “camera” that can pan and zoom over the surface.” [BeMeGo00, S. 2]

Ein ZUI erlaubt also dem Anwender, auf Informationsobjekte zuzugreifen, die frei auf der Ebene verortet sind. Navigiert wird mit Zooming und Panning.

Es gibt verschiedene Ausprägungen des Zoomings, die nachfolgend genannt werden. Die drei Grundtypen sind geometrisches Zooming, Fischaugen-Zooming und semantisches Zooming:

“There are three basic types of zooming.

Geometric zooming allows the user to specify the scale of magnification and increasing or decreasing the magnification of an image by that scale. This allows the user focus on a specific area and information outside of this area is generally discarded. A great example is mapping software like MapQuest or Yahoo.

The fisheye zoom is similar to the geometric zoom with the exception that the outside information is not lost from view; this information is merely distorted.

Semantic zooming approaches the process from a different angle. Semantic zooming changes the shape or context in which the information is being presented. An example of this type of technique is the use of a digital clock within an application. In a normal view, the clock may show the hour of the day and date. If the user zooms in then the clock may alter it’s appearance by adding the seconds and minutes. If the user that zooms out, information is discarded with only the date remaining. The actual information did not change, only the presentation method.”

[Stephens03]

“In semantic zooming, objects change appearance or shape as they change size. For example a growing dot will become a simple box, then a box with a one-word label, then a box with a longer label, then a rectangle filled with text and pictures. The goal is to give the most meaningful presentation at each size.”

[UMDL96]

“Another advantage of using a zoomable interface is to allow objects to have multiple representations, which is called semantic zooming [BeHo96] . When an object is zoomed out and becomes small, contents inside the object, such as text, become illegible and less useful.”

[SuBe01, S. 17]

Das geometrische Zooming erlaubt also das Vergrößern und Verkleinern von Objekten, indem die Skalierung geändert wird. Verwandt damit ist das Fischaugen-Zooming, das Objekte im Fokus vergrößert darstellt und – ausgehend von diesem Objekt – andere Objekte kleiner werden lässt. Das semantische Zooming ähnelt dem geometrische Zooming, wobei sich hier der Informationsgrad in Abhängigkeit von der Skalierung ändert.

Zoomable-User-Interface

2.2.1 Anforderungen an ein ZUI

Bederson et al. stellen in [BeMeGo00, S. 2] die folgenden Anforderungen an ein ZUI.

Ein Zoomable-User-Interface dient der Darstellung von Information. Die Information befindet sich auf einer breiten virtuellen Leinwand in hoher Auflösung, wobei über eine Kamera ein Ausschnitt zu sehen ist. Die Oberfläche kann verschoben und fokussiert werden.

1. Das ZUI muss benutzerdefinierte Grafiken unterstützen.
2. Es muss eine große Zahl von Objekten unterstützt werden, sodass die Performance des Renderings und der Interaktion sich nicht vermindert.
3. Objekte müssen willkürliche Transformationen und hierarchische Gruppierung unterstützen.
4. Navigations-Sichten (Pannen und Zoomen) müssen weich und durchgängig animiert sein.
5. Es müssen mehrere Repräsentationen von Objekten unterstützt werden, sodass semantisches Zooming möglich ist.
6. Mehrere Sichten auf die Oberfläche müssen über Portale oder Linsen möglich sein.
7. Objekte müssen sich verankern lassen, sodass sie bei Navigation ihre Position behalten.
8. Benutzerdefinierte Ereignisbehandlung muss möglich sein, um die Manipulation von individuellen Elementen und Gruppen von Elementen zu unterstützen. [nach BeMeGo00, S. 2]

Für das Zooming gibt es verschiedene Herangehensweisen.

1) Der Anwender wählt ein Objekt durch Anklicken aus und die Kamera zentriert sich darüber, um anschliel3end automatisch heranzuzoomen, bis das Objekt bildschirmfüllend dargestellt wird. Diese Komposition aus Zentrierung und anschliel3endem Zoom ist auch in Kombination eines Vektors möglich: in der Form, dass die Kamera „schräg“ an das Objekt heranfährt. Diese Art des Zoomings wird zum Beispiel in der Bildbetrachtungsanwendung PhotoMesa^[1] eingesetzt.
2) Eine zweite Möglichkeit ist, den Referenzpunkt (Zooming Reference Point, ZRP) mit Klick auf die Oberfläche festzulegen (Kamera zentriert über ZRP) und anschliel3end die Fokussierung manuell zu justieren, also Zooming abhängig vom Referenzpunkt. Diese Möglichkeit wird in Piccolo-Anwendungen^[2] verwendet.
3) Ein weiterer Ansatz ist, eine zusätzliche kleine Übersichtskarte von der Oberfläche zu geben und den Anwender darüber navigieren zu lassen. Ein manipulierbares Rechteck gibt den Ausschnitt in der Hauptansicht vor. Diesen Ansatz zeigt Donelson in seinem Dataland [Donelson78, S. 203-209] auf.
4) Woodruff et al. [WoLaSt98, S. 305-306] schlagen die Möglichkeit vor, über Shortcuts oder Buttons zu Orten auf der Oberfläche zu springen. Eine Abart von Aufzählungspunkt 1), beispielsweise implementiert als Lesezeichen (siehe Abschnitt 2.2.2).
5) Werner A. König verwendet in seinem ZOIL-Prototyp^[3] einen mit der Maus aufziehbaren Rahmen, der um den zu vergröl3ernden Ausschnitt gelegt wird.

Bei der Navigation durch Panning und Zooming kann folgendes Problem auftreten: Der Anwender kann sich ins „Aus“ navigieren – eine Situation, in der der Anwender die Übersicht verliert. a) Dies kann auftreten, wenn er soweit herauszoomt, dass die Objekte zu sehr verkleinert sind und er nichts mehr erkennen kann.
b) Äquivalent dazu kann ein übermäl3iges Heranzoomen an die Oberfläche zum Verlust des Informationsgehalts führen, da die Objekte zu grol3 dargestellt werden: Man sieht einen vergröl3erten Ausschnitt weniger Objekte.
c) Es gibt auch die Situation, dass der Anwender sich durch Panning zu einer Position navigiert hat, an der keine Objekte verankert sind. Er sieht also nur die Leinwand. Allgemein ergibt sich das Problem durch fehlende Orientierungspunkte, an denen der Anwender sich ausrichten könnte – er weil3 nicht, wie er wieder zu den Informationshaufen gelangt.

Die Lösung dieses Problems ist trivial: Der Anwender muss in der Navigation begrenzt werden oder, um die obige Situation c) zu vermeiden, automatisch zum nächstgelegenen Informationscluster weitergeleitet werden. Büring et al. [BüGeRe06, S. 3] weisen auf die Möglichkeit hin, zu einem bestimmten Informationscluster zu animieren. Dabei wird der Anwender durch eine Animation, bestehend aus automatischem Panning und Zooming, zum nächsten informationstragenden Punkt weitergeleitet. Falls der Endpunkt weiter als eine Bildschirmgröl3e vom Startpunkt entfernt ist, wird zu einem mittleren Punkt herausgezoomt, sodass beide Punkte sichtbar sind. Dann wird zum Endpunkt gezoomt. Das gibt dem Anwender einerseits eine Kontext-Übersicht und beschleunigt andererseits die ansonsten nötige manuelle Navigation.

Bei der ZUI-Bibliothek Pad++ [BeHo94, S. 17-26] umgehen Bederson et al. das Problem durch vorgegebene Navigationswege und automatische Zooms auf spezielle Bereiche. Aul3erdem machen sie indirekt einen Lösungsvorschlag für die Situation der Problematik a) [BeHo94, S. 6]. Egal, wie weit der Anwender herauszoomt: Selbst wenn Objekte so klein sind, dass sie unsichtbar sind, werden ihre Marker trotzdem angezeigt.

Der Autor schlägt nun zur Navigationsbegrenzung verschiedene Lösungen vor. Die Distanz zwischen verschiebbaren Objekten müsste nach oben begrenzt werden, um grol3e Freiräume und abgelegene Objekte zu vermeiden. Die Skalierungsstufen des Heran- und Herauszoomens sollten limitiert sein und die Navigation aul3erhalb von Randbereichen der Leinwand unterbunden werden.

Die sechste Anforderung an ein ZUI besagt, dass mehrere Sichten auf die Oberfläche über Portale oder Linsen möglich sein müssen. Es soll nun nach Bederson et al. [BeHo96] definiert werden, was Portale und Linsen sind.

[...]

---

^[1] http://www.cs.umd.edu/hcil/photomesa/.

^[2] Programmier-Bibliothek zur Erstellung von ZUIs.

^[3] http://www.kingsys.de/.