User Experience Teil II - UX Kriterien - Jürgen Beckmerhagen Juni 2009

User Experience
                         Teil II - UX Kriterien
                                  Jürgen Beckmerhagen
                            juergen.beckmerhagen@gmail.com

                                       Juni 2009

                           http://web.me.com/beckmerhagen/UX

Dienstag, 9. Juni 2009                                         1

Überblick

                         • Rückblick und Einleitung
                         • Formen und ihre Geschichte
                         • Kriterien
                         • Ausblick

Dienstag, 9. Juni 2009                                  2

Dienstag, 9. Juni 2009                                                                                                   3

Im ersten Seminar hatten wir aus der Nutzer-Perspektive einen Blick auf die Benutzungs-Schnittstellen von Anwendungen
und ihren Interaktionsmodellen geworfen. Mit Hilfe einer Zeitachse, die sich vom ersten Eindruck über die Installation und
die allererste Benutzung bis hin zur geübten Anwendung und der De-Installation erstreckte, haben wir über die Wirkung
von Branding - also Farben und Formen -, Interne und Externe Konsistenz z. B. bei Menüs, Keyboard-Shortcuts, das
Layout, über Wizards, über Fehlermeldungen und vieles mehr gesprochen.

Edward Tufte

                                                                                  Jacob Nielsen

                         Douglas Engelbart
Dienstag, 9. Juni 2009                                                                                                         4

Heute wollen wir uns mit dem User Experience Designer beschäftigen - also mit jemandem, der weder Software-Entwickler

noch Software-Anwender ist. Dabei möchte ich Sie nicht zum User Experience Designer machen - denn selber bin ich

auch nicht der UX Experte - sondern ich möchte Sie mit der Sichtweise des UX Designers vertraut machen, wohl in der

Hoffnung, dass sie daraus neue Einsichten für ihre künftige Tätigkeit als Software-Architekt gewinnen, wie auch in der

Hoffnung, dass ich in Ihnen das Interesse an der Zusammenarbeit mit UX Designern wecke.

User Experience Designer bringen eine neue Qualität mit einer ganz eigenen Perspektive in die Software-Entwicklung. UX

Designer konzentrieren sich überwiegend auf die subjektive Wahrnehmung, also auf Aspekte wie Sinnes-Empfindungen,

Erlebnis-Welten und Zusammenhänge.

Einige Namen von einflussreichen Personen auf dem Gebiet der User Experience will ich kurz erwähnen:

- Douglas Engelbart (*1925) entwickelte 1963 die erste Computer-Maus und präsentierte diese zusammen mit einer

graphischen Benutzeroberfläche 1968 erstmals der Öffentlichkeit. Bei YouTube finden Sie die spektakulären Filme von

dieser Präsentation.

- Edward Tufte (*1942) hat hervorragendes auf dem Gebiet des Graphik-Designs geleistet. Wenn man seine Bücher liest,

mag man meinen, dass er Computer für die Informationsverarbeitung ablehnt, aber ich denke, dass z. B. seine Feststellung

hierzu, „dass nicht alles sinnvoll ist, was machbar ist“, zutreffend ist. Genießen Sie die Bücher von Tufte - besonders „The

Visual Display of Quantitative Information“ und lernen Sie u. a., warum weniger mehr ist.

- Jacob Nielsen (*1957) ist Däne und hat sich als Consultant für User Experience Design einen hervorragenden Namen in

der Branche gemacht. Er schlägt eigentlich in die gleiche Kerbe, wie Edward Tufte, macht dabei aber wesentlich

• Command Line Interface (CLI)
                         • Forms and Menus (F&M)
                         • Direct Manipulation (DM)

Dienstag, 9. Juni 2009                                                                                                      5

Bevor wir auf den User Experience Designer eingehen, will ich mit Ihnen eine kleine Bestandsaufnahme der verschiedenen

User Interface Formen und einen Blick in ihre jeweilige Geschichte, sofern ich sie selber seit Anfang der 70er Jahre

begleiten durfte, wagen. Oft versteht man die Form erst, wenn man sich mit ihrer Geschichte befasst hat. Gleichzeitig sollten

Sie aber bedenken, dass es sich bei der Geschichte und den Zusammenhängen ebenfalls nur um meine Beobachtungen und

um meine Interpretationen handelt. UX und Computer Science Experten mögen mit mir in vielem nicht übereinstimmen.

User Interfaces teilen wir in drei Kategorien ein:

•Command Line Interfaces (CLI),

•Formulare und Menüs (F&M), und

•Direct Manipulation (DM).

Direct Manipulation

Dienstag, 9. Juni 2009                                                                                                  6

Beginnen wir mit der anscheinend jüngsten Form, der „Direct Manipulation“.

In ihr manipuliert ein Anwender ein virtuelles Objekt direkt, etwa durch Ziehen, Verschieben, Strecken, Drehen,

Schneiden, Maximieren, Minimieren, Sortieren, Filtern u.s.w. Wir kennen diese Form heute meist aus Grafik-Programmen,

Spielen, virtuellen Ton- und Filmstudios oder Desktop-Publishing-Programmen.

Wir begegnen dieser Form in jüngster Zeit vermehrt auch bei herkömmlichen Office-Anwendungen - wie E-Mail,

Adressverwaltung, Terminverwaltung oder Aufgabenverwaltung - dann allerdings eher im Zusammenhang mit modernen

Endgeräten, wie dem iPhone, iPod Touch, Tablet PCs, PCs mit Touch-Screens, Laptops mit modernen Touchpads oder Stift-

Tablets an.

Direct Manipulation setzt auf den ersten Blick eine graphische Oberfläche voraus. Doch behaupte ich, dass Direct

Manipulation weniger an eine bestimmte Technik sondern eher an ein bestimmtes mentales Modell gebunden ist.

Direct Manipulation

                                                                                                 Xerox Parc
                                                                                                 Alto
                                                                                                 mit
                                                                                                 SmallTalk
Dienstag, 9. Juni 2009                                                                                                     7

Zwar wurden die ersten Maschinen mit graphischer Bedien-Oberfläche bereits Anfang der siebziger Jahre im

Forschungszentrum Xerox Parc entwickelt - so z. B. der ALTO (1973) oder Star (1981) - und Anfang der 80er Jahre von Apple

übernommen und weiterentwickelt. Aber es sollte noch bis Anfang der 90er Jahre dauern, bis Microsoft mit Windows 3.0

eine marktrelevante Entwicklung lieferte und eine offensichtliche Fehlentscheidung im Hause Apple - nämlich die, den

Macintosh mit seiner graphischen Benutzeroberfläche nicht als Office-Maschine zu positionieren - zum eigenen Vorteil

ausnutzte und Office-Anwendungen, wie z. B. Word oder Excel, mit graphischer Oberfläche anbot.

Interfaces mit Direct Manipulation sind - sofern sie gut entworfen wurden - intuitiv und daher sehr leicht von Anwendern

zu erlernen und zu bedienen. Sie kommen meist ohne jegliche Fehlermeldungen aus. Allerdings erfordern das Design und

die Implementation sehr viel Aufwand, nicht zuletzt weil man von Natur aus kaum auf vorhandene User Interface Toolkits

zurückgreifen kann und fast alle Widgets selber programmieren muss. User Interfaces mit Direct Manipulation werden in

sehr enger Zusammenarbeit mit potentiellen Anwendern entworfen - wie: das werde ich im dritten Seminar-Teil anhand des

iPhone bzw. iPod Touch veranschaulichen.

Direct Manipulation

Dienstag, 9. Juni 2009                                                                                                        8

Der Begriff „Direct Manipulation“ - also „Direkte Bearbeitung“ - sagt an sich nichts über die Technik aus, sondern er

umschreibt lediglich wie ein Nutzer Informationen instantiiert, verändert, sichtet und löscht - nämlich: direkt. Der Nutzer

interagiert direkt mit einem Objekt, das ein Informations-Träger ist. Wie agiert man aber mit Informationen? Was sind

überhaupt Informationen? Wie agiere ich mit einer Adresse, mit einem Angebot, mit einer Rechnung, mit einem

Kundenkonto? Wir müssen der Information einen Träger und diesem Träger eine Form geben. Die Programmiersprache,

mit der Anfang der 70er Jahre auf dem Alto programmiert wurde, heißt „SmallTalk“. Will man in SmallTalk ein Objekt

visualisieren, so definiert man einen „Morph“. „Morphologie“ ist die Lehre von der Form.

Informationen benötigen schon immer einen Träger. Nachrichten werden auf Zeitungspapier gedruckt. Telefonnummern

stehen in Telefonbüchern. Adressen schreiben wir auf Karteikarten. Ich hatte im ersten Seminar kurz über meine Anfänge

in der Informatik berichtet. Meine Wurzeln gehen zurück in die Anfänge der 70er Jahre und befinden sich in der s. g.

Mittleren Datentechnik. Während in der Großrechner-Welt die riesigen Maschinen in hermetisch abgeriegelten Sälen von

Experten in weißen Kitteln bedient wurden, hatte in der Mittleren Datentechnik der Nutzer direkten Zugang zu den

Maschinen und zu den Daten. Primärer Informationsträger war die Lochkarte - ergänzt wurde sie später durch s. g.

Magnetkonten. Beide boten Nutzern den großen Vorteil des wahlfreien Zugriffs auf überschaubare Daten. Lochkarten

konnten sowohl von Menschen als auch von Computern gelesen werden. Um Lochkarten zu sortieren oder zu selektieren

bedurfte es nicht einmal eines Computers. Selbst große Datenmengen wurden ohne Computer und mit mechanischen

Sortiermaschinen sortiert. Die Farbe einer Lochkarte konnte etwas über ihren Inhalt aussagen: etwa „Rot“ für Kunden,

„Blau“ für Lieferanten und „Gelb“ für den Artikelstamm.

Direct Manipulation

Dienstag, 9. Juni 2009                                                                                                 9

 Von der Höhe eines Lochkarten-Stapels konnte man auf die Verarbeitungsdauer schließen. Kleinere Notizen konnten mit

einem normalen Stift auf die Vorder- oder Rückseite der Lochkarte für jedermann lesbar geschrieben werden. Einen

Datensatz zu löschen war ganz einfach. Hatte man eine Lochkarte versehentlich gelöscht, konnte man sie ohne Computer

und mit Hilfe einer Lochkarten-Stanzmaschine relativ einfach duplizieren.

Informationen hatten also die Form von Lochkarten - oder von Magnetkonten. Mit ihnen konnte der Anwender tun und

lassen was er wollte - keine Maschine gängelte ihn, was vieles sehr einfach machte. Man musste nicht warten, bis ein

Programmierer eine neue Filter- oder Sortierfunktion programmiert hatte. Neue Datensätze wurden einfach mit einer

Stanzmaschine generiert.

Wollte ich ein wiederverwendbares Programm benutzen - etwa ein Buchungsprogramm für Eingangsrechnungen -, dann

musste ich es zuerst mit Stammdaten füttern. Angenommen, ich wollte Lieferanten-Rechnungen buchen, dann musste ich

die Lochkarten mit den Informationen über Lieferanten und Sachkonten einlesen, bevor ich mit dem Buchen beginnen

konnte. So einfach das klingt - was aber, wenn ich die Lochkarte mit dem Verbindlichkeiten-Sammelkonto 1600

versehentlich gelöscht habe?

Bei diesem Gedanken wird jedem Buchhalter und Geschäftsführer Angst und Bange. Mit zunehmender Datenmenge stieg

selbst in Kleinstunternehmen die Komplexität von Informations-Systemen. Die Stabilität eines Systems hängt in hohem

Maße von der Konsistenz des Informationsmodells ab.

Forms & Menus

Dienstag, 9. Juni 2009                                                                                                     10

Ganz anders sieht es mit „Formularen und Menüs“ aus. Formulare verändern Datenmodelle nur indirekt. In Formularen

gebe ich Informationen ein und übergebe diese an Prozeduren, die mir die Stabilität des Systems jederzeit zusichern. Ich

kann also, um bei dem Beispiel von vorhin zu bleiben, ein Konto nur dann löschen, wenn ich eine Lösch-Prozedur z. B.

zusammen mit dem entsprechenden Kontenstammblatt aufrufe.

„Formulare und Menüs“ benötigen keine graphischen Desktops. Fast könnte man sogar sagen, dass diese Form nicht einmal

einen Computer benötigt. Formulare und Menüs gibt es, seitdem es Verwaltungen gibt. Wenn ich heute das Finanzamt

besuche, finde ich gleich im Eingang Regale mit allen denkbaren Formularen, über die ich mit „meinem“ Finanzbeamten

kommunizieren kann. Rechenzentren haben diese Art der Kommunikation lange Zeit beibehalten. Ich kann mich noch gut

daran erinnern, wie ich in den 70er Jahren von unserem Rechenzentrum mittels Formular hin und wieder Adresslisten

anforderte. Am nächsten Tag stand auf meinem Schreibtisch ein Stapel Tabellierpapier, auf dem die angeforderten

Anschriften gedruckt waren. Für Änderungen und Löschungen musste ich jeweils andere Formular ausfüllen und sie zu

einer bestimmten Zeit an das Rechenzentrum weiterreichen.

Diese Arbeitsweise wurde auch dann noch beibehalten, als Nutzer selber die Daten mit zeichenorientierten Terminals

erfassen und bearbeiten konnten. Einziger Unterschied war, dass die Formulare im System hinterlegt und über

Funktionstasten abrufbar waren. Selbst mit Verbreitung von graphischen Desktop Systemen hat sich an dieser

Interaktionsform kaum etwas geändert - nur sind die Formulare bunter und zahlreicher geworden, und Anwender können

auf ihrem Desktop nicht nur ein sondern gleich mehrere Formulare parallel sehen. Sämtliche Programmiersprachen und

Programmiersysteme bieten umfangreiche UI Toolkits an, mit deren Widget-Libraries jeder Programmierer ganz schnell

ganz einfache Formulare implementieren kann.

Command Line
                               Interface

Dienstag, 9. Juni 2009                                                                                                      11

Die dritte Form von User Interfaces ist das Command Line Interface. Das Command Line Interface implementiert das

Interaktionsmodell der guten alten Telex-Maschine. In Unix-Betriebssytemen bezeichnet man daher heute noch die

Terminals als „TTY“, was die Abkürzung für „Teletype Machine“ ist. Eine Teletype-Machine ist nichts anderes als ein

zeichenorientiertes Telefon - man spricht nicht, sondern man tippt. Ich kann mich noch daran erinnern, wie ich Anfang der

80er Jahre mit Hilfe eines herkömmlichen Telex-Gerätes mit Rechnersystemen von Fluggesellschaften und Hotels

kommuniziert habe. Selbst Ende der 80er Jahre hatte ich für einen Bus-Reiseveranstalter die Schnittstelle zu einer Telex-

Box geschrieben, worüber dieser Buchungen von Reisebüros entgegen nehmen konnte.

Beim Command Line Interface wurde gegenüber der Teletype-Maschine einer von beiden humanen Akteuren durch einen

virtuellen Akteur ersetzt - nämlich durch ein Computer-System. Und so, wie man in der Kommunikation mit einem anderen

Menschen dessen Sprache im weitesten Sinne kennen muss, um eine vernünftige Unterredung zu führen, muss man dies

auch in der Kommunikation mit einem Computer-System über ein Command Line Interface. Will sagen: die gesamte

Information über die vom System verstandenen Kommandos und ihre Syntax und über die Strukturen der

zurückgelieferten Antworten muss bei einem Command Line Interface im Gedächtnis des Anwenders vorhanden sein.

Command Line
                                Interface

Dienstag, 9. Juni 2009                                                                                                   12

Selbst heute nutzen wir noch dieses Interface-Modell: beim Schreiben und Lesen von SMS oder beim Chatten. Klassische

Anwendungen sind weiterhin die Shell von UNIX-Systemen und die weltweit verbreiteten Buchungssysteme der

Fluggesellschaften. Diese Form von Interface ist äußerst flexibel, sehr kostengünstig, und sie bietet hervorragende

Möglichkeiten zum Skripting von komplexen Prozeduren.

Hat man erst einmal eine der beiden Akteure durch einen Computer ersetzt, so hindert einen nichts, das gleiche auch am

anderen Ende der Leitung zu tun.

Anwender, die die Sprache eines solchen Systems einmal beherrschen, wollen niemals zu einem System mit Formularen

und Menüs wechseln.

Alle drei Formen von User Interfaces - das Command Line Interface, Formulare und Menüs, und Direct Manipulation

implementieren völlig unterschiedliche Gedankenmodelle. Es ist wichtig, dass wir diese Gedankenmodelle und die mit

ihnen verbundenen Vor- und Nachteile sehr gut verstehen, bevor wir uns zusammen mit den Nutzern auf eine diese Formen

für ein Anwendungssystem verständigen. Oft entstehen Probleme erst dadurch, dass wir Eigenschaften verschiedener

Formen mischen, z. B. indem wir einem Formular-basierten System Funktionen der Direct Manipulation Form zuordnen -

einfach weil wir es vielleicht chic finden, wenn sich ein Formular dreht und wendet.

Von daher kann die vornehmste Aufgabe von uns Entwicklern und User Experience Designern nur darin bestehen, uns mit

dem Nutzer, seiner Vorstellungswelt und seinen Problemen vertraut zu machen, bevor wir unser Handwerk dazu nutzen, um

ihm eine hoffentlich geeignete Lösung zu bauen.

Boston College
                     Campus Police: "Using
                      Prompt Commands"
                        May Be a Sign of
                        Criminal Activity
                         http://www.eff.org/deeplinks/2009/04/boston-college-prompt-commands-are-suspicious

                                                         April 14th, 2009

Dienstag, 9. Juni 2009                                                                                        13

Ohne Worte

UX Designer

                                           http://smokingapples.com/iphone/iphone-beautiful-ui-design/

Dienstag, 9. Juni 2009                                                                                                   14

Wenn wir Software-Entwickler über User Experience Design sprechen, so denken wir i. d. R. an Widget Libraries mit

Windows, Panels, Menüs, Drop-Downs, Textboxen, Toolbars, Buttons, Tooltipps und vielen anderen virtuellen Objekten. Wir

reden über diese Objekte als seien sie losgelöst von jeglicher subjektiver Wahrnehmung: „Ein Button ist ein Button und löst

die auf ihm angegebenen Funktion aus, und eine Textbox ist ein Eingabefeld, in die jeder Anwender die erwarteten Werte

eingeben kann.“

Wir betrachten oft eine graphische Oberfläche und die darauf befindlichen Elemente wie selbsterklärende Objekte.

Folglich glauben viele Entwickler, sie müssen nur das richtige UI Toolkit auswählen und es beherrschen, um damit für jede

beliebige Anforderung von jedem beliebigen Anwendern gerüstet zu sein. Lange bevor wir den Benutzer, dessen

Vorstellungswelt und seine Probleme kennen, beherrschen wir ein User Interface Toolkit.

Dabei vergessen wir oft, dass Objekte nur das sind, als was sie von uns Subjekten, nämlich von uns Menschen,

wahrgenommen werden. Hinzu kommt, dass die subjektive Wahrnehmung auch solch subtile Abläufe umfasst, wie Sinnes-

Empfindungen, Seelen-Erlebnisse und Urteilsvermögen.

Wahrnehmung

Dienstag, 9. Juni 2009                                                                                                      15

Ich will das an drei Beispielen kurz erläutern.

A) Auf mein Auge trifft das Licht von tausenden Bildpunkten eines Monitors und ich treffe die Aussage „Der Knopf ist

    grau“. Diese Aussage sagt nichts über meine Sinnes-Empfindungen aus, die mir hilft, dem Licht eine Form, nämlich die

    des Knopfes, und die Farbe Grau zuzuordnen.

B) „Der Knopf auf dem Bildschirm ändert seine Form.“ Dies sagt nichts darüber aus, was ich beim Betrachten des Knopfes

    erlebe - beispielsweise, dass der Knopf von mir gedrückt wurde.

C) „Der Ordner ist geöffnet und das Formular ist leer.“ Hiermit treffe ich zwar eine objektive Feststellung, allerdings mache

    ich keine Aussage über den Sachverhalt, wonach diese beiden Objekte in einem Zusammenhang stehen.

Man kann nicht Objekt-orientiert entwickeln, ohne sich mit der subjektiven Wahrnehmung zu beschäftigen. Das trifft

insbesondere auf die Benutzer-Oberfläche zu. Wir werden darauf noch in besonderer Weise im dritten Teil des Seminars

eingehen.

Vor diesem Hintergrund betrachtet ein User Experience Designer folgende Aspekte der Oberfläche eines

Anwendungssystems:

•die Erlernbarkeit (Learnability),
•die Einfachheit (Simplicity),
•die Sichtbarkeit (Visibility),
•die Kontrolle durch den Anwender (User Control),
•die Behandlung von Fehlern (Error Handling),
•der Aufwand bei der Erledigung von Aufgaben (Efficiency), und
•das graphische Design.

Learnability

                                                                           http://thelrocks.wordpress.com/2009/01/16/prokrastination-mein-groster-feind/

Dienstag, 9. Juni 2009                                                                                                                                16

Hirnforscher gehen davon aus, dass wir Menschen über zwei grundsätzlich verschiedene Systeme zur Langzeit-Speicherung

von Informationen verfügen. Demnach lernen wir entweder durch Erfahrung oder durch Training.

Ich beiße mit Elan in eine weiche Frucht mit hartem Kern, was sehr schmerzen kann. An diese Erfahrung werde ich mich

mein Leben lang erinnern. Wahrscheinlich werde ich mich sogar noch an viele Einzelheiten aus dem Kontext erinnern, z.

B. dass es die Kirsche im Kuchen war, den meine Mutter zum sechsten Geburtstag meiner Schwester gebacken hatte.

Erfahrungen werden im deklarativen bzw. episodischen Gedächtnis gespeichert.

Will man hingegen eine Sprache, ein Musikinstrument oder einen Sport erlernen, hilft nur regelmäßiges Üben. Dabei

reicht es beispielsweise nicht, wenn wir uns zum Klavierspielen einmal pro Woche für wenige Sekunden vor das Klavier

setzen. Hier erfolgt die Speicherung im prozeduralen Gedächtnis.

Wenn wir nun erreichen möchten, dass Menschen ein neues Objekt auf Anhieb als nützlich erkennen und den Umgang mit

ihm schnell erlernen, müssen wir es so gestalten, dass seine potentiellen Benutzer einige der bei ihnen bereits vorhandenen

Vorstellungen mit diesem Objekt verknüpfen können.

Learnability
                                      Affordance

Dienstag, 9. Juni 2009                                                                                                       17

So wie eine Türklinke signalisiert „Durch Herunterdrücken der Klinke kannst Du die Tür öffnen“, so signalisiert

beispielsweise ein Push-Button „Wenn Du mit der Maus auf mich klickst, dann rufe ich die auf mir bezeichnete Funktion

auf.“

Wenn eine User Interface Komponente dem Benutzer eine Handlungsoption aufzeigt, so reden die User Experience

Designer von „Affordance“.

Das Wort „Affordance“ existiert in keinem offiziellen Englisch-Wörterbuch. Übersetzungsdienste im Internet verweisen

allenfalls auf Forums-Beiträge, in denen „Affordance“ mit „Affordanz“ oder „Angebots-Charakter“ übersetzt wird.

So schlecht man dieses Wort übersetzen kann, so sehr wird in das Design von Affordances investiert.

Ein Push-Button muss gedrückt werden. Mit einem Radio-Button wähle ich genau einen Wert aus einer Menge von Werten

aus. Check-Boxen nehmen für ein Element den Wert „Wahr“ oder „Unwahr“ an. Mit Scroll-Bars bewege ich ein Fenster

über ein darunter liegendes Dokument. Will ich erreichen, dass ein potentieller Benutzer auf Anhieb mit meinem System

arbeiten kann, so sollte ich mich an Standards halten.

Als ich kürzlich meiner Frau eine von Entwicklern erstellte Oberfläche zeigte, fiel ihr das Lupen-Symbol auf, bei dem der

Griff nach links zeigte. „Ist dies ein Programm für Linkshänder?“, war ihre Reaktion. In ihrer Vorstellung zeigt der Griff

einer Lupe immer nach rechts. Zeigt der Griff nach rechts, dann weiß jeder, dass dieses Bild eine „Such-Funktion“

symbolisiert.

Schwierig wird es, wenn wir graphische Komponenten für „Direct Manipulation“ definieren müssen, die zugleich neue

Interaktions-Muster symbolisieren.

Learnability
                                     Konsistenz

                 Keynote                            Pixelmator                                Apple Mail

Dienstag, 9. Juni 2009                                                                                                    18

Nicht nur die Gestaltung bzw. Auswahl von „Affordances“ beeinflusst die Erlernbarkeit eines Systems. Hierzu gehören auch

die Strukturierung von Menüs und die Bedeutung von s. g. Keyboard-Shortcuts. Mit +“S“ sichere ich ein Objekt, mit

+“N“ erstelle ich ein neues Objekt und mit +“P“ rufe ich die Druckfunktion auf. Auf einem Mac werden für

Keyboard-Shortcuts anstelle der -Taste die -Taste gedrückt.

Will man alternative Zeichen mit einer PC-Tastatur erzeugen, nutzt man die  Taste. Bei einem Mac nutzt man die

-Taste. Das Euro-Währungssymbol erhält man mit +“E“ bzw. mit +“E“. Allerdings verwirrt es selbst

gestandene IT-Profis wenn der Klammeraffe mit deutschen PC-Tastaturen durch Drücken von +“Q“ und auf einer

Mac-Tastatur mit +“L“ erzeugt wird. So banal dieses Beispiel klingt - es trägt dazu bei, dass sich Nutzer beim Umstieg

vom PC auf einen Mac nicht richtig wohl fühlen.

Learnability
                                      Nachahmen

Dienstag, 9. Juni 2009                                                                                                           19

Komplexe Abläufe kann ich sehr gut durch Nachahmung lernen. Will ich beispielsweise lernen, wie ich ein Eclipse RCP

Plug-in erstelle, verschaffe ich mir mit Hilfe von s. g. „Cheat-Sheets“ einen Überblick über den Ablauf und verwende dann

eine Vorlage, die mir ein fertiges Plug-in erstellt. Im ersten Seminar hatte ich erwähnt, wie schnell ich auf diese Weise eine

Internet-Präsenz für eine kleine Pension erstellt hatte. Durch Nachahmung und durch die Verwendung von Vorlagen habe

ich in kürzester Zeit ein Erfolgserlebnis, ohne die Kontrolle an das System jemals abgegeben zu haben. Vielleicht reicht mir

das Ergebnis und ich werde daher künftig immer in ähnlichen Situationen die selbe Vorlage verwenden, oder ich möchte

lediglich einzelne Details verändern, ohne gleich das gesamte System beherrschen zu müssen.

Dieses Konzept implementieren zahlreiche Anwendungssysteme, indem sie erweiterbare Vorlagen anbieten. Vorlagen sind

dabei sehr komplexe Affordances, indem sie Benutzern Handlungsoptionen für komplexe Workflows anbieten. Beispiele:

•„Nimm diese Vorlage für die Buchung eines Fluges.“

•„Nimm diese Vorlage für eine neue Kundenadresse.“

•„Diese Vorlage hilft Dir beim Erstellen eines Geschäftsberichtes.“

•„Und diese Vorlage hilft Dir beim Erstellen eines Liquiditätsplans.“

Learnability
                                      Feedback

Dienstag, 9. Juni 2009                                                                                                   20

Im Zusammenhang mit „Erlernbarkeit“ möchte ich noch kurz die Relevanz von „Rückmeldungen“ bzw. von „Feedbacks“

besprechen.

Gerade hatte ich kurz erwähnt, dass ein Anwender stets eine möglichst positive Rückmeldung zu seiner Tätigkeit wünscht

und dass ihm diese Rückmeldung hilft, um einen einmal eingeschlagenen Pfad weiter zu verfolgen oder um sein Vorgehen

zu korrigieren. Wenn ich beispielsweise binnen weniger Minuten eine für mein Empfinden Web-Seite gestalten kann, dann

weiß ich, dass ich das für meine Verhältnisse richtige Werkzeug gewählt habe.

Die Relevanz von Feedback ergibt sich aber auch schon viel unmittelbarer. Wenn wir einen Push-Button drücken, dann

wollen wir sofort sehen, dass der Knopf tatsächlich gedrückt wurde. Wenn wir im Browser die URL einer Webseite

eingeben, dann wollen wir sofort sehen, dass der Browser die Webseite öffnet.

In welchem zeitlichen Rahmen Feedback erfolgen sollte, besprechen wir später im Zusammenhang mit „Visibility“.

Fassen wir das Kriterium „Erlernbarkeit“ zusammen: Damit der Umgang mit einem System einfach gelernt werden kann,

muss es die geeigneten Affordances - geeignete Hinweise auf Handlungsoptionen liefern. Wir müssen an bereits

vorhandenes Wissen anknüpfen und wir können dem Anwender fertige Lösungen für komplexere Abläufe bieten, die er in

Teilen verändern kann.

Simplicity

Dienstag, 9. Juni 2009                                                                                              21

Je weniger Handlungsoptionen ein Gegenstand anbietet, um so eher nehmen Menschen diesen Gegenstand als einfach zu

handhaben wahr. Ein Stein, eine Keule und ein Speer bieten sehr wenige Handlungsoptionen. Will man mit dem Stein aber

Feuer machen, so müssen beispielsweise Katzengold, Zunderschwamm und Späne hinzugefügt werden - und schon wird die

Sache wesentlich komplizierter - zumindest für „moderne“ Menschen. Kein Wunder, dass die meisten modernen Menschen

Einweg-Feuerzeuge mit Einknopf-Bedienung bevorzugen, verbergen sie doch einen komplexen physikalischen Ablauf hinter

einem einzelnen Knopf.

Ein Neandertaler wird hingegen beim Feuer-Machen mit Katzengold, Feuerstein, Zunderschwamm und Spänen

wahrscheinlich weniger Probleme haben, wie wenn er zum ersten Mal das Einweg-Feuerzeug benutzen soll.

Simplicity

Dienstag, 9. Juni 2009                                                                                                     22

Erinnern wir uns an die Graphik, die ich zur Einleitung des letzten Seminars gezeigt hatte und die die einfachen

Oberflächen eines Apple-iPod‘s und der Google-Suchmaschine mit denen von Unternehmenssoftware verglichen. Eine

einfach gehaltene Oberfläche mit wenigen Handlungsoptionen signalisiert dem Benutzer ein leicht zu erlernendes System.

Ob eine Sache einfach oder schwierig ist, kann man allerdings nur im Kontext mit der jeweiligen Situation beurteilen - und

zu einer Situation gehört natürlich stets derjenige, der das System benutzt und somit beurteilt. Ein Software-Entwickler

wird mit einer Oberfläche, die an die Eclipse IDE erinnert, weniger Probleme haben, als ein Nicht-Programmierer. Ähnlich

verhält es sich wahrscheinlich mit einem Web-Designer und dem Photoshop-Benutzungsmodell.

Da es zur Aufgabe von Entwicklern gehört, komplexe Systeme zu bedienen, können Software-Entwickler von Natur aus mit

komplexen Oberflächen-Systemen umgehen. Ganz anders sehen das aber „normale“ Benutzer. „Normale“ Benutzer

erwarten von einem neuen System, dass es die Komplexität hinter einer einfachen Benutzer-Oberfläche verbirgt.

Umgekehrt wird ein Reisebüro-Agent die Benutzung des Command Line Interfaces eines Reservierungssystems als einfach

empfinden, während selbst Software-Entwickler und ganz besonders Web-Designer dieses System als viel zu komplex

beurteilen.

Wir Entwickler und Designer müssen stets daran denken, dass wir nur in den seltensten Fällen die Anwender unserer

eigenen Systeme sind.

Alternativen zur Erlangung einfacherer Oberflächen-Systeme werden wir im dritten Seminar besprechen.

Visibility

                         • Aktionen
                         • Zustand Oberfläche
                         • Zustand Modell
                         • Reaktionen

Dienstag, 9. Juni 2009                                                                                                23

Mit „Visibility“ bezeichnen wir das Kriterium, wonach alle in der jeweiligen Situation relevanten Informationen und

Handlungsoptionen sichtbar sind.

Wenn ein Benutzer eine wichtige Information nicht sieht, dann kann er nur raten, ob diese Information oder Aktion

überhaupt existiert und wenn ja - wo.

Dabei können wir das Visibility-Kriterium in drei Bereiche gliedern:

•Sichtbare Aktionen - wo finde ich Aktionen

•Sichtbarer Zustand der Oberfläche und des bearbeiteten Modells - wo liegt meine Aufmerksamkeit

•Sichtbare Reaktionen - gefühlter Zusammenhang und Antwortzeiten

Visibility
                         Sichtbare Aktionen

                                                         Maybe
                                                         something
                                                         like this?

Dienstag, 9. Juni 2009                                                                                                  24

Aktionen sind die Handlungen, die ein Benutzer mit Hilfe des User Interfaces ausführen kann. Bei Formular-Oberflächen

werden Aktionen i. d. R. im Hauptmenü und in Aktions-Buttons innerhalb des Formulars angeboten. Die gebräuchlichsten

Aktionen kann man zusätzlich in Toolbars oder in eine Sidebar integrieren.

Bei „Direct Manipulation“-Oberflächen müssen sich dem Anwender die möglichen Aktionen allein aus der Form der

Controls und ihrer räumlichen Nähe zu anderen Objekten erschließen. Beispiel für ein Mischpult: Ist der Schieberegler

eines Potentiometers in der Audio-Spur des Sprechers am oberen Ende angelangt, so kann ich die Lautstärke nur noch

verringern.

Visibility
                         State UI & Model

Dienstag, 9. Juni 2009                                                                                                   25

Mit „Zustand“ ist der Zustand der Benutzeroberfläche und des darunter liegenden Modells gemeint. Beispiele:

•Welche Datensätze habe ich ausgewählt?
•Welche Informationen beinhaltet mein Modell im Moment?

•Wurden Informationen verändert, ohne dass das Modell gesichert wurde?

•Ist dies ein neuer Datensatz?

Hier liegt eine von vielen Schwächen eines Command Line Interfaces. Einige Benutzer von Unix Shells integrieren einige

Status-Informationen in den Shell-Prompt, z. B. um sich den aktuellen User Account und den aktuellen Pfad anzeigen zu

lassen.

Eclipse IDE zeigt in den Editor-Tabs den Dateinamen an. Ebenso findet man hier ein s. g. „Dirty Flag“, sobald Änderungen

am Modell vorgenommen wurden, ohne sie zu ändern.

Beim VI-Editor weiß allenfalls, in welchem Modus sich das User Interface befindet - hier im „Insert-Modus“. Den

Dateinamen sehe ich nicht und ich kann nicht erkenne, ob ich Änderungen vorgenommen habe, die noch nicht gesichert

wurden.

Bei „Direct Manipulation“ Interfaces sollte sich der Zustand des Modells aus dem Zustand des User Interfaces erschließen.

Visibility
                                      Reaktionen

                         • = 5 Sekunden

Dienstag, 9. Juni 2009                                                                                                        26

Hiermit meine ich die Rückmeldung des Systems aufgrund einer Benutzeraktion. Dabei unterscheiden wir zwischen

•Low Level Feedback - z. B. der Rückmeldung eines Push-Buttons, und
•High Level Feedback - das den Zustand des bearbeiteten Modells oder beispielsweise das Laden eines neuen Formulars
signalisiert.

Feedback kann durch Veränderung des sichtbaren Zustands oder einfach nur durch Anzeige einer Meldung erfolgen.

Drücke ich mit der Maus auf einen Push-Button, so muss sich die Form des Push-Buttons sofort verändern, um den

Anwender zu signalisieren, dass der Button gedrückt wurde.

Was heißt „sofort“? Menschen nehmen zwei aufeinander folgende Bilder als zusammenhängend war, solange diese in einem

zeitlichen Abstand von 50 bis höchstens 200 Millisekunden angezeigt werden. Als Faustformel sollte man sich 100

Millisekunden merken.

Ab einer Verzögerung von 0,1 bis 1 Sekunde bemerkt der Anwender die Verzögerung und denkt ggf. über alternative

Aktionen nach.

Ist absehbar, dass die Aktion zwischen einer und fünf Sekunden braucht, bevor das Ergebnis am Bildschirm angezeigt

werden kann, sollte ein Sanduhr oder eine ähnliche animierte Graphik, wie z. B. ein drehendes Rad angezeigt werden.

Bei Aktionen die länger als fünf Sekunden benötigen, sollte auf jeden Fall ein Fortschritts-Indikator angezeigt werden, der

dem Anwender signalisiert, wie lange die Aktion noch benötigt. Und außerdem sollte dem Anwender die Möglichkeit

gegeben werden, die Aktion abzubrechen.

User Control

                         • Undo - Redo
                         • Wo bin ich - wie komme ich zurück
                         • Abbruch
                         • Änderbarkeit

Dienstag, 9. Juni 2009                                                                                                      27

Jakob Nielsen (http://www.useit.com) hatte diesen Begriff „User Control“ ursprünglich geprägt. Die Frage ist, wer das Sagen

über einen Dialog-Schritt und über die Daten hat - der Benutzer oder das Computer System. Natürlich heißt lt. Nielsen die

Antwort: der Benutzer. Ereignis-orientierte Softwareentwicklung trägt diesem Anspruch dem Wesen nach Rechnung,

beispielsweise indem der Anwender über die Reihenfolge, in der er Informationen in ein Formular einträgt, selber

entscheidet.

Eine weitere Frage ist, ob der Nutzer eine einmal getroffene Entscheidung wieder rückgängig machen kann - z. B. mit Hilfe

einer Undo-Funktion.

User Control soll den Nutzer auch dazu animieren, eine Anwendung ohne Angst vor Fehlern zu erkunden. Folglich lautet

eine weitere Frage, ob der Anwender jederzeit weiß, wo er sich gerade befindet, ob er jederzeit wieder zum Ausgangspunkt

zurück findet und ob er jederzeit eine Aktion wieder abbrechen kann?

Natürlich gibt es Situationen, in denen das System die Führung übernehmen soll - z. B. bei der Installation von Software.

Hier wird oft das Wizard-Pattern benutzt. Aber auch hier sollte der Anwender die Möglichkeit haben, einen Schritt zurück

zu gehen, zu sehen, wo er sich gerade im Prozess befindet, und er sollte jederzeit den gesamte Prozess wieder abbrechen

können.

Software-Systeme sind u. a. dazu da, Prozesse zu automatisieren. Allerdings kann ein und derselbe Prozess in

unterschiedlichen Situationen nicht immer vollständig automatisiert werden. Der Anwender sollte folglich die Möglichkeit

haben, den Grad der Automation jederzeit zu verändern bzw. eine automatisch vorgeschlagene Lösung manuell zu

korrigieren. Beispiel: in Google Maps kann ich die Route zwischen zwei Orten generieren lassen. Diese Route kann ich

anschließend u. a. durch einfaches Ziehen verändern.

User Control

                         • Undo - Redo
                         • Wo bin ich - wie komme ich zurück
                         • Abbruch
                         • Änderbarkeit

Dienstag, 9. Juni 2009                                                                                                  28

Hinsichtlich der Kontrolle über die Daten bzw. über die Modelle wird überprüft, ob ein Anwender einmal erfasste Daten

jederzeit wieder ändern oder sogar löschen kann. Es ist für einen Benutzer äußerst frustrierend, wenn er Daten nur

erfassen kann, später aber keine Möglichkeit mehr hat, diese zu manipulieren.

Error Handling

       http://www.moffem.de/en/babel/04-money-deficiency-symptom.html

                                                                        http://www.moffem.de/de/keller2/original/en-adri-pilz-unreal-xxxl-fafem.gif

Dienstag, 9. Juni 2009                                                                                                                                29

Wir unterscheiden zwischen zwei Arten von Fehlern:

•Flüchtigkeitsfehler und Versehen, und
•Echte Fehler.

Bei Flüchtigkeitsfehlern und Versehen gehen wir davon aus, dass der Nutzer das System kennt, dass er aber beispielsweise

aus Unachtsamkeit einen Knopf gedrückt hat oder dass er mangels Konzentration vergessen hat, was er eigentlich wollte.

Bei Echten Fehlern gehen wir davon aus, dass der Anwender aus Unwissen ein falsche Tool oder gar einen falschen

Lösungsweg für eine bestimmte Aufgabe gewählt hat.

Die Frage ist, wie gut das User Interface Fehler vorbeugt und vermeiden hilft. Kann der Anwender erkennen, ob das

gewählte Tool dem Zweck tatsächlich dient? Sieht der Anwender jederzeit, in welchem Zustand das Modell oder das User

Interface ist? Wird die Arbeit des Benutzers jederzeit vor Fehlbedienung durch den Benutzer gesichert?

Viele Fehlermeldungen sind ein Indikator für schlechte User Experience Design. Bevor man eine Fehlermeldung schreibt,

sollte man sich überlegen, wie man diese Fehlermeldung vermeiden kann.

Sollten dann doch noch Fehlermeldungen nötig sein, so schaut sich der User Experience Designer an, ob diese präzise

sind, ob sie die Sprache des Benutzers (und nicht des Entwicklers) sprechen, ob sie die Fehlerursache und ob sie

konstruktive Hinweise zur Vermeidung des Fehlers bzw. zur Fehlerbehebung geben.

Ende
                         http://web.me.com/beckmerhagen/UX

Dienstag, 9. Juni 2009                                       30