VisualComputing: Benutzerschnittstellen

-bei UI Entwicklung: iterative Entwicklung, schrittweise Verfeinerung (Gestaltung ist keine definierte Optimierungsaufgabe), Zyklen, ständig kompromisse nötig

-bei klassischer Softwareentwicklung: klar getrennte zeitliche Phasen, formale Methoden

> Spielekonsolen (Wii, Xbox Kinect)
> Webbasierte Systeme (XING, Facebook)
> Eingebettete interaktive Systeme (Verschmelzung von realen
Geräten und Software → Waschmaschine, Kopiergeräte,
Kaffeemaschine, !! Cockpit moderner Autos → Fahrzeugnavigation,
Mediensteuerung)
> Multitouch- und Sensorbasierte Systeme (ReacTable,
SmartPhone)
> Interaktive Systeme für kreative Systeme (Mind Manager,
Wikis)
> Benutzerschnittstellen mobiler Geräte (PDA, Handys)
> Sicherheitskritische Anwendungen (Master-Slave-Roboter)

„As we may think“
> Menschen denken assoziativ → inhaltsbasierte Suche nach Infos
> MEMEX
„soll in dieser personalisierten Bibliothek so suchen können
wie der Mensch in seinem Langzeitgedächtnis nach Informationen
sucht und damit den menschlichen Speicher erheblich erweitern“
> Aufbereitung von Informationen (Digitalisierung,
Schlüsselwörter, Querverweise)
> Integration von Lesezeichen, Notizen, Anmerkungen
==> Konsequenz für GUI: Orientierung an realen Modellen
(Analogien mit Bibliotheken, Büchern)

• 1960 Licklider als Begründer
• höhere Produktivität durch Benutzerschnittstelle
• Erschließung neuer Anwendungsfelder mithilfe neuer Benutzerschnittstelle

Ziele:

• Computer als kooperativer Partner
• Interaktive Arbeit
• Trial-and-Error Prozesse

Von ihm geforderte kurzfristige Anforderungen an die Interaktion (eher technologisch):

• Time Sharing Systeme zur Feststellung der Rechnerzeit
• große Speicher, schnelle Prozesse etc.

Von ihm geforderte langfristige Aufgaben bezüglich der Interaktion:

• Verstehen natürlicher Sprache
• Erkennung von Zeichnungen und Gesten

-Begründer: Sutherland and Jonsen

-Erstes CAD Programm der interaktiven Computergrafik

-Benutzte erstmals folgende Konzepte:

• Die Übertragung einer per Hand gezeichneten Skizze (Grafiktablett und Stift (Light Pen) in elektronischer Form
• Speichern und Einordnen der Objekte/Skizzen in Objekthierarchien
• Anzeige der Objekte als Vektorgrafiken
• Erstmals konnten Objekte auf dem Screen direkt manupuliert werden

-Analyse des Problemlöseverhaltens

-Unterstützung von Menschen bei der Lösung

-Engelbert erfand die "Maus"

-Nelson entwickelte die Hyper Text

-Entwickelte fensterbasiertes NLS (On Line System)

-Erste Verwendung von grafischen Bildschirmen

-1979-81: Erstes kommerzielles System mit grafischer Benutzeroberfläche

-Zielstellung: Erstellung und Verwaltung von Dokumenten, Terminen, Nachrichten, Tanellenkalkulation und Geschäftgrafiken

Zielgruppe: Manager ► kaum Erfahrung mit Computern und hoher Zeitdruck

Technologien: Eigene Workstation mit anderen Rechnern vernetzt, grafischer Bildschirm mit Fenstern und Icons, Steuerung mit Maus

Ursachen des geringen Erfolgs: Späte Markteinführung, hoher Preis, einseitige Konzentration auf neue Interaktionstechniken, starke Verkettung der Anwendung (Monolithisch), kaum Drittanbieter, keine Freigabe der Entwicklungswerkzeuge, keine Gestaltungsrichtlinien

1. Direkte Manipulation

2. Drag and Drop

3. Einführung der Zwischenablage

-Strikte Trennung von Anwendung und GUI

-Nutzen von Ressource Dateien

-Entwicklung und Weiterentwicklung von Styleguides

-Quantitative Ziele bei der Evaluierung, konkrete und harte Termin- und Kostenvorgaben

-Konsequente Unterstützung von Drittanbietern

-Werkzeuge und Richtlinien für Drittanbieter

-Vorgefertigte Klassen für Dialogelemente

-integrierte Tools zur Erstellung von Logos und Icons

-Schnelle Erstellung von interaktive Systemen

-Eingabegeräte werden überflüssig da direkte Manipulation durch zB. Touch- und Spracheingaben Standard werden

►Neue Benutzerschnittstellen müssen daher darauf angepasst werden

-Ende der 80er Jahre diente es dem Daten- und Mailaustausch

-Ziel: Informationsaustausch

-Anfänge: Interne Nutzung

-Ereignis wird jeweils innerhalb einer bestimmten Komponente ausgelöst und an anderer Stelle darauf reagiert

-Untersuchung verschiedener Konzepte dahingehend:

• wie eine Ereignisbehandlungsroutine über das Auftreten eines bestimmten Ereignisses informiert wird
• wie die Unterscheidung verschiedener Ergebnisse vorgenommen wird

-Listener melden sich bei Komponenten an

-Komponenten benachrichtigen Listener, wenn Events auftreten

-onBlur, onChange, onClick, onDblClick, onFocus, onSubmit, onKeydown, onKeyup,onKeypress, onLoad, onUnload, onReset, onSelect, onMousedown, onMouseup, onMouseover, onMousemove, onMouseout

Event-Listener: FocusListener, ActionListener, AdjustmentListener, ItemListener, TextListener, KeyListener, MouseListener, MouseMotionListener, WindowListener, ContainerListener, ComponentListener

Die Komponente mit registriertem Listener muss zum Zeitpunkt des Events im Fokus sein.

-Zentralisierte Verarbeitung

-Eigene (externe) Klasse

-Innere Klasse

-anonyme innere Klasse

-Ereignisse können textuell sehr nahe an der Erzeugung der Komponente implementiert werden ⇒ Der Code wird übersichtlicher

-Es müssen keine neuen Klassen mit eigenen Namen erzeugt werden⇒Die gesamte Klassenhierarchie wird übersichtlicher und deutlich kleiner

JMenuBar, JMenu, JMenuItem

AWT & Swing+AWT: JButton, JMenu, JLabel, JTextfield, JPanel, JFrame, JSlider, JColorChooser, JFileChooser

Flow-, Border-, Box-, Grid-, Spring- und GroupLayout

-ein optisch ansprechendes Layout entsteht durch die Verschachtelung verschiedener Layout-Manager

-ebense können nur hierdurch komplexe und flexible Benutzeroberflächen gestaltet werden

• Einem Model können mehrere Views zugeordnet werden
• VIews können leicht ausgetauscht, hinzugefügt und erweitert werden
• Verbesserte Wartbarkeit und Wiederverwendung
• Mehrere Ansichten werden synchronisiert, weil sie auf die gleichen Daten lauschen

-Das Model implementiert das Observer Muster (kann durch Eventlistener oder Observer realisiert werden)

• Auf das Model wird ein Listener gesetzt, der alle angemeldeten View Komponenten benachrichtigt, sobald sich etwas am Model geändert hat
• Diese Änderungen verursachen Aktualisierungen der View
• Das Model braucht auf diese Weise die View nicht zu kennen (lose Kopplung)
• Model erweitert die Observable Klasse, über die sich verschiedene Komponenten als Beobachter/Listener anmelden lassen
• Bei jeder Änderung lässt sich die notifyObservers() Methode aufrufen, die die Änderung an jeden Beobachter weiter gibt
• Die Beobachter müssen die Klasse Observer mit deren einziger Methode update() erweitern
• Die Methode wird immer aufgerufen, wenn sich das Model geändert hat

-View und Controller implementieren das Strategy Muster  

• Die View ist mit einer bestimmten Strategie gekoppelt. Diese Strategie wird vom Controller implementiert
• Die Strategie kann man in separate Klassen auslagern, damit man sie zur Laufzeit je nach Bedarf austauschen kann
• Eine mögliche Strategie ist das Rendern des Aussehens eines Fensters. Das sieht unter Windows zB anders aus als unter Mac OS. Das liegt daran, dass die Algorithmen zum Rendern des Fensters beim Start des Programms je nach Bedarf(System) ausgetauscht werden
• Ermittelt an den Daten, die die View bei einem Event weiter gibt die zugehörigen Models und nimmt ggf Änderungen an dem Model vor
• Kennt View und Model
• Meist sind die Listener die Controller. Eine Action auf einer View Komponente führt über einen Controller zu einer Statusänderung im Model
• Die Views werden dann durch einen Update Mechanismus aktualisiert (siehe Observer Pattern)

-Die View implementiert das Composite Muster

• Alle grafischen Komponenten sind von der Klasse Component abgeleitet
• Das sorgt dafür, dass alle Ereignisse bei jedem Objekt gleich angenommen und behandelt werden können
• http://en.wikipedia.org/wiki/Composite_pattern
• Composite Muster ist nur zur Strukturierung und Kapselung von gemeinsamen Funktionen gedacht
• Kennt Model und Controller

Zustandslogik

• Hier wird der Zustand der Views und der Software gespeichert und verarbeitet

Datenlogik

• Hier werden Daten gespeichert, so wie in der Datenbank

Anwendungslogik

• Hier sind die Funktionen die für die Verarbeitung der Informationen zustänid ist

View

• Darstellung der benötigten Daten und die Entgegennahme von Benutzerinteraktionen. Nicht für Weiterverarbeitung der vom Benutzer angebenen Daten

Controller

• Nimmt die Benutzerinteraktion entgegen, wertet diese aus und agiert entsprechend. Zu jeder View existiert ein Controller, welcher die Daten manipuliert, entscheidet auf Grund der Benutzerinteraktion auf der View, welche Daten verändert werden müssen und schränkt die Benutzerinteraktion der View ein
• Schaltzentrale

-Das Model weiß nichts über die beiden anderen Komponenten. Dabei wird das Model von der View auf Veränderungen beobachtet. Hier wird nach dem Entwurfsmuster des Beobachters vorgegangen.

1.  User interagiert mit View
2. Controller fordert Modell auf seinen Zustand zu ändern
3. Controller fordert View auf geänderten Zustand zu zeigen (Manchmal optional → Sorgt für Feedback zum Beispiel in Form eines ausgegrauten Buttons o. Ä. / Hier werden nochkeine Daten geändert, nur Anzeige in der View)
4. Modell benachrichtigt View, dass es sich geändert hat
5. View erfragt Details über Änderung bei Modell

- Der Controller ist sozusagen ein Übersetzer (Mensch-Maschine)

-Der Controller besitzt die Listenerfunktion und sorgt für die richtige Reaktion bei einer Aktion auf bestimmte Objekte.

-Man kann dank des Controllers die Listener auch aus dem Model und der View auslagern►dadurch können Views auch variabel gehalten werden

> View muss nicht geändert werden!
> im Controller können relativ einfach Funktionalitäten aktiviert bzw. deaktiviert werden
> Model kann relativ leicht ausgetauscht werden
> View ist für andere Modelle verwendbar, somit in anderen
Anwendungen
> View ist mit anderen Controllern verwendbar, somit ist anderes Verhalten möglich

• HerzModel an BeatModel anpassen
• DJView die Möglichkeit geben, direkt mit HerzModel zusammenzuarbeiten
• Wenn Methoden in Verbindung mit einem Herz keinen Sinn machen, keine Implementierungen erstellen
• Man kann eine komplett andere Logik hinter der View haben, ohne sie zu ändern
• Adpater übersetzt die Aufrufe aus der DJVIew in Aufrufe aus dem HerzModel

• Benutzung vertrauter Begriffe, einer Analogie zur Erklärung von Systemen und Konzepten in einer unvertrauten Zieldomäne

Dekstop-Metapher

• Dem PC Interface wird eine Schreibtischfunktion zugeordnet. Es handel sich um eine räumliche Metapher, weil man sich die physischen Orte von Dateien/Ordnern auf dem Desktop merkt (Statt der genauen Namen und Verzeichnissen)

Interface-Metapher

• Cursor-Icons-Greifen-Zeigen

Haus Metapher

• EIne Datei oder Odernerstruktur wird auf den Aufbau eines Hauses oder einer Stadt gemappt. Dabei gibt es einen Home Button, der einen immer wieder nach Hause bringt (Startseite oder "Heimverzeichnis). Ein Tür Symbol wird oft für das Beenden oder Verlassen eines Systems genutzt

Menü Metapher

• Menüs sind grundsätzlich Speisekarten nachempfunden. Dabei blätter man aber sichtenweise durch alle (Unter-) Menüs, statt sie wie am PC aufzuklappen

> Schreibmaschine (Textverarbeitung)
> Buch (Hypertext-Systeme)
> Raum (Spiele)
> Fernsehen (WWW-Browser)
> Desktop (Fenster, Slider, Menü, Mülleimer)