Modul: Einführung in die Praktische Informatik Grundlagen der Programmierung (GPR) VG10 Bedeutung und Rolle der GUIs

(1)

Modul: Einführung in die Praktische Informatik Grundlagen der Programmierung (GPR)

VG10 Bedeutung und Rolle der GUIs

Prof. Dr. Franziska Matthäus / Prof. Dr. Matthias Kaschube / Dr. Karsten Tolle Institut für Informatik

Fachbereich Informatik und Mathematik (12)

(2)

Prof. Dr. Franziska Matthäus Prof. Dr. Matthias Kaschube Dr. Karsten Tolle

Folie 2

EPI - Organisatorisches

Ziele dieser Vorlesung

‣ Bedeutung GUI und Historische Entwicklung

‣ Unterscheidung

‣ Command-Line-Interface (CLI/TUI) und

‣ GUI (Graphisches User Interface) kennen!

‣ Entwicklung von Benutzungsschnittstellen unterscheiden: TUIs vs. GUIs

‣ Begriffe wie Software-Ergonomie, Usability, User-Experience kennen und einordnen.

‣ Ein weiteres SW-Entwurfs-Pattern, nämlich „Model-Control-View“

kennenlernen.

(3)

Folie 3

Vorab

‣ Benutzungsschnittstelle oder User Interface UI

‣ Benutzungsoberfläche

‣ Mensch-Maschine Schnittstelle Human Machine Interface (HMI) Human Computer Interface (HCI)

‣ nicht „Benutzeroberfläche“ oder „Benutzerschnittstelle“!

Ja, ich weiß: Wir sagen auch „Handcreme“: „Creme für die Hand“

‣ Aber es wird vielfach „unsauber“ als Übersetzung von „user interface“ benutzt.

Benutzungsschnittstelle wird in der Fach-Community bevorzugt.

‣ Nach DIN EN ISO 9241-110 ist der Begriff der Benutzungsschnittstelle definiert als „alle Bestandteile eines interaktiven Systems (Software oder Hardware), die Informationen und Steuerelemente zur Verfügung stellen, die für den Benutzer notwendig sind, um eine

bestimmte Arbeitsaufgabe mit dem interaktiven System zu erledigen.“

(4)

Folie 4

Bedeutung und Kosten von

"guten" User Interfaces (Benutzungsschnittstellen)

‣ Marktvorteile für Unternehmen.

‣ Beispiele: Google, Amazon, Microsoft haben das längst erkannt

‣ Benutzungsschnittstelle oft entscheidend für den Kauf eines Systems.

‣ Benutzungsschnittstelle hat zentralen Einfluss auf die Zufriedenheit der Nutzer.

‣ Eine gute Benutzungsschnittstelle kann Arbeitsprozesse verkürzen und damit zu Einsparungen beitragen.

‣ Mittlerer Anteil des Sourcecodes für die Benutzungsschnittstelle am Gesamtsystem: 48%.

(5)

Folie 5

Stimmt das? … (fast) 50% des Gesamtaufwandes?

‣ Myers und Rosson stellten 1992 eine Studie vor, nach der

‣ 48% des Sourcecode,

‣ 45% der Entwicklungszeit,

‣ 50% der Implementationszeit und

‣ 37% des Wartungsaufwands

für die Benutzungsschnittstelle aufgewendet werden. [Myers & Rosson 1992]

‣ Siedersleben schätzt für die Realisierung der Bedienoberfläche den Anteil

am Gesamtaufwand bei interaktiven Systemen auf häufig 60%, manchmal sogar 80%.

[Siedersleben 2004]

‣ Petrasch schätzt diesen Anteil –bedingt durch steigende Anforderungen und die wachsende Zahl heterogener Ein- und Ausgabegeräte – auf mindestens 50% der Gesamtentwicklungszeit [Petrasch 2007].

(6)

Folie 6

Quellen dazu:

‣ Myers, Brad A. & Rosson, Mary B.: Survey On User Interface Programming: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. New York: ACM.

(CHI ’92), 195–202; 1992.

‣ Siedersleben, Johannes Moderne Software-Architektur: Umsichtig planen, robust bauen mit Qua-sar: Dpunkt; 2004.

‣ Petrasch, Roland: Model Based User Interface Design: Model Driven Architecture und HCI Patterns. Softwaretechnik-Trends 27(3), 5–10; 2007.

(7)

Folie 7

Inhalt

‣ Die historische Entwicklung der User Interfaces

‣ Eigenschaften von Command Line Interfaces: CLIs

‣ Entwicklung von Command Line Interfaces

‣ Eigenschaften von GUIs

‣ Wie entwickele ich ein „gutes“ GUI?: Software-Ergonomie – Usability – User Experience

‣ Zwischenspiel: Eine Hierarchie von Normen, Empfehlungen, Styleguides, …

‣ Pattern und Toolkits

‣ Zusammenfassung

(8)

Folie 8

Übersicht zur HCI (Human Computer Interaction) Entwicklung -- Paradigmenwechsel

Operator bedient Maschine

Batch Command Line Interface Interface

TextUI -- CLII

User benutzt

Tool

Graphical User Interface

Manager delegiert an

Assistenten Attentive User Interface

GUI -- WIMPI

60er / 70er / 80er 80er/90er

ZUI (?) …TangibleUI(?)

ab 2000

(9)

Folie 9

Vergleich CLIs (T

^ext

UIs) und G

^raphical

UIs Charakteristika

1. Lese die Eingabe input() 2. Verarbeitung

3. Ausgabe print(), ggf. mit .format() 4. Gehe zu Schritt 1.

EVA-Prinzip [input(), print()]

1. Pop-up des Fensters.

2. Warte auf ein 'User Event'.

3. Bearbeite das 'User Event'.

4. Gehe zu Schritt 2.

Machen wir mit dem Modul tkinter Event-based Programming

(10)

Folie 10

GUIs – Das WIMP-Paradigma

‣ Immer noch grundlegendes und

aktuelles Paradigma zur Gestaltung der Mensch-Maschine-Interaktion (MMI)

‣ WIMP (Windows, Icons, Menues, Pointer)

‣ Werkzeugmetapher (Tool)

‣ Direct Manipulation

‣ State-of-the-Art zumindest bei Desktop-Rechnern und Laptops; ein wenig angepasst bei Touch-Interfaces (Smart Phones + Tablets, Smart Watches).

(11)

Folie 11

Attentive User Interface … Die Zukunft?

‣ Erste größere Änderungen seit 1980 (ab 2005) erst mit der weiten Verbreitung der Touch- Interfaces (Smartphones, Tabletts) hin zu ZUIs (Zoomable User Interface, Responsive Design, adaptive UI - skalierbare Benutzungsoberfläche).

‣ Andere Technologien:

‣ BCI (Brain Computer Interface),

‣ NUI „Natürliche Benutzungsschnittstellen (Natural User Interface),

‣ VUI Sprachbasierte Benutzungsschnittstellen (Voice User Interfaces),

‣ PUI Perceptual User Interface,

‣ TUI Gegenständliche Benutzungsschnittstellen (Tangible User Interface) (Achtung:

gleiches Abkürzung wie T^extUIs)

‣ … aber alle Ansätze sind in der Forschungsphase, … keine stabile Situation …

(12)

Folie 12

Inhalt

‣ Wie entwickele ich ein „gutes“ GUI: Software-Ergonomie – Usability – User Experience

‣ Pattern, Frameworks

‣ UI-Toolkits und Bibliotheken

‣ Zusammenfassung

(13)

Folie 13

TUI – T

^ext

UIs, speziell: CLI Command Line Interface

(auch Command Language Interface, Kommandozeile)

‣ Befehle werden als Text mit der Tastatur eingegeben

‣ Systemantwort als Text auf dem Bildschirm

‣ Historisch die erste (echte, ursprüngliche) Form der Interaktion Mensch-Maschine

(vorher überhaupt keine eigentliche Interaktion, z.B.

Lochkarten, Drucker)

‣ Beispiele

‣ UNIX Shell, MS-DOS Shell

‣ Datenbankabfragen, z.B. SQL

Programmiersprachen, Skriptsprachen

‣ Interpreter-Fenster: z.B. für Python: print() und input()…

(14)

Folie 14

Eingabeaufforderung (command prompt) ab ca. 1985

‣ ab 1985 Einführung der fensterorientierten Oberflächen

‣ ermöglichen es, mehrere virtuelle Terminals zu öffnen.

‣ werden als Eingabeaufforderung, command prompt oder shell bezeichnet

‣ jede Eingabeaufforderung ist eigenständiges virtuelles Terminal

‣ kann gut zur Netzwerk-Verbindung zwischen Rechnern verwendet werden

‣ heute meist über TCP/IP

‣ Telnet: Terminal Emulator über TCP/IP

(15)

Folie 15

Vorteile der CLI Schnittstellen - Mächtigkeit

‣ Kommandosprachen haben (potentiell) einen großen Umfang von Befehlen (100+)

‣ der Wortschatz kann auf die Anforderung zugeschnitten werden, Beispiele dir, rm,...

‣ meist einfache Syntax

‣ verbraucht wenig Ressourcen z.B. Befehl "-" Optionen Argument

‣ ggf. einfach zu memorieren (trotzdem noch schwer genug)

‣ Erweiterbar: häufig benötigte Befehlssequenzen können abgespeichert und wieder abgerufen werden; Makros

z.B. BAT-Dateien

(16)

Folie 16

Weitere Vorteile des CLI

‣ Flexibilität

‣ Benutzer kann „jederzeit“ einen beliebigen Befehl eingeben

‣ Keine Reihenfolge der Befehle vorgegeben

‣ Schnell und effizient – "effizienteste" Benutzungsschnittstelle Voraussetzung dafür:

‣ geübter Benutzer mit guten Schreibmaschinenkenntnissen und

‣ CLI ist gut entworfen

‣ Schonender Umgang mit Bildschirmplatz

‣ (meist) nur eine Zeile für Eingabe (unbedingt) benötigt

‣ Rest für Ausgabe

‣ Geringer Bandbreitenbedarf, "nur Text"

(17)

Folie 17

Nachteile der CL Interfaces (1)

‣ Schwierige Erlernbarkeit

Befehle müssen auswendig gelernt werden

‣ ebenfalls Parameter und Optionen der Befehle

‣ Effizienz durch kurze (aber meist kryptische) Befehle

‣ Schnelles Vergessen garantiert

‣ Bei Nichtgebrauch gehen Befehlssyntax schnell wieder vergessen

 nicht geeignet für gelegentliche Benutzung

‣ Schreibmaschinen-Fertigkeit

nur wenn diese hoch, dann effizienteste Benutzungsschnittstelle

‣ Fehleranfällig: Tippfehler sind schnell geschehen

(18)

Folie 18

Nachteile der CL Interfaces (2)

‣ Kommandos müssen z.T. in bestimmten Reihenfolgen eingegeben werden.

‣ Schwierig, Fehler zu korrigieren oder andere Lösungsstrategien umzusetzen.

‣ Ggf. müssen längere Eingabesequenzen wiederholt werden, um eine Kleinigkeit zu ändern.

‣ Sind auf Text-Ein-/Ausgabe beschränkt.

‣ In der "realen Welt" werden CLIs von GUIs komplett dominiert …

(19)

Folie 19

Video Terminal-Nutzung …

(20)

Folie 20

Inhalt

‣ Wie entwickele ich ein „gutes“ GUI: Software-Ergonomie – Usability – User Experience

‣ Pattern, Frameworks

‣ UI-Toolkits und Bibliotheken

‣ Zusammenfassung

(21)

Folie 21

Wie entwirft man eine

Kommandosprachen-Struktur?

Beschreibung der geforderten Funktionalität durch Analyse des Anwendungsgebietes 1. Auflisten aller User Tasks

Bei großen Anzahlen eine Spalte mit der erwarteten Häufigkeit der Nutzung anlegen:

Häufigste Aufgaben sollten am einfachsten zu merken und auszuführen sein.

2. Auflistung aller Interface-Objekte

Unterstützende Technik

‣ Zustandsdiagramme (rechts) z.B. der UML

Quelle: https://www.edrawsoft.com/template-phone-uml-statechart.php

(22)

Folie 22

Weitere Schritte:

‣ Abstrahieren der Liste in Interface Actions und Interface Objekte.

‣ Entwicklung und Beschreibung der Low-level Interface Syntax.

‣ Spezielle Evaluierung destruktiver Aktionen (z.B. Löschen eines Objektes).

Bereitstellung von Undo-Mechanismen (teilweise sehr aufwendig).

‣ Identifizieren von Fehlersituationen und Formulierung adäquater Fehlermeldungen.

‣ Einführung zusätzlicher Shortcuts für Experten, z.B. über Makros oder Mechanismen zur Anpassung von Systemparametern.

(23)

Folie 23

Strukturierung von Kommandos

(Wenn die Nutzerbasis deutschsprechend ist, dürfen Kommandos natürlich in Deutsch sein!) 1. Einfache Kommandos (Befehle ohne Argumente)

‣ Beispiele: look, go, move, … end

2. Befehle mit Argumenten und Optionen – drei übliche Möglichkeiten

‣ Befehl mit Argumenten

‣ copy source dest

‣ Befehle mit Keyword Labels

‣ copy From=source To=dest

‣ Befehle mit Optionen

‣ PRINT/3,HQ FILEA

‣ PRINT FILEA -3, HQ

3. Hierarchische Kommandostrukturen (führt hier zu weit  HCI)

(24)

Folie 24

Vergleiche Kongruenz und Hierarchien

(nach J.M. Carroll 1982): Beispiel: Steuerung eines Roboterarms

‣ Kongruente (Begriffs-)Paare und hierarchische Formen sind vorteilhaft.

(Kongruenz: Benutzung bedeutungsvoller Begriffspaare, z.B. Open/Close – links/rechts – oben/unten)

(25)

Folie 25

Benamungen und Abkürzungen

‣ Beispiel: UNIX (leider kein gutes Beispiel!)

‣ mkdir (make directory)

‣ ls (list directory)

‣ cd (change directory)

‣ rm (remove file)

‣ pwd (print working directory)

‣ Problem mit diesen Abkürzungen

‣ Keine feste Regel, die festlegt, wie man von einem Befehl auf die Abkürzung kommt

‣ Fehlen von Standards

‣ darum …

(26)

Folie 26

Strategien (Regeln) für Abkürzungen

‣ Einfaches Abschneiden

Verwendung des 1. + 2. (+ 3. … ) Zeichens des Kommandos Problem: Kommandos müssen unterscheidbar sein

‣ Vowel Drop – Weglassen von Vokalen

‣ Erster und letzter Buchstabe

Verwendung des ersten und letzten Buchstaben des Kommandos, da diese besonders deutlich wahrgenommen werden.

‣ Erster Buchstabe eines jeden Worts einer Phrase

‣ Beispiel: lf für List Full

‣ Typischerweise verwendbar mit hierarchischem Konzept

‣ Standard-Abkürzungen verwenden

‣ Phonics

‣ Beispiel: XQT für execute

‣ Problem: eher im amerikanischen Sprachraum üblich

(27)

Folie 27

Richtlinien für Abkürzungen

(nach Ehrenreich und Porcu, 1982)

‣ Verwende maximal 2 verschiedene Regeln zur Abkürzung

‣ Einfache Hauptregel (siehe letzte Folie)

‣ Abweichende Zweitregel im Fall von Konflikten (bei Anwendung der Hauptregel)

‣ Anwendungen der Zweitregel sollte durch Marker (z.B. *) dargestellt werden

‣ Zweitregel sollte so wenig wie möglich verwendet werden

‣ Anwender müssen die Regeln kennen

‣ Einheitliche Länge der Kommandos ist zu bevorzugen

‣ Abkürzungen sollten immer angeboten werden. Ausnahme: zu viele ähnliche Aktionen

Aber: Vom Computer generierte Messages sollten keine Abkürzungen verwenden, wenn es nicht ein Platzproblem bei der Darstellung gibt

Abbreviations: Improving Operator Performance on Battlefield Automated Systems SL Ehrenreich, TA Porcu-1982- apps.dtic.mil

https://apps.dtic.mil/sti/pdfs/ADA134111.pdf

(28)

Folie 28

Zusammenfassung Command Line Interfaces

‣ Ganz schön viel Entwurfsarbeit, bevor man das erste input() – print() Paar schreiben kann.

‣ Diese Arbeit müssen Sie auch dokumentieren 

‣ In der Analyse.

‣ Im Source Code.

‣ (Benutzer-)Handbuch oder Benutzungshandbuch.

(29)

Folie 29

Inhalt

‣ Zusammenfassung

(30)

Folie 30

GUIs sind meist WIMP-Interfaces Zentrale Eigenschaften (1)

‣ Windows (Fenster):

‣ abgegrenzter Bereich auf dem Bildschirm.

‣ überlappend oder nebeneinander.

‣ In der Computergrafik meist (etwas genauer) Viewport genannt.

‣ Window ist das abstrakte Fenster, das Programme nutzen um ihre Ausgaben als Text, Grafik oder Steuerelemente: Buttons, Slider, etc.

darzustellen.

‣ Icons (Ikonen, Symbole, kompakte Bilder, Graphisches Zeichen, Grapheme):

‣ Zeichen repräsentieren entweder eine Funktion oder ein Objekt, z.B. ein Schere um etwas auszuschneiden oder

einen Mülleimer um etwas zu löschen.

‣ Sie sollen schneller 'aufnehmbar'/erfassbar sein als Text. Beispiele sind u.a. Warnsymbole, Werkzeugicons, Navigationspfeile.

IDLE Debugger PyCharm

(31)

Folie 31

Zentrale Eigenschaften der WIMP-Interfaces (2)

‣ Menues (Menüs):

‣ Meist ausklappbare Auswahlliste von (aktuell verfügbaren) Kommandos, zwischen denen der Nutzer auswählen kann.

‣ Oft in Form von Text (manchmal als Icon).

‣ Häufig Kontextabhängig, d.h. zeigt nur die Kommandos, die aktuell möglich sind.

‣ Pull-Down-Menüs klappen vom Fensterrand nur nach unten (down) auf.

‣ Das Pull-Up-Menüs (am unteren Fensterrand) und

‣ Pop-Up-Menüs (an beliebigen Stellen auf dem Window).

(32)

Folie 32

Zentrale Eigenschaften der WIMP-Interfaces (3)

‣ Pointer (Zeigegerät, z.B. Mouse (Maus)).

‣ Ein Symbol (Cursor), das die Position der Maus auf dem Bildschirm repräsentiert und sich (mit-)bewegt, wenn sich auch die Maus bewegt.

‣ Kann man durch (Mouse-)Click bedienen, z.B. Fensterflächen zu verschieben, Icons zu markieren, Menüpunkt auszuwählen, Buttons zu drücken, Schiebebalken zu verschieben.

‣ Je nach Anwendungskontext wird der Mauszeiger mit einem geeigneten Symbol markiert (Pfeil, Einfügemarke, Greifhand, Zeigefingerhand, Warteschleife usw.).

(33)

Folie 33

Geschichte des WIMP-Interfaces

‣ Zur Geschichte des WIMP-Interfaces sehen Sie z.B.

https://web.archive.org/web/20150222035606/http://mark13.org/utf8/wimp (Ganz nett gemacht und fokussiert – bis 1990!)

‣ Ein erster Meilenstein der WIMP-Geschichte ist das am Stanford

Research Institute unter der Leitung von Douglas Engelbart entwickelte NLS (oN-Line System), welches 1968 öffentlich präsentiert wurde.

‣ Einige NLS-Entwickler wechselten Anfang der 1970er Jahre ans Xerox PARC, um das WIMP-gestützte Smalltalk (Programmiersprache) zu realisieren, welches wiederum für Apples Mac OS Pate stand.

‣ Die Computersysteme veränderten sich vor allem in den 1980er Jahren dramatisch: PCs, Workstations, etc.

(34)

Folie 34

Inhalt

‣ Zusammenfassung

(35)

Folie 35

Wie entwickele ich ein „gutes“ GUI?

Was ist das überhaupt: ein „gutes“ GUI?

‣ Wenn ich Ihnen das in wenigen Sätzen sagen könnte … Andere studieren dafür ein ganzes Studium lang.

‣ Schlüsselbegriffe: (Software-)Ergonomie, HCI (Human Computer

Interaction), MMI (Man Maschine Interface), Interaktionsdesign, Usability (Gebrauchstauglichkeit)(-Engineering), User Experience (UX).

‣ Ja, auch Begriffe unterliegen Moden! …

‣ Weitgehend einig ist man sich darüber, dass dies ein wirklich interdisziplinäres Feld ist: Informatik, Psychologie (vor allem der Medienpsychologie), Arbeitswissenschaft, Kognitionswissenschaft,

Ergonomie, Soziologie und (Kommunikations-)Design und das jeweilige Anwendungsgebiet: Maschinenbau, Prozessleittechnik, Büromaschinen, ….

‣ Entsprechend viele „Flavors“ gibt es!

(36)

Folie 36

Die historische Entwicklung

‣ Bis ca. 1980 war dieses Feld fast unbedeutend: Für die wenigen Rechner gab es geschulte Bediener der Systeme: Operator und Programmierer.

‣ Erst mit dem Aufkommen der Arbeitsplatzsysteme und der PCs wuchs die Nachfrage nach „gut“ gestalteten Interfaces.

‣ Ab 1982 gibt es SIGCHI (Special Interest Group on Computer-Human

Interaction), eine Fachgruppe der US Gesellschaft Association for Computing Machinery (ACM). Ab 1982 regelmäßig große (3000 Teilnehmer*innen)

Konferenzen (erst zweijährig – jetzt jährig). Siehe:

https://sigchi.org/conferences/conference-history/CHI/ .

‣ Ab 1983 gab es in der „Gesellschaft für Informatik“(GI) einen Fachaus- schuss 2.3 „Software-Ergonomie“. Wegen der Ausweitung und Bedeutung wurde daraus ab 2001 der GI-Fachbereich „Mensch-Computer-Interaktion“.

(37)

Folie 37

(Software-)Ergonomie

Der Begriff Ergonomie hat eine lange Tradition: [abgeleitet von ergon: Arbeit, Werk und nomos: Regel, Gesetz]

‣ „Ergonomie ist ein wissenschaftlicher Ansatz, damit wir aus diesem Leben die besten Früchte bei der geringsten Anstrengung mit der höchsten

Befriedigung für das eigene und für das allgemeine Wohl ziehen.“

[Jastrzebowski, 1857; nach Rudlof, 2006]

‣ Das Ziel der Ergonomie ist die menschengerechte Arbeitsgestaltung:

Arbeitende Menschen sollen ihre Fähigkeiten und Fertigkeiten optimal einsetzen können.

‣ Ergonomie ist Teilgebiet der Arbeitswissenschaft (von F.W. Taylor);

bisher oft „angesiedelt“ im Maschinenbau oder Psychologie.

Nicht so wirklich unser Ding!

(38)

Folie 38

‣ Usability übersetzt man am besten mit Gebrauchstauglichkeit oder Benutzerfreundlichkeit.

‣ Usability bezeichnet das „Ausmaß, in dem ein System, ein Produkt oder eine Dienstleistung durch bestimmte Benutzer in einem bestimmten Nutzungskontext

genutzt werden kann, um festgelegte Ziele, effektiv, effizient und zufriedenstellend zu erreichen“

‣ Gute Usability wird in der Regel gar nicht explizit wahrgenommen, schlechte hingegen schon.

‣ Wichtig ist: Usability gibt es bei allen Produkten mit einer Schnittstelle zwischen Mensch und Technik bzw. zwischen Mensch und Maschine. (Software, Websites, mobile

Endgeräte, medizinische Geräte oder komplexe Anlagen zur Maschinensteuerung, Haushaltsgeräte, …).

Usability ab ca. 1995

(39)

Folie 39

User Experience (UX) ab ca. 2010

‣ User Experience erweitert den Begriff Usability um ästhetische und emotionale Faktoren wie eine ansprechende, „begehrenswerte”

Gestaltung, Aspekte der Vertrauensbildung oder Spaß bei der Nutzung (joy of use).

‣ Dieser „ganzheitliche Ansatz“ umfasst das gesamte Nutzungserlebnis, welches man bei der Verwendung eines Produktes erfährt.

‣ Die Nutzer sollen nicht nur schnell und reibungslos zum Ziel kommen (Usability), sondern auch positive Gefühle wie Spaß oder Freude bei der Benutzung erleben.

‣ Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Systems, eines Produkts oder einer Dienstleistung resultieren.

(40)

Folie 40

UX-Modelle

In Anlehnung an die Bedürfnispyramide von

Maslow (1970) formuliert Jordan eine Hierarchie von Benutzerbedürfnissen.

Wie bei Maslow können die Bedürfnisse der höheren Ebene erst erfüllt werden, wenn die Bedürfnisse der darunterliegenden Ebene erfüllt sind.

Nach den ISO-Normen:

Usabilitybetrachtet den reinen Prozess während der Nutzung.

User Experience (UX, 2011) geht auf die subjektiven Empfindungen des Nutzers ein.

Hierbei werden auch die Effekte vor

und nach der Nutzungberücksichtigt und fokussiert.

(41)

Folie 41

Zusammenfassung

‣ O.k. Sehr viel Stoff angesprochen!

• Klar: allein damit kann man sich ein ganzes Studium lang beschäftigen, siehe https://www.studis-online.de/Studiengaenge/Mensch-Computer-Interaktion/

(42)

Folie 42

Inhalt

‣ Zusammenfassung

(43)

Folie 43

Eine Hierarchie von Normen, Empfehlungen, …

1. Normen (werden ggf. in rechtsverbindliche Verordnungen/Gesetze referenziert).

2. Empfehlungen (z.B. im Anhang von Normen, aber nicht verbindlich)

≈ Heuristiken oder aus der Wissenschaft und Anwendung.

3. Hersteller-Styleguides (sind oft spezifischer, aber nicht allgemeingültig, wichtig für sogenannte native Apps).

4. Entwicklungsmethoden und Evaluationsmethoden für die Praxis

Die Entwicklungsmethoden müssen sich in die jeweilig genutzte Methode des Software-Engineerings einfügen.

Evaluationsmethoden kommen im Wesentlichen aus der Psychologie.

5. Architektur- oder Entwurfs-Pattern 6. GUI-Toolkits (ggf. Frameworks)

(44)

Folie 44

Für uns bedeutsame Normen im Bereich Usability und User Experience

Die Norm DIN EN ISO 9241 ist ein internationaler Standard. Die Normenreihe trägt seit 2006 den deutschen Titel Ergonomie der Mensch-System-Interaktion.

hat sehr viele Teile, anfangs 17, jetzt mehr als 30 gültige. Beispiele:

DIN EN ISO 9241-

11:2018 Gebrauchstauglichkeit: Begriffe und Konzepte 110:2020 Interaktionsprinzipien

112:2017 Grundsätze der Informationsdarstellung

125:2018 Empfehlungen zur visuellen Informationsdarstellung 126:2019 Empfehlungen zur auditiven Informationsdarstellung

210:2020 Menschzentrierte Gestaltung interaktiver Systeme … viele mehr

auch DIN ISO/IEC 25000 Software-Engineering – Qualitätskriterien und Bewertung von Softwareprodukten (SQuaRE)

(45)

Folie 45

Empfehlungen und Heuristiken

aus der Forschung und Anwendung

‣ Allgemeine UI-Richtlinien, Empfehlungen und Style-Guides (aus der Wissenschaft), z.B.

‣ Jakob Nielsen's 10 general principles for interaction design.

‣ 7 Usability Heuristics That All UI Designers Should Know

‣ Die 7 goldenen Regeln des UI-Designs

‣ Die 8 goldenen Regeln des Interface Design (von Ben Shneiderman) Shneiderman's Eight Golden Rules of Interface Design

‣ Dieser Art Empfehlungen und Heuristiken gibt es Hunderte: Aus berufenem Munde und auch sonst so (siehe Web).

(46)

Folie 46

Eine Hierarchie von Normen, Empfehlungen, … UI Hersteller-Styleguides (1)

‣ haben eine gewisse Bedeutung, wenn man sogenannte „native“

Interfaces entwickeln will

‣ sind oft wesentlich detaillierter und sehr spezifisch – sind nicht allgemein gültig.

‣ Repräsentieren das Look&Feel des jeweiligen Systems (Herstellers)

Apple

‣ OS X Human Interface Guidelines (aktuelle Online-Version) Design Prinzipien von Apples Betriebssystem (OS X)

‣ iOS Human Interface Guidelines Design Prinzipien von Apples Betriebssystem für mobile Geräte (iOS)

(47)

Folie 47

UI Hersteller-Styleguides (2)

Google

‣ Android Design Principles Übersicht und Beispiele der Design Prinzipien von Android

‣ App Widget Design GuidelinesAnleitung zum Erstellen von Andoid Widgets

‣ Design Guide für Android (Material Design) Styleguide für User Interface Design von mobilen Anwendungen auf Android.

‣ Usability / Accessibility Guides für Android (Material Design) Prinzipien, Farben und Kontraste, Layout...

IBM

‣ Object-Oriented Interface Design: IBM Common User Access Guidelines (1993, Buch)

"Die Mutter aller Styleguides". Diese Gestaltungsrichtlinie erschien 1992 für das IBM/OS2 Betriebssystem. Microsoft basierte anschließend das Windows-Betriebssystem auf den hier beschriebenen Regeln! Auf 352 Seiten sind umfassende Gestaltungsregeln zu finden, die ohne weiteres auf andere und aktuelle Betriebssysteme übertragbar sind und nach wie vor ihre Gültigkeit haben. Das Buch ist ein hervorragendes Nachschlagewerk für alle User Interface Designer.

(48)

Folie 48

UI Hersteller-Styleguides (3)

Microsoft

‣ Design und UI (Online-Version) Informationen zum Entwerfen einer „Universal Windows Plattform“ (UWP)-App-Benutzungsschnittstelle

‣ Microsoft Guidelines for Windows Desktop Applications (aktuelle Online-Version)

‣ Microsoft User experience guidelines for Universal Windows Platform (UWP) apps (PDF-Dokument)

‣ Touch design guidelines(Online-Version) Anleitung für Touch-Gesten für Windows Apps

SAP

‣ SAP Design Guild Resources (Webseite der SAP Design Guilde mit Links auf Guidelines)

SUN Microsystems / Oracle

‣ The Java™ Tutorials - Trail: Creating a GUI With JFC/Swing (Webseite des Swing Tutorials)

Solche Styleguides gibt es von jedem größeren Hersteller.

(49)

Folie 49

Die üblichen Schritte bei einer

Menschzentrierte Gestaltung interaktiver Systeme

Charakteristisch ist die zyklische Erarbeitung einer SW-Lösung: viele Prototypen, z.B.

Papierprototypen, Layout Skizzen auf Raster, etc.

‣ Nutzungskontext verstehen und beschreiben: Benutzergruppen-Profile, Szenarien, Personas (archetypische Nutzer, repräsentieren die Ziele und Bedürfnisse der

Zielgruppe).

‣ Nutzungsanforderungen spezifizieren: Erfordernisse ermitteln, ggf.

Gestaltungsrichtlinie festlegen, …

‣ Lösungen entwickeln: Low Fidelity Prototyp, High Fidelity Prototyp, UI-Software, …

‣ Evaluation: Usability Test, User Experience Test, Feldtest, Fragebogen, …

(50)

Folie 50

Inhalt

‣ Zusammenfassung

(51)

Folie 51

UI-Lösungen entwickeln

‣ Diverse Prototypen (auch an Papierprototypen denken, …)

… kann man z.B. auch mit Powerpoint machen, etc.

‣ Lösungen basieren entweder auf einem

‣ Architektur oder SW-Entwurfs-Pattern

‣ Framework (Rahmenstruktur) ist ein Programmiergerüst, das in der objektorientierten Softwareentwicklung ggf. eingesetzt wird.

‣ Ein Framework gibt somit die Architektur vor.

‣ Dabei findet eine Umkehrung der Steuerung (Inversion of Control) statt: Der Programmierer registriert konkrete

Implementierungen, die dann durch das Framework gesteuert und benutzt werden, statt – wie bei einer Klassenbibliothek – Klassen und Funktionen zu benutzen.

‣ UI Builder / UI-Bibliothek

(52)

Folie 52

Erstellen einer interaktiven GUI-Anwendung

Beobachtungen:

‣ Änderungen oder Erweiterungen an der Benutzungsschnittstelle ist häufiger als an der Geschäftslogik.

‣ Mix des Codes für die Geschäftslogik und die Präsentation erschwert die Portierung.

‣ Möglichst hohe und einfache Portabilität (auf diversen Endgeräten).

Anforderungen:

‣ Änderung der Benutzungsschnittstelle soll den Code für die Geschäftslogik nicht beeinflussen.

‣ Strikte Trennung der Datenschicht (-haltung) /Geschäftslogik von der Präsentation derselben.

(53)

Folie 53

Ein ganz wichtiges Architektur- und SW-Entwurfsmuster:

Model – View – Controller (MVC)

‣ Das MVC Design Pattern ist eines der gebräuchlichsten Muster zur Strukturierung von Software (also ein Architekturmuster):

Bisher kennen wir ja nur EVA.

‣ Es ermöglicht eine klare Trennung von model (Datenhaltung) und der Präsentationsschicht (views und controllers)

‣ Schon 1979, zunächst für Benutzungsoberflächen in Smalltalk durch Trygve Reenskaug beschrieben (als sog. Seeheim-Modell erst 1983 diskutiert und erst 1988 formal erklärt).

‣ Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme (und darum sollten Sie das auch kennen und verstehen).

‣ Es gibt heute diverse Varianten … und (leider) viele Missverständnisse.

(54)

Folie 54

model - view - controller

view controller

model

command query

user

Wir denken uns die Komponenten model, viewund controller als Klassen oder Module implementiert Eine vollständige Aufruf-Vernetzung der Komponenten wäre unsinnig:

Viel zu komplex und nicht klar:

„Wer importiert wen?“

Verbindungen eher minimieren.

Je weniger man über andere Module / Klassen wissen muss, umso besser.

Je besser kann man auch die Arbeit auf mehrere Programmierer*innen verteilen.

möglichst viele Verbindungen streichen.

(55)

Folie 55

Die Original-Idee

model

command query

user

Wir denken uns die Komponenten model, viewund controller als

Klassen oder Module implementiert.

view ist ein widget (UI-Objekt) auf dem Bildschirm. Es kann nur sich selbst zeichnen.

controllerbehandelt die Benutzer Interaktionen, z.B. Tastatur- oder Mouse-Events (für einen einzelnen view).

model ist die Daten-Komponente, realisiert die Business-Logik und managed die Datenquellen

(Files, Datenbanken).

(56)

Folie 56

Passive Model MVC

model

command query

user

Wir denken uns die Komponenten model, viewund controller als

Problem: wenn query und command Funktions- oder

Methodenaufrufe sind: Woher weiß view, wann es eine query und dann update ausführen soll.

1. Lösungsansatz Passive Model MVC:

der controller initiiert Veränderungen des models (commands) und ist verantwortlich, den view über eine Zustandsänderung zu informieren.

view kann dann das model abfragen (query) und updaten.

notify notify

(57)

Folie 57

Active Model MVC (Classic MVC)

model

command query

user

Wir denken uns die Komponenten model, view und controller als

2. Lösungsansatz Active Model MVC:

controller empfängtEingaben vom user, sendet entsprechende

Commands zum model.

Dies führt die Business Logik aus und ändert ggf. den Zustand.

model generiert ein notify-event (z. B. eine Exception) um das view zu veranlassen, ein update

auszuführen.

notify

(58)

Folie 58

Active Model MVC (Variante mit UI-Widget)

model

command query

user

Wir denken uns die Komponenten model, view und controller als

2. Lösungsansatz Active Model MVC:

Es gibt keine Kommunikation zwischenview und controller.

Diese Variante mit sogenannten Widgets aus UI-Bibliotheken

durchbricht die strenge Aufteilung in drei Teile.

Aber, die strenge Trennung zum model bleibt erhalten.

Wir rechnen es trotzdem zum MVC Pattern-

notify

UI Widget

<view, controller>

(59)

Folie 59

Die konstituierenden Teile:

model - view

Das Modell (model) = die eigentliche Logik des Programms

‣ enthält die Arbeitsdaten eines Programms, Zustandsinformation, aus Datenbanken/Dateien gelesene Daten, etc.,

‣ In manchen Anwendungen enthält es die Geschäftslogik.

‣ Es enthält niemals Referenzen auf die beiden anderen Teile  die Programmierer*in muss das nicht kennen!

Die Präsentation (view):

‣ Die (bei einem Desktop-Programm z.B. graphische) Darstellung von Daten, die Programmoberfläche (GUI), etc.

‣ Sie enthält im Quelltext weder Daten, noch Teile der Geschäfts- oder Programmlogik vor, sondern ist lediglich für deren Darstellung verantwortlich.

‣ Hierzu definiert sie entsprechende Schnittstellen.

(60)

Folie 60

Die konstituierenden Teile:

controller

Die Steuerung (controller) = „Vermittler“

‣ Die vermittelnde Schicht, die für die Interaktion zwischen Präsentationsschicht und dem Modell (Daten) zuständig ist.

‣ Implementiert das Verhalten des Patterns auf Benutzereingaben.

‣ Sie wird oft mittels eines sogenannten Observer-Patterns realisiert, das die Daten des Modells beobachtet und diese ggf. mit der Präsentationsschicht wechselseitig aktualisiert.

‣ Die Steuerung muss somit sowohl zu den Daten, als auch zu Teilen der Darstellungsschicht Zugang haben.

‣ Es kann nur ein Modell, aber u.U. mehrere Views (z.B. als Tabelle, als Balkendiagramm, als Tortendiagramm) und mehrere Controller geben.

(61)

Folie 61

Web Anwendung

(62)

Folie 62

Zusammenfassung

Entwurfsmuster (Pattern) in der GUI-Entwicklung

‣ Als defacto Standard zur Strukturierung von Software (als Architektur-muster) haben wir das MVC (model-view-controller) kennengelernt.

‣ Implementiert werden model, view und controller als Module oder Klassen. Die

Minimierung der Abhängigkeiten untereinander erlaubt es, die Software so aufzuteilen, dass mehrere Entwickler*innen daran arbeiten können.

‣ Die views realisieren die Ausgabe zum Benutzer, die controller die Eingabe von der Tastatur, Mouse, etc.

‣ MVC ermöglicht eine klare Trennung von model (Datenhaltung) und der Präsentationsschicht (views und controllers).

‣ Wenn aktuelle GUI-Toolkits (Bibliotheken) genutzt werden, fallen controllers und views in eine Komponente: MVC bleibt aber erhalten.

(63)

Folie 63

Entwicklung von GUIs

Hierzu benutz man sogenannte "GUI-Toolkits" oder GUI-Bibliotheken oder widget toolkit, Man benötigt zwei Anbindungen:

‣ Zum Betriebssystem (Unix, Windows, Mac-OS) und zur

‣ Programmiersprache

Es gibt hunderte solcher Bibliotheken oder Frameworks. Siehe

https://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken. Manche erlauben ein sogenanntes Visual Programming.

Wir benutzen

‣ Tk als Python Bibliothek tkinter. Zentraler Begriff hier: Widget

(64)

Folie 64

Der Begriff Widget (1)

Bedeutungen im modernen Englisch:

1. Kleines mechanisches Gerät oder Geräteteil, dessen Namen unbekannt ist.

2. Ein massenproduziertes Objekt einer Fabrik.

3. Softwareentwicklung: Komponente einer grafischen Benutzungsoberfläche.

4. Vorrichtung in Bierdosen, wodurch das Bier beim Ausschenken schäumt.

für uns.

‣ In der Informatik wahrscheinlich ursprünglich aus dem Projekt Athena (MIT), und bezeichneten ein mit einem Fenster assoziiertes Objekt, daraus resultiert das Silbenkurzwort aus Wi(ndow) und (Ga)dget.

(65)

Folie 65

Widget (2)

Ein Steuerelement (graphical control element oder auch widget) ist ein Interaktionselement in einer grafischen Benutzungsoberfläche (GUI), beispielsweise eine Schaltfläche oder eine Bildlaufleiste.

Jedes widget hat verschiedene Eigenschaften (Attribute), wie Größe, Position auf dem Bildschirm, usw.

Python tkinter Dokumentation:

(66)

Folie 66

Zusammenfassung

‣ Wir müssen uns die Tk-Bibliothek etwas genauer anschauen … und das machen wir in EPR.

‣ Es ist aber vollkommen klar, das man die Entwicklung und Evaluation von UIs nicht im vorrübergehen lernen kann. Wir haben nur einen (zu) kleinen Einblick erhalten.

‣ Aufgrund der riesigen Freiheitsgrade in der UI-Entwicklung, ist die Entwicklung eines GUIs tatsächlich sehr aufwendig  50 % + des Gesamtaufwandes in einem typischen Anwendungsprojektes.

‣ Aber: Die Benutzungsschnittstelle ist das „Gesicht“ der Software und sie entscheidet oft über Erfolg oder Misserfolg.

(67)

Folie 67

Fragen und (hoffentlich) Antworten

‣ Schreiben Sie diese einfach ins Forum!