Teil 1 Kurzgeschichte des Benutzerinterfaces · 1 Anwendungssysteme SS03 Gerald Friedland,...

1

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 1

GUI Programmierung

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 2

Teil 1Kurzgeschichte des Benutzerinterfaces

2

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 3

Geschichte: Die ersten Rechenmaschinen

ENIAC, 1946

Zuse Z3,1941

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 4

Geschichte: Computer zweiter Generation

Eingabe: Lochkartenleser

Ausgabe: Drucker

1955-1965

3

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 5

Geschichte: Die ersten Terminals

IBM 2741, 1975

Amdahl 470/U6,1977

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 6

Geschichte: Das Textterminal

IBM SAA Standard, 1987

Hier: Turbo Pascal

Commodore 64, 1982

4

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 7

Geschichte: Windows 1.0 (1985)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 8

Geschichte Windows 2.0 (1987)

5

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 9

Geschichte: Windows 3.0 (1990), 3.1 (1993)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 10

Geschichte: Windows 9x, XP

Windows 95: 1995

Windows 98: 1998Windows ME: 2000

Windows NT: Abkömmling von OS/2Windows 2000: 2000Windows XP: 2001

6

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 11

Teil 2 Grundlagen

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 12

Benutzbarkeit (Usability)

Usability = Effectiveness + Efficiency + Satisfaction(Dix et al.)

7

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 13

Die Kommandozeile

- Historisch entstanden- Schnell zu bedienen- Leicht zu automatisieren

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 14

Die Kommandozeile

- Hauptvorteil: Maximal große “Eingabedomain” => Mächtig, maximaler Freiheitsgrad.

- Hauptnachteil: Maximal große “Eingabedomain” => Nicht ohne erhebliches Vorwissen

bedienbar.

=> Problem: Freiheitsgrade einschränken, aber universelle Bedienbarkeitbehalten.

8

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 15

Die GUI

Erster kommerzieller Rechner mit GUI: Apple Lisa, 1983.

Vorher Forschung am Xerox Parc (z.B. Erfindung der Maus durch Douglas Engelbart 1968).

Entscheidende Idee: Die Desktop-Metapher

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 16

Die Desktop Metapher

Grundidee: Der Computer erweitert den Schreibtisch

9

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 17

Nichtanwendbarkeit der Desktopmetapher

- Die Desktopmetapher hilft die Zeit zu minimieren, die man braucht, einenBrief zu schreiben, zu drucken, zu speichern und zu löschen. Aber istsie z.B. für einen Netzwerkadministrator hilfreich?

- Sehr wichtiges Anwendungssystem für das die Desktopmetapher imAllgemeinen ungeignet ist: Computerspiele.

- Wahl der Metapher hängt von der Hardware ab: PDAs, IntegrierteSysteme, Wandtafeln (E-Chalk), etc... brauchen eine andere Metapher.

Aktuelle Forschungsdisziplin: Human Computer Interface Design (HCI)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 18

GUI Standards

- Microsoft: The Windows Interface Guidelines for Software Design: An Application Design Guide, Microsoft Press, Redmond, WA, 1995.

- Apple: Macintosh Human Interface Guidelines, Addison-Wesley, Reading, MA, 1993.

- Apple: Aqua Human Interface Guidelines, Apple Inc, Cupertino, CA, 2001.

- Sun: Java Look and Feel Design Guidelines, second edition, Boston, MA, 2001 und Java Look and Feel Design Guidelines: AdvancedTopics, Addison-Wesley, Boston, MA, 2002.

10

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 19

Teil 3 Designprinzipien

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 20

Prinzip 0

Do not think „inside-out“

- Häufigstes Problem nicht nur bei der Entwicklung von Software: „Betriebsblindheit“

Andere Beispiele:

- Vorlesungen

- Aufsätze (vor allem technische Beschreibungen)

- Soziale Phänomene („von sich auf andere schliessen“, „sich in eine Lage nicht hineinversetzen können“)

11

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 21

Prinzip 1

Orientiere Dich nicht an dem, was durch die Technik vorgegeben wird, sondern konzentriere Dich auf die

Benutzer und Ihre Aufgaben

- Welche Fähigkeiten hat der Benutzer?

- Bei welchen Aufgaben soll ihm das Programm helfen?

- Wie kann das Programm die wichtigsten Aufgaben des Benutzers schnell erledigen und die selteneren überhaupt?

„Common things should be easy, advanced things should be at least possible“(Larry Wall)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 22

Prinzip 2

Denke erst an die Funktion, dann an die Präsentation

- Weniger ist mehr

- Halte Dich an Standards, sei nicht an der falschen Stelle kreativ.

- Halte es so einfach wie möglich, aber nicht zu einfach (Negativbeispiel: mv in Unix)

- Benutze vorgegebene GUI Komponenten nur so, wie sie gedacht sind

12

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 23

Prinzip 3

Denke daran, wie der Benutzer seine Aufgaben sieht

- Lass Deinen Benutzer keine unnatürlichen Handlungen ausführen (Beispiel: Schachprogramm)

- Führe keine willkürlichen Beschränkungen ein (typischer Fehler: konstante Arraylängen)

- Benutze das Vokabular des Benutzers

- Behalte Programminterna im Programminnern

- Finde den richtigen Kompromiss zwischen Mächtigkeit und Komplexität des Programms

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 24

Prinzip 4

Fördere den Lernprozess des Benutzers

- Strukturiere logisch, vermeide Widersprüche (gutes Beispiel: Unixphilosophie)

- Sei konsistent (Vorsicht: Konsistenz bringt auch Probleme mit sich)

- Schaffe eine risikolose Umgebung (Beispiel: Undo, Redo)

- Gib intelligente Standardwerte vor

13

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 25

Prinzip 5

Vermittle Inhalt, nicht nur Daten

- Dein Programm muss sich sinnvoll präsentieren: Es muss zu jeder Zeit klar sein, was der nächste Schritt ist.

- Das Programm muss dem Anzeigemedium angepasst sein (Beispiel: 1280x1024 auf einem PDA?)

- Bildschirmmeldungen müssen erklärend, verständlich und angebracht sein (Negativbeispiel: Geldautomat).

- Der Bildschirm gehört dem Benutzer (Negativbeispiel: Officeassistenten)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 26

Prinzip 6

Garantiere die Ansprechbarkeit des Programms

- Das Programm sollte möglichst immer ansprechbar sein. (Negativbeispiel: Internet Explorer)

- Wenn das Programm ausnahmsweise nicht ansprechbar ist, sollte der Benutzer darüber informiert werden, was das Programm gerade tut und wie lange noch. (Beispiel: Busy Cursor, Progress Bar)

- Alle längeren Aufgaben sollten grundsätzlich abbrechbar sein.

Responsiveness = Perceived Performance

14

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 27

Prinzip 7

Probiere Dein Programm an Benutzern aus- Zwei Ziele: Sozial, Inhaltlich

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 28

Teil 4 Exemplarische Designfehler

15

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 29

Schlecht: Variable Menüeinträge

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 30

Schlecht: Doppelte Menüeintrage

Ausserdem schlecht: Keine Tastaturunterstützung

16

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 31

Schlecht: Handlungen implizit verlangen

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 32

Besser: Handlungen explizit vorgeben

17

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 33

Schlecht: Unintuitive Anordnung

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 34

Schlecht: Entscheidungen verlangen, ohne hinreichende Hinweise

18

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 35

Schlecht: Entscheidungen verlangen, ohne hinreichende Hinweise (2)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 36

Schlecht: Information geben, aber keine Wahl lassen

19

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 37

Schlecht: Dialoge mit Nullaussage

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 38

Schlecht: Künstlich Stress erzeugen

20

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 39

Noch schlechter: Künstlich Stress erzeugen und die Zeit des Benutzers verschwenden (Endlosschleife)

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 40

Schlecht: GUI Elemente verkomplizieren

21

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 41

Schlecht: Aufgaben an Benutzer verteilen

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 42

Noch schlechter: Unerfüllbare Aufgaben verteilen

22

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 43

Schlecht: Komplizierte Formulierungen

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 44

Schlecht: Geek Speak

23

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 45

Schlecht: Benutzer mit Komplexität erschlagen

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 46

Schlecht: Programm nicht wirklich ansprechbar

24

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 47

Schlecht: Kreativität an der falschen Stelle

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 48

Schlecht: Die wichtigsten Features der GUI nicht zu kennen

25

Anwendungssysteme SS03 Gerald Friedland, fland@inf.fu-berlin.de 49

Literatur

- Jeff Johnson, „GUI Bloopers“, Morgan Kaufmann, 2000.

- Jakob Nielsen, „Designing Web Usability“, New Riders, 2000.

- Jakob Nielsen, „Usability Engineering“, Academic Press, San Diego, 1993.

- Alan Dix, Janet Finlay, Gregory Abowd, „Human Computer Interaction“, Prentince Hall, 1998.

- Jeff Raskin, „The Humane Interface“, Addison-Wesley 2000.

- Donald R. Norman, „The Design of Everyday Things“, Currency/Doubleday, 1990.