Universität Stuttgart

Größe: px
Ab Seite anzeigen:

Download "Universität Stuttgart"

Transkript

1 Universität Stuttgart Fakultät Informatik, Elektrotechnik und Informationstechnik Studiengang: Softwaretechnik Prüfer: Prof. Dr. Thomas Ertl Betreuer: Dipl. Inf. Fabienne Marquardt (IBM) Dr. Matthias Ressel (Universität Stuttgart) Beginn am: Beendet am: CR-Nummer: D.2.1, D.2.2, H.1.2, H.5.2 Diplomarbeit Nr Redesign von Benutzungsoberflächen durch Mittel der Navigation Harriet Kasper Universität Stuttgart Fakultät Informatik, Elektrotechnik und Informationstechnik Institut für Visualisierung und Interaktive System (VIS) Universitätsstraße 38, D Stuttgart IBM Deutschland Entwicklung GmbH Abteilung Informationsentwicklung & Usability Engineering Schönaicher Straße 220, D Böblingen

2

3 Zusammenfassung In der Diplomarbeit wurde ein auf Treemaps basierendes Visualisierungs- und Navigationskonzept entworfen und evaluiert. Das Redesign des DB2 Performance Experts von IBM bildete das Rahmenprojekt dafür. Die Entwicklung folgte einem iterativen, partizipativen Vorgehensmodell. Das entstandene Konzept wurde Monitor Maps genannt. Es handelt sich dabei um eine Kombination aus Treemaps und Statusfarben, welche die Aufmerksamkeit des Benutzers lenken. Die Monitor Maps wurden in die bestehende Benutzungsoberfläche des DB2 Performance Experts integriert. Die Gestaltung der Interaktion macht die Darstellung zu einem mächtigen Navigationskonzept, das für den Benutzer des DB2 Performance Experts geeignet ist. Es wurden zwei Alternativen von Monitor Maps prototypisch entworfen, ihre Eigenschaften analysiert und gezeigt, wie sich das Konzept auf andere Bereiche übertragen lässt. Außerdem wurden in der Diplomarbeit die Unterschiede von Redesign und Neuentwurf herausgearbeitet.

4

5 Ich danke der IBM Deutschland Entwicklung GmbH für die Chance, meine Diplomarbeit in einem praktischen Umfeld schreiben zu können. An der Universität Stuttgart bedanke ich mich bei Prof. Dr. Thomas Ertl und Dr. Matthias Ressel für die Ermöglichung und Betreuung dieser Arbeit. Mein besonderer Dank gilt der außerordentlichen Betreuung bei IBM durch Fabienne Marquardt, von der ich sehr viel gelernt habe. Ein herzliches Dankeschön geht an Michele Gauler, Denis Aberth, Raphael Müller, Dirk Willuhn und an alle Mitarbeiter bei IBM, die mich stets tatkräftig unterstützt haben. Ich habe mich sehr wohl gefühlt. Antonio Krüger und Andreas Butz danke ich für die Möglichkeit, an der Smart Graphics teilzunehmen. Ebenso danke ich den Organisatoren der Mensch & Computer, und der Computer Human Interaction dafür, dass ich die Konferenzen besuchen konnte. Alexander Gmyrek und Martin Kunzelnick danke ich für ihre große Hilfe und vor allem für das Händchenhalten bei allen Katastrophen. Allen Testpersonen und Korrektoren danke ich für ihre Zeit und Mühe. Abschließend danke ich meinen Eltern Elisabeth und Peter Kasper für die Ermöglichung meines Studiums. Ich widme diese Arbeit allen meinen Freunden. Stuttgart, 14. Oktober 2003

6

7 Inhaltsverzeichnis 1 Einleitung Er, Form und Usability Engineering Software-Ergonomie Motivation Struktur der Arbeit Grundlagen User Centered Design Richtlinien und Normen Aufgabe eines Usability Engineers User Centered Design und Software Engineering Redesign im Vergleich zum Neuentwurf Personalisierung Prototyping Low-Fidelity Prototyping High-Fidelity Prototypen Prototyping im Vergleich Wegwerfprototypen und iterative Entwicklung Usability Testing Testteilnehmer Testmethoden DB2 Performance Expert Architektur des DB2 Performance Experts Eigenschaften des DB2 Performance Experts Mittel der Navigation Einführung Informationsstruktur, Visualisierung und Interaktion Navigationselemente Menüs und Toolbars Tabs Links Breadcrumb Trail und Undo Landmarks Navigationskonzepte Bäume und Variationen Sitemaps

8 vi INHALTSVERZEICHNIS Suche Fenster und Drilldown Direkte Navigation Metaphern Andere Konzepte Eine Navigation für den DB2 Performance Expert Das Projekt Aufgabenstellung Projektablauf Unterschiede zu anderen Softwareprojekten Analyse Kundenanforderungen Elemente der Benutzungsoberfläche von DB2-Produkten Istzustand Anforderungen Design Einführung Prozess Designvorschläge Ausgewähltes Design Spezifikation System Overview Statistic Details Entwurf und Implementierung Entwurf Implementierung Zusammenfassung Entwurf und Implementierung Evaluierung Evaluierungsmethoden Beschreibung der Tests Auswertung Schlussfolgerungen und Ergebnisse Schlussfolgerungen Redesign von Benutzungsoberflächen Monitor Maps als Mittel der Visualisierung und Navigation Zusammenfassung der Ergebnisse Zukünftige Arbeit A Fragebögen 105 B Quantitative Auswertung 119 C Demo Film 127 D Glossar 129

9 Abbildungsverzeichnis 1.1 Zweidimensionale Softwareentwicklung Klassifikation der ergonomischen Standards [36] Zusammenhang der ISO 9241 [36] Zuordnung von Aktivitäten des Usability Engineers zu Rolle und Phase im UCD-Prozess Auswirkungen von Designfehlern Screenshot von DEMAIS (Designing Multimedia Applications with Interactive Storybords) Die drei Dimensionen von Benutzererfahrung und -vorwissen aus [31] Anzahl der gefundenen Usability Probleme ín Abhängigkeit von der Anzahl der Tester [30] Architektur des DB2 Performance Experts Quadranten der Komplexität von Anwendungen, bestimmt von Anzahl der Funktionen und Objekte Menüs und Toolbars in verschiedenen Anwendungen Tabs in verschiedenen Anwendungen Vom Baum zur Treemap MarketMap von smartmoney.com Titchenersche Täuschung - Fehleinschätzung der Größe durch den Kontext Übersicht DB2 Performance Expert DB2 Performance Expert: Multiplatform- und z/os-funktionen System Overview mit ausgewähltem Ordner (Balkendarstellung) Adobe Photoshop Navigator und Denim Radar View Erste Skizze zu System Overview (erstellt mit DEMAIS) Treemap für System Overview (erstellt mit PowerPoint) Navigationsrahmen (Powerpoint Prototyp) Papierprotoyp der Aufgabenliste Powerpoint Skizze der Treemap in Statistic Details Zeitachse in Statistic Details System Overview Monitor Map Mouseover in System Overview Doppelklick Auswahlfenster in System Overview Markierte und unmarkierte Systeme in System Overview

10 viii ABBILDUNGSVERZEICHNIS 4.15 Zoom auf z/os Statistic Details: Ursprüngliches Design und alternative Monitor Map Mouseover in der Monitor Map von Statistic Details Selektion in Statistic Details Treemap Prinzip, Venn-Diagramme, Slice & Dice Treemaps Testaufbau Beispiele aus den Fragebögen System Overview: Wie viele System können gleichzeitig beobachtet werden? Zufriedenheit der Benutzer mit den Monitor Maps im Prototypen Präferenzen für Monitor Maps in System Overview oder Statistic Details Alternativer Designvorschlag für Statistic Details, der ebenfalls eine Treemap und Halbtransparenz verwendet Mögliche unterstützende Monitor-Map-Funktionen - Bewertung der Tester Beispiele von Anwendungen im Komplexitätsfeld

11 Tabellenverzeichnis 2.1 Methoden des Prototyping im Vergleich Einfluss der Präsentationsgestaltung auf die Interaktionsgestaltung Schwächen im Istzustand von System Overview Schwächen im Istzustand von Statistic Details Zur Evaluierung des DB2 Performance Experts angewandte Methoden Testteilnehmer Usability Test Gruppen beim Usability Test mit Fragebögen Testteilnehmer Experten Walkthrough Ergebnistabelle der Heuristischen Evaluation anhand der Prinzipien von Tognazzini Fragen zu Sinn und Nützlichkeit der Monitor Maps (Gruppe 1 mit 5 Testern) Von Gruppe 1 bei Exploration entdeckte Interaktionsformen in System Overview

12

13 Kapitel 1 Einleitung In diesem Kapitel wird Software-Ergonomie als Bereich der Informatik, in den die Arbeit eingegliedert ist, vorgestellt. Außerdem wird die spezielle Themenstellung Redesign mit Mitteln der Navigation motiviert. Der letzte Abschnitt stellt Aufbau und Struktur der Arbeit vor. 1.1 Er, Form und Usability Engineering In der gesamten Diplomarbeit wird darauf verzichtet, geschlechtsneutrale oder gleichermaßen weibliche und männliche Formulierungen zu benutzen. Es wird stets die männliche Form er verwand, ohne dadurch diskriminieren zu wollen. Here s the deal. There was nothing imprecise or erroneous about what I had written. Instead, the problem was that I had been informal when the world I was addressing wanted me to be formal. Robert L. Glass in Communications of the ACM/Practical Programmer, Februar 2002 Das Redesign des DB2 Performance Experts von IBM ist eine praxisnahe Auseinandersetzung mit dem Thema der Diplomarbeit. Diese Vorgehensweise wird als Proof of Concept bezeichnet und bildet einen formal anerkannten Teil der Ausarbeitung. Er wird ergänzt durch eine wissenschaftliche Analyse der Ergebnisse. Anglizismen bleiben erhalten, wenn eine Übersetzung unangebracht erscheint, zum Beispiel bei Usability Engineering. 1.2 Software-Ergonomie Der Mensch mit seinen Fähigkeiten und Beschränkungen ist ein entscheidender Faktor für die erfolgreiche Anwendung von Informations- und Kommunikationstechnologien. [6]

14 2 Einleitung Funktionalität wird in heutigen Softwareprodukten vorausgesetzt. Die Zufriedenheit des Benutzers wird fast ausschließlich von der Benutzungsoberfläche erzeugt. Sie ist das Alleinstellungsmerkmal, welches den Kunden dazu bewegt, ein bestimmtes Produkt einem anderen vorzuziehen. Die visuelle Umsetzung einer Benutzungsoberfläche bestimmt, ob ein Produkt gefällt. Das Interaction Design, also wie Funktionen durch Interaktion mit der Benutzungsoberfläche ausgeführt werden, bestimmt, wie einfach das Produkt zu bedienen ist. Gefällt das Produkt und wird sofort verstanden, werden oft Abstriche in der Funktionalität hingenommen. Software-Ergonomie hat durch diese Entwicklung im Vorgehensmodell der meisten Firmen an Bedeutung gewonnen. In interdisziplinären Teams wird unabhängig von der eigentlichen Implementierung die positive Benutzererfahrung, die so genannte User Experience, entworfen. Der Begriff umfasst das visuelle Erscheinen, das interaktive Verhalten und die unterstützenden Eigenschaften einer Software. Software Ergonomie ist das, was die Informatik von einer olympischen höher-schneller-weiter Disziplin zurück in eine realistischere Welt bringt. Sie schlägt die Brücke zwischen Psychologie, Informatik und Design. Diese Spannung zwischen exakter Wissenschaft und angewandter Forschung wird in [2] beschrieben und relativiert. Softwareentwicklungsprojekte liegen nicht auf einer Linie zwischen technologiegetrieben und menschbezogen, sondern in einem zweidimensionalen Portfolio, wie in Abbildung 1.1 dargestellt. Abbildung 1.1: Zweidimensionale Softwareentwicklung Drei dieser Quadranten entsprechen anerkannten Arbeitsgebieten der Softwareentwicklung:

15 1.3 Motivation 3 (high, high)-projekte, die neue Technologien in enger Zusammenarbeit mit dem Kunden erstellen (z. B. MIT Multics, IBM System R) (high, low)-projekte, die Wissen einsetzen, um menschliche Probleme zu lösen (Anwendungsentwicklung, CHI) (low, high)-projekte, die neue Technologien um ihrer selbst willen entwickeln (viele Universitätsprojekte) All diese Arbeitsgebiete sind wichtig und keines ist von sich aus den anderen überlegen. Lediglich der vierte Quadrant (low, low) genügt dem Forschungsgedanken nicht. Dazu zählen Projekte, die lediglich zum Spaß entstehen. Das im Rahmen dieser Diplomarbeit durchgeführte Projekt (siehe Kapitel 4) gehört zu dem Quadranten (high, low). Dieser beschreibt eine Disziplin, die den Technologiefortschritt sucht und dabei von Nutzbarkeit und Nützlichkeit inspiriert wird. 1.3 Motivation Bei Anwendungsprogrammen wird während des Einsatzes häufig ein Redesign der Benutzungsoberfläche notwendig, da die Benutzer mit dem bestehenden Design nicht oder schlecht zurechtkommen. Durch ein neues Design soll die Lern- und Trainingszeit reduziert werden. Lernzeit und Trainingszeit sind Indikatoren für die Einfachheit der Bedienung (Ease of Use), die einen entscheidenden Wettbewerbsfaktor bildet [8]. Die Kunden des DB2 Performance Experts beklagen, dass die komplexe Benutzungsoberfläche eine sehr hohe Qualifikation erfordert. Es ist dem Benutzer unmöglich, alle Funktionen zu finden, weil er kein Gedankenmodell des DB2 Performance Experts erzeugen kann. Konkurrenzprodukte, die weitaus weniger Funktionen haben, aber dafür leicht zu verstehen sind, werden deswegen vorgezogen. Der DB2 Performance Expert genügt außerdem nicht den visuellen Ansprüchen der Kunden. Die einfachen Mittel der Darstellung wurden als DOS-like beschrieben. Eine weitere Schwierigkeit in der Bedienung des DB2 Performance Experts besteht darin, zwischen den vielen Fenstern zu navigieren. Aus diesen Beschwerden leitet sich die Notwendigkeit einer besseren Unterstützung bei der Aufgabenausführung, der Visualisierung der Zustände und der Daten ab. Das Redesign von Benutzungsoberflächen ist Aufgabe eines Usability-Engineers. Dieser ist ein Praktiker [37] und sieht sich einer Fülle von Regeln und Empfehlungen gegenüber, anhand deren er eine Verbesserung spezifizieren kann. In diesem Prozess der Neugestaltung bildet für den Usability Engineer Ideen haben einen wichtigen Teil, und dabei lässt sich der menschliche Geist selten in Kategorien drängen. Trotzdem macht es Sinn, sich die verschiedenen Aspekte zur Verbesserung des Ease of Use bewusst zu machen und gezielt nacheinander oder bei zeitlichen Einschränkungen auch nur einen davon zu bearbeiten. Diese verschiedenen Bereiche der softwareergonomischen Gestaltung nach Ziegler [6] sind: die Konzeptionelle Gestaltung, die sich mit Datenobjekten, Relationen und Operationen beschäftigt

16 4 Einleitung die Interaktionsgestaltung, die Nutzersichten und Navigationsstrukturen sowie Interaktionsobjekte und Eingabemöglichkeiten definiert und die Präsentationsgestaltung, welche visuelle Struktur, Layout, Anordnung sowie Begriffe, Symbole und Icons bearbeitet. In Anwendungen mit einer großen Anzahl komplexer Datenobjekte ist Interaktionsgestaltung besonders wichtig. Eine gute Navigation ist ein entscheidender Faktor bei der Bestimmung des Ease of Use der Benutzungsoberfläche. Der Aspekt der Navigation wurde für das Redesign des DB2 Performance Experts aus folgenden Gründen ausgewählt: Kundenanforderungen: konkrete Beschwerden darüber, dass die Navigation zwischen den Fenstern verwirrend ist [27] Die dem explosiven Anstieg von Größe und Komplexität des Datenbankumfeldes nicht gewachsene Baum-Navigation [8] Mangel an qualifizierten Datenbankadministratoren zur Beherrschung und Navigation der Benutzungsoberfläche [47] Hieraus lassen sich folgende Kriterien für die im DB2 Performance Expert zu verwendenden Navigationskonzepte ableiten: schneller Zugriff Unterstützung eines Gedankenmodells, in dem der Benutzer weiß, wo er sich befindet Führung des Benutzers (durch Events) Beherrschung der Datenmengen und der Komplexität intuitive Bedienbarkeit (unabhängig von speziellen Kenntnissen des Benutzers) 1.4 Struktur der Arbeit Das Kapitel 2 Grundlagen führt User Centered Design, Prototyping und Usability Testing ein und gibt eine Einführung in den DB2 Performance Expert. Das Kapitel 3 Navigationsmittel stellt Navigationselemente und Navigationskonzepte vor. Darauf aufbauend wird im Kapitel 4 die Entwicklung einer neuen Navigation für den DB2 Performance Expert beschrieben. Der Aufbau dieses Kapitels folgt dem Wasserfallmodell: Analyse, Design, Spezifikation, Entwurf, Implementierung und Einsatz bzw. Evaluierung. Die Entwicklung selbst war jedoch stark iterativ. Im letzten Kapitel 5 werden Ergebnisse und Schlussfolgerungen zusammengefasst und präsentiert. Die Diplomarbeit enthält außerdem verschiedene Anhänge, zum Beispiel einen Glossar.

17 Kapitel 2 Grundlagen Im diesem Kapitel wird in die Arbeitsgebiete der Diplomarbeit eingeführt. Neben einer allgemeinen Beschreibung von User Centered Design, Prototyping und Usability Testing wird der DB2 Performance Expert vorgestellt. 2.1 User Centered Design User Centered Design bezeichnet ein Vorgehen in der Softwareentwicklung, bei dem der Mensch im Mittelpunkt steht. Erkenntnisse der Software-Ergonomie, die ihrerseits aus den Disziplinen Anthropologie, Informatik, Linguistik, Arbeitswissenschaft, Psychologie und Soziologie gewonnen wurden, werden vom Usability Engineer berücksichtigt und verarbeitet. Software-Ergonomie bezeichnet technisch die GUI- und Dialoggestaltung. Für den Entwickler bedeutet sie eine Zeitersparnis, da er auf bereits evaluierte GUI-Elemente zurückgreifen kann. Dadurch werden Entwicklungsfehler vermieden. Durch User Centered Design werden die Arbeitsproduktivität des Benutzers sowie seine Autonomie und Kompetenz erhöht [36]. Insgesamt steigern diese Punkte die Akzeptanz des Produktes. Für das Unternehmen wird User Centered Design so zu einem entscheidenden Wettbewerbs- und Kostenfaktor. Im Folgenden werden Regeln und Normen, die Aufgaben eines Usability Engineers, die besondere Stellung eines Redesigns, der User Centered Design Prozess im Software Engineering sowie Personalisierung betrachtet Richtlinien und Normen Softwareentwicklung ist ein kreativer Prozess. Entwickler treffen hunderte von Gestaltungsentscheidungen in einem Umfeld, dessen technische und inhaltliche Anforderungen sich ändern. Deswegen haben Normen in diesem Bereich eher den Charakter von Richtlinien und Prinzipien, statt von festen Regeln. [36]

18 6 Grundlagen Klassifikation der ergonomischen Standards Bereich Prinzipien Richtlinien Spezielle Konventionen User Interface Design ISO ISO ISO 9241 Teile ISO Teile 2-3 Industrielle Richtlinien UI Desig & SW- Requirements Usability Kriterien Prozess ISO 9241 Teil 11 ISO TR Accessibility ISO Abbildung 2.1: Klassifikation der ergonomischen Standards [36] Interaktive Systeme Wintersemester 2002/2003 Folie 35 Fachhochschule Gelsenkirchen Fachbereich Informatik Dipl.-Inform. Christiane Rudlof Abbildung 2.1 zeigt einen Überblick bestehender Standards und ordnet sie in den Entwicklungsprozess ein. Meistzitierte Norm der software-ergonomischen Prinzipien zur Systemgestaltung ist der Teil 10 (Dialoggestaltung) von ISO Er wird durch diese sieben Schlagworte beschrieben: Aufgabenangemessenheit Erlernbarkeit Erwartungskonformität Selbstbeschreibungsfähigkeit Steuerbarkeit Individualisierbarkeit Fehlertoleranz Verschiedene Bücher (zum Beispiel [18]) erklären die Bedeutung dieser Begriffe sehr anschaulich. Abbildung 2.2 gibt an, welche Aspekte der Systemgestaltung von den anderen Teilen der ISO 9241 behandelt werden und wie sie aufeinander aufbauen. ISO mit Fokus auf multimediale Interfaces ist weniger bekannt. Diese Prinzipien adressieren vor allem die neuen Möglichkeiten in Benutzungsoberflächen. Der Einsatz verschiedener Medien wird darin sorgfältig hinterfragt. Wichtige Schlagworte dieser Norm sind: Kommunikationszielangemessenheit Explorierbarkeit

19 2.1 User Centered Design 7 Eignung für Wahrnehmung und Verstehen Motivationseignung Neben solchen Normen, den Industriestandards und den plattformspezifischen Styleguides von Sun [40], Windows [29] oder Apple [1], ist ein in den USA sogar gesetzlich festgelegter (ADA-Gesetz) Aspekt sehr wichtig: Accessibility bezeichnet die Zugänglichmachung von Software und Webinhalten für Menschen mit Behinderungen. Empfehlungen, wie die daraus entstehenden Anforderungen eingehalten werden können, sind in ISO TR enthalten. In Abschnitt wird die heuristische Evaluierung besprochen. Ihr liegen Prinzipien zugrunde, die den vorgestellten Standards ähneln, aber auch ergänzen. Abbildung 2.2: Zusammenhang der ISO 9241 [36] Aufgabe eines Usability Engineers Aufgabe des Usability Engineers ist es, die positive Erfahrung (User Experience) eines Benutzers in der Interaktion mit einer Software zu entwerfen. In großen Unternehmen wie IBM wurde der Nutzen von User Centered Design (UCD) erkannt, und es gibt eigens dafür zuständige Abteilungen bzw. Mitarbeiter. Die Berufsbezeichnung Usability Engineer wird oft noch verfeinert in Visual Designer oder Interaction Designer. Die Mitarbeiter rekrutieren sich aus den verschiedensten Disziplinen, zum Beispiel der Psychologie, dem Design und der Informatik. Ein Usability Engineer ist in der frühen Entstehungsphase eines Produktes dafür zuständig, die Benutzungsoberfläche zu gestalten. Dazu sind folgende Aktivitäten notwendig: Identifizierung der Zielgruppe Competitor Analysis

20 8 Grundlagen Aufgabenanalyse Entwicklung eines Prototypen Evaluierung verschiedener Konzepte Abbildung 2.3 zeigt die Aktivitäten in einer durch die Rolle des Usability Engineers und die Phase des UCD-Prozesses bestimmten Matrix. Die Rollen im UCD-Team werden aufgrund der besonderen Vorbildung vergeben. Psychologen zum Beispiel kümmern sich typischerweise um die Evaluierung. Die Phasen des UCD-Prozesses werden im nächsten Abschnitt genauer erläutert. Abbildung 2.3: Zuordnung von Aktivitäten des Usability Engineers zu Rolle und Phase im UCD-Prozess User Centered Design und Software Engineering Heute folgt professionelle Softwareentwicklung Prozessen, die durch Erkenntnisse des Software Engineering geprägt wurden. Das phasenbasierte Wasserfallmodell oder iterative Modelle nach dem Vorbild des Spiralmodells von Boehm sind Grundlage für die bestehenden Vorgehensmodelle, wie zum Beispiel den Unified Software Development Process [21]. Die meisten Vorgehensmodelle gehen wenig auf die Gestaltung von Benutzungsoberflächen ein [4]. Durch die sich verschiebenden Anforderungen an Software, nämlich, dass Benutzbarkeit essenziell wichtig ist und Funktionalität selbstverständlich vorausgesetzt wird (vgl. Abschnitt 1.3), wurden Prozesse entwickelt, die das Gestalten von benutzbarer Software in den Vordergrund stellen. Vorgehensmodelle, die sich mit der Gestaltung von Benutzungsoberflächen beschäftigen haben viele Namen; bei der IBM wird der in [35] geprägte Begriff des User Centered Design (UCD) verwendet. Es handelt sich dabei um ein Sammelsurium

21 2.1 User Centered Design 9 von Methoden und Techniken aus unterschiedlichsten Fachbereichen, die mehr oder weniger eng verknüpft werden. Die sechs Phasen von UCD aus Abbildung 2.3 (beschrieben in [46]) werden im Folgenden kurz erklärt: Business Opportunity Der Anstoß für ein Projekt erfolgt, wenn z. B. eine Marktchance erkannt wird, die zu den gesetzten Zielen eines Unternehmens passt. Dann müssen konkrete Ziele definiert und ein Plan erstellt werden. Übernommen werden diese Aufgaben vom Marketing-Team und der Projektleitung des UCD-Teams. Understanding Users In dieser Phase beginnt die Arbeit des UCD-Teams. Es werden die Anforderungen der Zielgruppe herausgearbeitet und in Einklang mit den Vorgaben des Marketing gebracht. Die Richtlinien für das Design werden festgelegt und Use-Cases spezifiziert. Initial Design Ergebnis dieser Phase ist ein Konzept zur Gestaltung der Benutzererfahrung (User Experience). Dieses wird zunächst in Low-Fidelity Prototypen umgesetzt und mithilfe von Benutzern evaluiert. Es entsteht daraus ein detailliertes Design des neuen Produktes. Development In dieser Phase entsteht die Spezifikation. Es wird meist anhand eines ausgereiften Prototypen demonstriert, was das neue Produkt können soll. Jede Designentscheidung ist hierbei dokumentiert und durch Ergebnisse der Evaluierung bekräftigt. Deployment Nach der Implementierung der von UCD vorgeschlagenen Lösung werden abermals Studien durchgeführt. Hieraus werden Anforderungen für die nächste Version des Produktes festgelegt. Life Cycle In der Softwareentwicklung entspricht dies der Wartungsphase. Fortlaufend soll während der Existenz eines Produktes das Feedback der Benutzer gesammelt werden, sodass in darauf folgenden Projekten darauf eingegangen werden kann. Eine Fülle von Information zu dem Thema ist online verfügbar [20]. Usability Engineering (UE) erweitert UCD zu einem strukturierteren Prozess und verbessert dessen Integration in den Softwareentwicklungsprozess. Es beinhaltet Rollenbeschreibungen, Definitionen von Aktivitäten und Arbeitsergebnissen (Artefakten), Empfehlungen für Methoden und geeignete Maßsysteme zur Feststellung des Erfolges. Objects, Views and Interaction Design (OVID) [5] ist eine formale Methode zum Entwurf der User Experience und wird im Rahmen von UE angewandt.

22 10 Grundlagen Redesign im Vergleich zum Neuentwurf Das Vorgehen beim Redesign des Produktes folgt idealerweise dem im vorherigen Abschnitt vorgestellten UCD-Prozess. Im Vergleich zum Neuentwurf einer Benutzungsoberfläche gibt es folgende Unterschiede: Erfahrungen mit dem jetzigen Produktdesign liegen vor die Zielgruppe ist bekannt; es kann eventuell auf diese Benutzer (als Tester) zurückgegriffen werden altes Design darf nicht völlig verworfen werden wenn der Benutzer alles neu lernen muss, wird er vor den Kopf gestoßen möglicherweise werden nicht nur Nachteile der alten Version ausgemerzt, sondern es gehen auch deren Vorteile verloren (vergleiche Abbildung 2.4) neues Design sollte eine (bessere) Alternative sein - dies stellt zusätzliche Anforderungen an die Navigation vorhandene Architektur sollte im Hinblick auf den Implementierungsaufwand ausgenutzt werden; das ist nicht immer möglich: Ein Paradigmenwechsel erfordert oft sehr viel Aufwand, zum Beispiel wenn von einem objektorientierten Ansatz zu einem taskbasierten oder kognitiven Modellen gewechselt wird. Abbildung 2.4: Auswirkungen von Designfehlern Personalisierung Personalisierung (Customization) wird an dieser Stelle besonders hervorgehoben, da es sich dabei um den Schlüssel zum Erfolg von Benutzungsoberflächen handeln kann [22]. Der Begriff bezeichnet sowohl sich automatisch an den Benutzer anpassende, als auch aktiv vom Benutzer angepasste Benutzungsoberflächen.

23 2.2 Prototyping 11 Die Toolbar von Microsoft Word, aus der mehrmals nicht benutzte Funktionen verschwinden, ist ein Beispiel für automatische Personalisierung. Eine Erfolgsgeschichte der aktiven Personalisierung im Web ist MyYahoo! Die dabei gewonnenen Erfahrungen wurden in [26] beschrieben: Die meisten Benutzer werden die Personalisierung niemals in Anspruch nehmen. Deswegen ist es essenziell wichtig, eine gute Default-Konfiguration anzubieten. Der Personalisierung sollen keine künstlichen Grenzen gesetzt sein. Zum Beispiel darf man bei einer Linkliste nicht davon ausgehen, dass sie weniger als 1000 Einträge hat. Personalisierung ist dem Menschen nicht aus der Welt außerhalb des Computers vertraut und muss deswegen besonders einfach zu verstehen und zu bedienen sein. Bei der individuellen Gestaltung von Benutzungsoberflächen spielen viele Faktoren eine Rolle. Neben Alter und Kulturkreis des Benutzers könnte zum Beispiel auch das Geschlecht in Zukunft mehr Beachtung finden. Eine von Intel in Auftrag gegebene Studie [23] stellte im Mai dieses Jahres fest, dass bei Frauen die Fähigkeit, mehrere Dinge gleichzeitig zu tun - das so genannte Multitasking - stärker ausgeprägt ist. 2.2 Prototyping Der Abschnitt 2.1 hat Prototyping als Teil des UCD-Prozesses bereits eingeführt. An dieser Stelle wird nun High-Fidelity- und Low-Fidelity-Prototyping besprochen und gegenübergestellt Low-Fidelity Prototyping Als Low-Fidelity Prototyping bezeichnet man das Erstellen von Modellen des späteren Produktes mit einfachen Mitteln, zum Beispiel mit Skizzen. Mithilfe dieser Prototypen wird das Aussehen spezifiziert und die geplante Funktionalität definiert. Das gemeinsame Bild ist eine Diskussionsgrundlage für Entwickler, Analysten und Benutzer. Papierprototypen Prototypen, entstanden mit Papier und Stiften, sind die einfachste und effektivste Form des Prototyping [45]. Sie werden folgendermaßen erstellt: Zuerst wird entschieden, welche Aufgaben der Benutzer erfüllen soll. Dann werden Screenshots oder handskizzierte Entwürfe von den Fenstern, Menüs, Dialogboxen, Popups, etc. angefertigt.

24 12 Grundlagen Der Prototyp wird dann mithilfe einer vorgegebenen Aufgabenstellung auf seine Benutzbarkeit hin getestet. Der Benutzer verwendet seinen Finger als Cursor; Texteingaben macht er handschriftlich. Der Testleiter simuliert die Aktionen der Software. Im Verlauf des Tests werden Benutzbarkeitsprobleme erkannt und notiert. Lösungen werden diskutiert und fließen als Optimierungen in den Papierprototypen ein. Diese Schritte können beliebig oft wiederholt werden. Idealerweise werden Papierprototypen in einer mehrstündigen Sitzung von einem interdisziplinären Team erstellt, evaluiert und nochmals verbessert. Programmierkenntnisse sind nicht erforderlich. Diverse Materialien, z. B. farbiges Papier, klebende Zettel und Transparentfolien erweitern die Möglichkeiten von Papier und Stift.[42] Mit Papierprototypen werden Benutzbarkeitsprobleme frühzeitig im Designprozess erkannt und vor der Implementierung gelöst. Sketchingwerkzeuge wie Denim [25] und DEMAIS [3] wurden entwickelt, um die Vorteile von Papierprototyping um den Vorteil der elektronischen Erfassung zu erweitern. Über ein Grafiktablett können Freihandskizzen angefertigt und mit einer Funktion wie Mouseover oder Mausklick verknüpft werden. Es entsteht ein interaktiver Prototyp. Abbildung 2.5: Screenshot von DEMAIS (Designing Multimedia Applications with Interactive Storybords)

25 2.2 Prototyping 13 Abbildung 2.5 zeigt einen Screenshot von DEMAIS. Das Werkzeug erlaubt es, automatische Abläufe zu spezifizieren, mit einem Ton zu hinterlegen und abzuspielen. Dadurch entstehen komplette Geschichten, so genannte Storyboards, welche die Funktionalität erklären. Der Vorteil von DEMAIS gegenüber Denim ist, dass neben den im Werkzeug erstellten Skizzen auch andere Medien, wie zum Beispiel Bilder, in den Prototypen eingebunden werden können. Durch das Erzählen einer Geschichte (Storytelling) werden große Mengen an Informationen über ein Design effektiv und intuitiv zugänglich gemacht [14]: Ein Bild sagt mehr als tausend Worte.. Filme sind ein gutes Mittel dafür, jedoch sehr aufwändig. Mit weniger Aufwand verbunden sind Präsentationen, zum Beispiel in MS PowerPoint. Die Geschichte wird dabei vom Vortragenden anhand der Bilder erzählt. PowerPoint hat den Vorteil, dass es leichter zu bedienen ist als die meisten Grafikprogramme. Es bietet Farben, Formen und eine einfache Animation. Außerdem ist die Software auf den meisten Windows-Rechnern verfügbar und allgemein bekannt. Untersuchungen von Nielsen [31] haben gezeigt, dass mit Papierprototypen genauso viele Usability-Fehler aufgedeckt werden können wie mit aufwändigeren Prototypen High-Fidelity Prototypen Zu den High-Fidelity Prototypen gehören neben dem im vorherigen Abschnitt erwähnten Film Prototypen, die mithilfe von HTML und JavaScript erstellt wurden, sowie Prototypen, die tatsächlich programmiert sind. Der zeitliche Aufwand, das benötigte Know-How und daraus resultierend die Kosten sind um ein Vielfaches höher als bei Low-Fidelity Prototypen. High-Fidelity Prototypen enthalten mehr Funktionalität und das Aussehen von HTML/JavaScript Prototypen und programmierten Varianten ähnelt stark dem des fertigen Produktes. Filme eignen sich in den frühen Phasen des Designs, um eine Vision vorzustellen und einen Auftrag zu akquirieren. Über diesen Prototypen wird wegen des hohen Aufwands meist nicht iteriert. Die folgenden Abschnitte beschreiben Vor- und Nachteile von HTML/JavaScript und programmierten Prototypen. HTML/JavaScript HTML und JavaScript werden zum Prototyping häufig eingesetzt, weil sie von vielen Designern beherrscht werden. Es lassen sich mit dieser Technik interaktive Prototypen gestalten, und speziell im Hinblick auf das Visual Design ist es sehr einfach, diese zu verändern. HTML/JavaScript Prototypen können im Aussehen sehr stark an das tatsächliche Produkt angenähert werden. Nachteil ist, dass bei dem Design die Möglichkeiten der Programmiersprache meist nicht bedacht werden, sodass es in der Implementierung oft zu Abstrichen kommt.

26 14 Grundlagen Programmierung Zur Programmierung von Oberflächenprototypen werden häufig einfache Programmiersprachen wie Visual Basic eingesetzt. Der Nachteil davon ist, dass der Prototyp im Aussehen nicht exakt dem späteren Produkt entspricht. Der Einsatz der gleichen Programmiersprache in Prototyp und Produkt ist ein entscheidender Vorteil gegenüber anderen Arten des Prototypings. Nicht nur, dass im Prototyp die exakte Oberfläche des Produktes gezeigt werden kann, es wird auch sichergestellt, dass die eingesetzten Oberflächenelemente in dieser Form benutzt werden können. Es gibt in vielen Entwicklungsumgebungen Werkzeuge, mit deren Hilfe Oberflächen durch Drag&Drop zusammengefügt werden können. Deren Möglichkeiten sind jedoch beschränkt, sodass sie meist nicht ausreichen. Ein großer Nachteil der Programmierung ist, dass der Benutzer diese gut beherrschen muss. Verfügt er nur über geringe Programmierkenntnisse, kann er nicht alle Möglichkeiten ausnutzen. Gute Programmierer im Gegenzug lassen sich in der Designphase häufig von den ihnen bekannten Möglichkeiten leiten und vernachlässigen das gestalterische Potenzial. Programmierten Prototypen sollten deswegen unbedingt Low-Fidelity Prototypen vorausgehen. Der Vorteil der Programmierung liegt darin, dass Interaktion viel einfacher zu realisieren ist. Ein weit entwickelter Prototyp kann für Tests verwendet werden, bei denen die Interaktion des Benutzers ausgewertet wird, z. B. durch Logging Tools. Eine Gefahr des Prototyping durch Programmierung ist, dass der meist unsaubere, nicht in eine Architektur eingefügte Code nicht weggeworfen, sondern zu einem Teil des Produktes wird. Alan Cooper bezeichnet das als Narbengewebe [7] Prototyping im Vergleich Tabelle 2.1 gibt einen Überblick über die Methoden des Prototyping, die in den vorhergehenden Abschnitten beschrieben wurden. Filme als eine Form des Prototyping werden dabei nicht betrachtet. Unter Sketchingtools werden Denim und DEMAIS zusammengefasst. Außer für Papierprototypen wird für alle Methoden ein Computer mit Monitor, Tastatur und Maus vorausgesetzt. Hardware bezeichnet zusätzlich benötigte Materialien. Installationsaufwand bezeichnet die zusätzlich auf dem Computer zu installierende Software, beispielsweise wird für DEMAIS das Java Media Framework benötigt. Performance bezeichnet die Performance des Werkzeugs und des entstehenden Prototypen. Fehler bezeichnet nicht Designfehler, sondern so genannte Bugs im Prototypen, die durch die Technik erzeugt wurden Wegwerfprototypen und iterative Entwicklung In iterativen Vorgehensmodellen wird ein Kernsystem kontinuierlich zu dem Endprodukt weiterentwickelt, indem nach und nach die gewünschte Funktionalität implementiert wird. Dieses Kernsystem kann beispielsweise ein Oberflächenprototyp sein, in dem alle Funktionen (z. B. durch Menüs) schon vorgesehen sind.

27 2.2 Prototyping 15 zusätzliche Hardware Programmierung Grafiktablett HTML/ JavaScript keine keine keine Papierprototypen (Drucker,) Papier, Stifte Sketchingtools Präsentationstools Software/ Lizenzen keine frei MS Power- Point z. B. Dreamweaver z. B. JBuilder z. B. Installationsaufwand keiner mittel gering gering mittelhoch Performance gut mangelhaft gut gut gut Fehler keine manchmal selten häufig häufig Lernaufwand sehr gering mittelhoch mittel hoch sehr hoch Zeitaufwand gering mittel mittel mittelhoch hoch Farbe ja nein ja ja ja Änderbarkeit sehr einfach einfach einfach z. T. einfach z. T. einfach Tabelle 2.1: Methoden des Prototyping im Vergleich Als Wegwerfprototyp bezeichnet man einen Prototyp, dessen Code nicht Bestandteil des Endproduktes ist. Er wird lediglich zu Analyse- und Spezifikationszwecken erstellt. Die in Abschnitt vorgestellten Methoden produzieren Wegwerfprototypen. Vorteile von Wegwerfprototypen: einfach und schnell zu erstellen (geringe Kosten) nicht durch Technologie oder Architektur eingeschränkt Nachteile von Wegwerfprototypen: vom Produkt abweichendes Aussehen doppelter Aufwand: Realisierungsschwierigkeiten treten zweimal auf schlechte Qualität des Endproduktes, wenn versucht wird, Teile des Prototypen darin zu verwenden Ein iteratives Vorgehen mit High-Fidelity Prototypen, deren Code in das Endprodukt einfließt, macht deswegen nur Sinn, wenn ein Produkt oder Teile davon völlig neu entwickelt werden. Ein solcher Prototyp erfordert sehr viel mehr Aufwand als ein Wegwerfprototyp.

28 16 Grundlagen 2.3 Usability Testing Im Software Engineering bildet der Test eine wichtige Phase im Lebenszyklus einer Software. Dabei wird die Implementierung gegen die Spezifikation geprüft. Usability Tests prüfen die Konsistenz von Spezifikation und Mensch, bzw. dessen Eigenschaften und Erwartungen Testteilnehmer Testteilnehmer können in Testleiter und Tester unterschieden werden. Der Testleiter ist für den Ablauf des Tests verantwortlich, führt Messungen durch und notiert Beobachtungen. Manche Tests erfordern, dass diese Aufgaben von einem Team von Testleitern übernommen werden, zum Beispiel gibt es häufig einen Protokollanten und einen Ansprechpartner für den Tester. Als Tester bezeichnet man die Personen, deren spontanes und bewusstes Feedback ausgewertet wird. Testleiter werden meist aus dem Designteam rekrutiert. Tester sind Personen aus unterschiedlichen Bereichen. Es kann sich um Entwickler, Endbenutzer oder auch software-ergonomisch vorgebildete Personen handeln. Dies ist abhängig von der Testmethode und dem Ziel des Testes (vgl. Abschnitt 2.3.2). Bei umfangreichen Usability Tests werden verschiedene Testergruppen unterschieden. Gruppierungskriterien sind dabei zum Beispiel Alter, Geschlecht, Vorwissen, etc. Vor allem das Vorwissen der Benutzer spielt eine wichtige Rolle [31] bei der Evaluierung. Abbildung 2.6 beschreibt die drei wichtigsten Dimensionen dieses Faktors. Wissen über die Domäne des Testobjektes Experte bei der Benutzung des Testobjektes wenig Erfahrung mit Computern erste Benutzung des Testobjektes kein Wissen über die Domäne des Testobjektes viel Erfahrung mit Computern (Power-User) Abbildung 2.6: Die drei Dimensionen von Benutzererfahrung und -vorwissen aus [31]

29 2.3 Usability Testing 17 In einer iterativen Entwicklung werden dieselben Tester häufig mehrfach eingesetzt, dabei verändert sich ihr Vorwissen. Man bezeichnet dieses Vorgehen als partizipative Entwicklung. Die Anzahl der Testpersonen bestimmt die statistische Signifikanz der Auswertung. Jedoch können bereits 5 Tester 75 % der Usability Probleme in einer Benutzungsoberfläche finden (vgl. Abbildung 2.7). Abbildung 2.7: Anzahl der gefundenen Usability Probleme ín Abhängigkeit von der Anzahl der Tester [30] Testmethoden Testmethoden des Usability Engineering können nach Art der Tester klassifiziert werden. Der folgende Abschnitt fasst unter dem Namen Benutzertests Tests mit an der Entwicklung unbeteiligten Personen zusammen. Idealerweise handelt es sich dabei um die Endbenutzer des Testobjektes. Die im darauf folgenden Abschnitt beschriebene Heuristische Evaluierung ist ein Repräsentant von so genannten Walkthroughs, die von Usability Experten durchgeführt werden. Diese können auch Teil des Designteams sein. In einem Walkthrough bewertet eine Person das Testobjekt unter Berücksichtigung ihres speziellen Wissens bzw. anhand von anerkannten Kriterien. Diese Form des Tests wird auch als Inspektion bezeichnet. Benutzertests Ad-Hoc Tests Die einfachste Form von Tests mit Endbenutzern sind Ad-Hoc Tests. Dabei werden dem Tester in einem informellen Interview Fragen zum Testobjekt gestellt. Der

30 18 Grundlagen Testleiter unterstützt seine Fragen mit Demonstrationen, Skizzen und Erklärungen. Das Vorgehen ist nicht standardisiert, und es erfolgt keine quantitative Auswertung der Ergebnisse. Usability Tests Mit diesem Namen sind in der Diplomarbeit standardisierte Testabläufe mit einer Reihe von Testern gemeint. Sie haben zum Ziel die subjektive Zufriedenstellung der Benutzer zu ermitteln und die Ursachen von mangelnder Zufriedenstellung festzustellen. Der Test wird mittels Fragebögen und Aufgaben strukturiert. Performance Tests Studien, welche die Effektivität des Testobjekts und die Effizienz der Tester quantitativ erheben, werden als Performance Tests bezeichnet. Mittel zur Erhebung sind dabei Videoaufnahmen und Logging Werkzeuge. Diese Testform wird häufig zum Vergleich verschiedener Testobjekte eingesetzt, zum Beispiel bei der Analyse der Konkurrenzprodukte (Competitor Analysis). Außerdem dient sie oft der abschließenden Evaluierung einer Benutzungsoberfläche [31]. Bei dem Testobjekt handelt es sich immer um einen High-Fidelity Prototypen oder ein bestehendes Produkt. Die Performance wird gemessen, indem eine Testergruppe vordefinierte Aufgaben ausführt. Dabei werden die Zeit und die Anzahl der Bedienungsfehler erfasst. Thinking Aloud Diese Testmethode wird häufig in Kombination mit anderen Testmethoden angewandt. Sie besteht darin, dass der Benutzer während er das Testobjekt bedient, seine Gedanken verbalisiert. Der Benutzer beschreibt mit seinen eigenen Worten, was er tun möchte und was er sich davon erwartet. Dann führt er die Aktion aus und beschreibt, wie die Ausführung und die Reaktion des Systems auf ihn gewirkt haben. Dadurch wird das Gedankenmodell des Testers für den Testleiter transparent. Ein weiterer Vorteil ist, dass Kommentare zu vielen verschiedenen Aspekten gemacht werden, zum Beispiel auch zu einem Icon, das nicht gefällt. Solche Störfaktoren der User Experience werden von anderen Testmethoden kaum entdeckt. Mehrere in [31] zitierte Studien zeigen, dass es nicht sinnvoll ist, durch diese Methode quantitative Daten zu erheben. Zum Beispiel besagt eine Studie, dass Benutzer, die ihre Aufgaben erfüllten und dabei laut dachten 80% weniger Fehler machten als diejenigen Benutzer, die leise arbeiteten. Die Geschwindigkeit der Ausführung wird von Thinking Aloud in zwei Richtungen beeinflusst: Einige sonst automatische Abläufe werden langsamer durchgeführt, weil sie erst verbalisiert werden müssen; im Gegenzug werden die gestellten Aufgaben schneller durchgeführt, weil die Anweisungen sich dem Benutzer durch das laute Denken nochmals einprägen. Der Benutzer korrigiert beim Verbalisieren häufig selbst Fehler in seinem Gedankenmodell. Heuristische Evaluierung Heuristische Evaluierung ist eine Methode, um Usability Probleme in einer Benutzungsoberfläche aufzudecken. Jakob Nielsen hat die Methode in vielen Publikationen

31 2.3 Usability Testing 19 beschrieben. Vorliegende Zusammenfassung beruht hauptsächlich auf [30] und [31]. Die Methode besteht darin, dass eine kleine Anzahl von Testern die Benutzungsoberfläche untersucht und die Einhaltung der Heuristiken prüft. Heuristiken sind anerkannte Prinzipien der Oberflächengestaltung. Empfohlen wird eine Anzahl von drei bis fünf Testern. Jeder Tester prüft die Benutzungsoberfläche allein. Erst danach werden die individuellen Ergebnisse in einem Gespräch mit allen Testern aggregiert und entweder in einem schriftlichen Bericht festgehalten oder einem Beobachter geschildert, während die Benutzungsoberfläche Schritt für Schritt durchlaufen wird. Dem Beobachter ist es erlaubt, die Tester während ihrer Beurteilung und während der Konsensfindung zu unterstützen. Die Anwesenheit eines Beobachters erhöht zwar zunächst den Aufwand, jedoch sprechen eine vereinfachte Auswertung und insgesamt bessere Ergebnisse für seinen Einsatz. Im Gegensatz zu Benutzertests mit Fragebögen, bei denen der Beobachter (Testleiter) die Reaktionen der Tester interpretieren muss, liegt die Verantwortung im Falle der heuristischen Analyse beim Tester. Weiterer Unterschied zu Benutzertests ist, dass der Beobachter willens ist, Fragen des Testers während dem Test zu beantworten. Eine heuristische Evaluierung dauert normalerweise ein bis zwei Stunden. Umfangreiche Testobjekte erfordern möglicherweise mehr Zeit. In dem Fall ist es besser, den Test auf mehrere kleine Tests aufzuteilen. Während des Tests durchläuft der Tester die Benutzungsoberfläche mehrere Male und beurteilt ihre Elemente anhand der Liste der Heuristiken. Für Benutzungsoberflächen, die Domänenwissen voraussetzen, ist es sinnvoll, den Testern ein Nutzungsszenario zu geben, anhand dessen sie den Test durchführen können. Benutzungsoberflächen, die der breiten Masse von Benutzern zugänglich sein sollen (so genannte walk-up-and-use Interfaces) können ohne weitere Unterstützung seitens des Beobachters evaluiert werden. Ergebnis der heuristischen Evaluierung ist eine Liste von Usability Problemen mit Referenzen auf die Prinzipien, die dabei verletzt wurden. Es entsteht keine Anweisung, wie die Benutzungsoberfläche verbessert werden kann, jedoch fällt es durch die angegebenen Begründungen leicht, in der nächsten Iteration ein besseres Ergebnis zu entwerfen. Obwohl die heuristische Evaluierung als Discount Usability Method bezeichnet wird, haben Studien gezeigt, dass sie sehr effizient ist. Es folgen zwei Stichwortlisten von Heuristiken von Nielsen und Tognazzini. Diese dienen nicht nur der Heuristischen Evaluierung. Werden sie beim Design einer Benutzungsoberfläche berücksichtigt, entstehen bedienbarere Oberflächen mit weniger Usability Problemen.

32 20 Grundlagen Nielsen: Zehn Usability Heuristiken [32] 1. Sichtbarkeit des Systemzustands - zu jeder Zeit, in angemessener Form, in vertretbarer Antwortzeit 2. Entsprechung von System und realer Welt - natürliche und logische Ordnung von Worten und Sätzen, die dem Benutzer vertraut sind 3. Freiheit und Kontrolle des Benutzers - zum Beispiel durch Undo und Redo Funktionalität 4. Konsistenz und Einhaltung von Standards 5. Fehlervermeidung vor Fehlerbehandlung 6. Erkennen statt Erinnern - benötigte Information anzeigen oder leicht zugänglich machen 7. Flexibilität und Effizienz der Bedienung - Tastatur-Shortcuts, um den erfahrenen Benutzer zu unterstützen 8. Ästhetisches und minimalistisches Design - keine irrelevante oder selten benötigte Information anzeigen 9. Hilfe zum Erkennen, Beurteilen und Bearbeiten von Fehlern - natürlichsprachliche Fehlerbeschreibung und konstruktive Lösungsvorschläge 10. Hilfe und Dokumentation - leicht zu durchsuchen, auf Aufgaben des Benutzers zugeschnitten, schrittweise Anleitung und nicht zu lang Tognazzini : First Principles [41] Antizipation der Wünsche und Bedürfnisse des Benuters Autonomie des Benutzers, ohne ihn alleinzulassen - Statusinformationen stets gut sichtbar und aktuell halten Farbenblindheit bedenken und sekundäre Informationsrepräsentation verfügbar machen Konsistenz innerhalb des Systems, der Produktfamilie und Plattform Defaults Effizienz des Benutzers und nicht des Systems berücksichtigen - nur weil das System arbeitet, darf dem Benutzer nicht die Möglichkeit genommen werden, weiterzuarbeiten Explorierbare Benutzungsoberflächen mit markierten Wegen und umkehrbaren Aktionen (Undo) Fitt s Law beachten

33 2.4 DB2 Performance Expert 21 Menschengerechte Bedienobjekte sind nicht notwendigerweise Objekte eines objektorientierten Systems Verringerung von Latenzzeiten durch Anpassung der Reaktionszeiten oder Feedback wie Sanduhr und Fortschrittsbalken Erlernbarkeit Benutzung von Metaphern Schutz der Arbeit des Benutzers - Vermeidung von jeglichem Verlust, gleich aus welchen Gründen Lesbarkeit - Beachtung physischer Anforderungen an Kontrast und Größe Verfolgen des Benutzers - woher er kommt, wohin er geht Sichtbare Navigation Andere Testmethoden Die Psychologie kennt eine große Anzahl weiterer Testmethoden, beispielsweise Methoden, bei denen Augenbewegungen analysiert werden. Der Aufwand für die Durchführung und die für solche Tests erforderliche Qualifikation sind sehr hoch. User Feedback, Logging während der alltäglichen Benutzung, Fokusgruppen und allgemeine Fragebögen sind weitere von Nielsen [31] beschriebene Testmethoden. Alle setzen eine hohe Anzahl an Testern voraus. 2.4 DB2 Performance Expert Der DB2 Performance Expert gehört zu den Data Management Werkzeugen von IBM. Über eine einzige Benutzungsoberfläche können damit viele DB2 Systeme gleichzeitig beobachtet und analysiert werden. Hauptziel des Produktes ist es, das Performance Management von DB2 Systemen zu vereinfachen. Das Werkzeug erlaubt es, Anwendungen, System Statistiken und System Parameter zu beobachten. Es unterstützt den Benutzer dabei, für die Performance kritische Punkte in Systemen zu erkennen. Außerdem werden Empfehlungen zur Verbesserung der Performance von System und Anwendung gegeben [39]. Am praktischen Beispiel des DB2 Performance Experts wird in der Diplomarbeit gezeigt, wie eine Benutzungsoberfläche durch Mittel der Navigation verbessert werden kann. Das Redesign des DB2 Performance Expert Clients (siehe Abbildung 2.8) ist dringend erforderlich, da die Kunden des Produktes sich massiv über die Bedienbarkeit der Benutzungsoberfläche beschwert haben (vgl. Abschnitt 1.3).

34 22 Grundlagen Abbildung 2.8: Architektur des DB2 Performance Experts Architektur des DB2 Performance Experts Abbildung 2.8 zeigt die Architektur des DB2 Performance Experts. Eine Installation besteht aus einem oder mehreren Servern, einem Client und mehreren angeschlossenen DB2 Datenbanken. Der DB2 Performance Expert ist für DB2 Datenbanken auf verschiedenen Plattformen verfügbar: OS/390, z/os, HP, AIX, Sun Solaris, Windows und Linux. Der DB2 Performance Expert Server sammelt und verwaltet Snapshot-Daten. Als Snapshot-Daten bezeichnet man Momentaufnahmen eines Systems. Man kann darin erkennen, was zu einem bestimmten Zeitpunkt passiert. Auf Basis dieser gespeicherten Daten (History-Data) können detaillierte Analysen erfolgen, z. B. für eine Kapazitätsplanung. In der Abbildung sind zwei End-Benutzerschnittstellen dargestellt. Bei ISPF panel handelt es sich um eine textuelle Benutzungsoberfläche, mit der nur Server und Datenbanken auf z/os angesprochen werden können. Der darunter dargestellte Performance Expert Client ist ein in Java geschriebenes GUI. Die Benutzungsoberfläche vereinfacht die Aufgaben von Datenbankadministratoren, indem sie ein allgemeines Werkzeugset über alle Plattformen anbietet.

35 2.4 DB2 Performance Expert Eigenschaften des DB2 Performance Experts Folgende Aufzählung beschreibt, wozu man den DB2 Performance Expert benutzen kann. Der DB2 Performance Expert ist ein zentraler Kontrollpunkt, an dem alle DB2 Systeme verwaltet und überwacht werden können. Er ermöglicht Echtzeit-Überwachung von mehreren DB2 Systemen parallel, unabhängig davon, wo sich die Systeme befinden. Er zeigt statistische Werte und Systemparameter an. Er liefert Details über Threads, z. B. auch darüber, ob sich diese gegenseitig behindern (Locking Conflicts). Er markiert Werte, die Grenzen (Thresholds) überschritten haben. Er bietet die Möglichkeit, sowohl die laufende Aktivität, als auch vergangene Daten zu betrachten und zu analysieren. Im Kapitel 4 Abschnitt 4.2 wird die Benutzungsoberfläche des DB2 Performance Experts (der DB2 Performance Expert Client) analysiert. Die einzelnen Komponenten werden dabei, soweit für ein Redesign der Navigation notwendig, genauer erläutert.

36

37 Kapitel 3 Mittel der Navigation Das Kapitel behandelt bestehende Mittel der Navigation in Software. Betrachtet und bewertet wird eine Auswahl von einzelnen Navigationselementen sowie umfassenden Navigationskonzepten. 3.1 Einführung Die Gestaltung von Benutzungsoberflächen bedient sich wie andere Bereiche der Softwareentwicklung meist bestehender Elemente und Konzepte und erfindet nicht notwendigerweise Neues. Komponenten wie Buttons, Menüs und Bäume sind in GUI-Toolkits üblicherweise vorhanden. Sie erleichtern nicht nur die Implementierung, sondern standardisieren auch Aussehen und Bedienung der Elemente. Dies hat einen positiven Einfluss auf die Erlernbarkeit einer Software. Einige Komponenten (Widgets) werden verwendet, um die Navigation in einer Benutzungsoberfläche zu gestalten. Abschnitt 3.3 stellt solche Elemente und Funktionen vor und betrachtet deren unterschiedliche Ausprägungen und Varianten. Die Komplexität einer Navigation durch eine Software steigt mit der Anzahl der Funktionen und Datenobjekte, die darin enthalten sind. Die Verwendung eines einzigen Navigationselementes reicht zur Beherrschung der gesteigerten Komplexität nicht aus. In Abbildung 3.1 wird die Komplexität von Anwendersoftware, gemeint ist Software mit einer Benutzungsoberfläche, als eine von der Anzahl der Objekte und Anzahl der Funktionen bestimmte Variable dargestellt. Zum ersten Quadranten mit einer geringen Anzahl von Objekten und Funktionen gehören einfache Anwendungen. Steigt die Anzahl der Funktionen, so handelt es sich um komplexe konstruktive Anwendungen. Die meiste Software im Desktopbereich gehört zu diesen beiden Anwendungsarten. Quadrant drei und vier mit einer großen Anzahl von Objekten enthält Anwendungen, die in einer Systemumgebung zu finden sind. Deskriptive Anwendungen bezeichnen

38 26 Mittel der Navigation Anwendungen, die nicht viel Interaktion mit den Objekten erlauben. Als Expertenanwendung bezeichnet man Software, die viele Objekte und Funktionen hat. Eine Anpassung an die speziellen Eigenschaften einer Software ist heute immer noch unumgänglich [28]. Abschnitt 3.4 behandelt abstrakte Konzepte, die die Gestaltung der Navigation unterstützen. Anzahl Objekte Komplexität von Anwendersoftware Komplexe deskriptive Anwendungen Experten- Anwendungen System Umgebungen Einfache Anwendungen Komplexe konstruktive Anwendungen Single User Umgebungen Anzahl Funktionen Abbildung 3.1: Quadranten der Komplexität von Anwendungen, bestimmt von Anzahl der Funktionen und Objekte 3.2 Informationsstruktur, Visualisierung und Interaktion Die Navigation einer Software kann nicht unabhängig von der darzustellenden Information und Funktionalität gestaltet werden. Selbst generische Ansätze zur Erstellung von Benutzungsoberflächen benötigen ein Modell der darzustellenden Information als Eingabe [13]. In einem ersten Schritt des Navigationsdesigns muss deswegen die Informationsstruktur betrachtet werden. Zur Analyse der Informationsstruktur muss man zwischen neu zu erstellender und neu zu gestaltender Software unterscheiden (siehe Abschnitt 2.1.4). Das Erarbeiten einer Informationsstruktur erfolgt in den anerkannten Prozessen der Softwareentwicklung, zum Beispiel dem Unified Software Development Process [21], prinzipiell gleich: Zunächst wird eine Analyse der Anforderungen erstellt. Daraus entsteht dann eine Spezifikation, die völlig unabhängig von der Implementierung die Funktionen der neuen Software beschreibt. Die Unified Modeling Language (UML) bietet mit Use-Case Diagrammen eine Notation, welche die Spezifikation unterstützt. Aus einer Spezifikation lassen sich ein Objektmodell und die zugehörige Interaktion herauslesen. Die so gewählte Interaktions- und Navigationsform beeinflusst die Visualisierung der Objekte. Da die Möglichkeiten der Informationsvisualisierung durch diese Abhängigkeit oft eingeschränkt werden, beschäftigen sich Informationsdesigner

39 3.3 Navigationselemente 27 damit, eine geeignete Repräsentation für die Objekte zu finden. Tabelle 3.1 stellt den in [28] formulierten Ziele der Visualisierung die daraus entstehenden Anforderungen an die Navigation gegenüber. Ziele der Visualisierung Navigationsfunktionen kompakte Darstellung von großen Übersichtsfunktion Datenmengen verschiedene Sichten auf die gleiche Information Wechsel zwischen den Sichten, Verknüpfung der Darstellungen Informationsvisualisierung auf verschiedenen Drilldown, Gedankenmodell, wo Detailstufen man sich befindet Unterstützung des visuellen Vergleiches parallele Anzeige von Information Geschichten über Daten erzählen Zusammenhänge navigierbar machen Tabelle 3.1: Einfluss der Präsentationsgestaltung auf die Interaktionsgestaltung Interaktionsgestaltung wird also sowohl von der konzeptionellen Gestaltung als auch von der Präsentationsgestaltung bestimmt. 3.3 Navigationselemente Dieser Abschnitt stellt Bedienelemente von grafischen Benutzungsoberflächen (GUIs) und Funktionen, die zur Navigation eingesetzt werden, vor Menüs und Toolbars Menüs gehören zum Standard der Navigation durch Anwendungsprogramme. Sie sind das am häufigsten angewandte Element [18]. Die Entwicklung von Menüs in den letzten Jahrzehnten zeigt Abbildung 3.2. Menüs in Terminalumgebungen, wie zum Beispiel in Pine, werden in [17] untersucht. Sie kommen heute nur noch selten vor. Nahezu alle Anwendungen mit GUI besitzen eine am oberen Fensterrand horizontal angeordnete Menüleiste mit Pull-Down-Menüs. Der Screenshot von TeXnicCenter in Abbildung 3.2 ist ein typisches Beispiel. Darunter sind zwei besondere Menüformen dargestellt: Das Sketchingtool Denim bietet ein Tortenmenü, das bei einem Doppelklick über der Zeichenfläche erscheint. In Maya gibt es Kontextmenüs mit transparentem Hintergrund. Dadurch wird das Bearbeitungsobjekt nur soweit notwendig verdeckt. Als Kontextmenü (oder Pop-Up-Menü) bezeichnet man ein Menü, das zu einem bestimmten Datenobjekt in der Benutzungsoberfläche gehört. Darin enthalten sind Funktionen auf das ausgewählte Objekt. Das Kontextmenü wird über die rechte

40 28 Mittel der Navigation Abbildung 3.2: Menüs und Toolbars in verschiedenen Anwendungen Maustaste aktiviert und erscheint relativ zur Mausposition. Genauso wie bei Pull- Down-Menüs wird durch ein Kontextmenü die darunter liegende Information während der Auswahl eines Menüpunktes verdeckt. Menüs werden häufig durch einen Schatten von ihrem Hintergrund abgehoben. Eine weitere Menüform sind Tear-Off-Menüs. Diese Abreißmenüs sind eine Variation der Pull-Down-Menüs: Ein Pull-Down-Menü kann an einer bestimmten Stelle abgerissen werden und irgendwo in der Benutzungsoberfläche platziert werden. Es verschwindet nicht, bis man es explizit schließt. Die Menüleiste wurde in der Entwicklung der Benutzungsoberflächen ergänzt durch eine Icon-Toolbar, die schnellen Zugriff auf Befehle erlaubt. Dabei ist die Menge der Toolbarbefehle meist ganz in der Menge der Menübefehle enthalten. Dies ist besonders in Hinblick auf Accessibility wichtig. Sowohl in der Menüleiste, als auch in der Toolbar werden Funktionen, die aktuell nicht eingesetzt werden können, ausgegraut. Funktionen, über denen sich die Maus befindet, werden markiert. In der Toolbar wird die Markierung durch einen so genannten Tooltip, der textuellen Entsprechung des Icons, ergänzt. Menüs sind im Allgemeinen hierarchisch strukturiert. Dabei ist sieben (plus oder minus zwei) die magische Grenze für die Anzahl der Einträge pro Ebene. [38] Folgende Aufzählung aus [18] enthält Punkte, über die bei der Gestaltung von Menüs entschieden werden muss: Text, Grafik, Farbe, Größe oder eine Kombination daraus zur Codierung der Menüelemente Abstände, Gruppierungen, vertikale oder horizontale Anordnung von Menüelementen

41 3.3 Navigationselemente 29 Verkettung von Menüs Reihenfolge der Menüelemente bestimmt durch z. B. Wichtigkeit, Konvention, Häufigkeit, Alphabet oder Sonstige Zeitpunkt und Ort des Erscheinens von Menüs Auswahlart (z. B. Maus oder Cursortasten) Menüs und Toolbars sind leicht erlernbar und eignen sich zur Navigation einer großen Anzahl von Funktionen. Werden passende Bezeichner für die Menüeinträge gewählt, gibt es praktisch keine Eingabefehler. Nachteil von Menüs und vor allem Toolbars ist, dass sie viel Bildschirmplatz verbrauchen. Die Auswahl vor allem in kaskadierenden Pull-Down-Menüs ist langsam, und es ist eine starke Strukturierung erforderlich, da nur eine kleine Menge von Auswahlpunkten gleichzeitig angezeigt werden soll Tabs Zur Navigation von verschiedenen Sichten eignen sich Reiter oder so genannte Tabs. Diese können, wie in Abbildung 3.3 gezeigt, oben oder unten angeordnet werden. Es existieren außerdem Anwendungen, in denen Tabs vertikal links oder rechts angeordnet sind. ^ Reiter mit verschiedenen Tabs im TeXnicCenter Attributreiter im Diagrammwizard von MS Excel > Abbildung 3.3: Tabs in verschiedenen Anwendungen Tabs können zur Navigation von Funktionen und Objekten verwendet werden. Sie eignen sich nicht zur Navigation von vielen Funktionen oder Objekten, da sie dann nicht mehr unterscheidbar sind. Mehrere Reihen von Tabs sind problematisch. Beispielsweise bei drei Reihen von horizontal, oben angeordneten Tabs müssen die Reihen bei einer Auswahl aus der ersten oder zweiten Reihe umsortiert werden, um den Effekt, dass der Tab mit der Anzeigefläche verbunden ist, beizubehalten. Umsortierungen verwirren den Benutzer. Wizards sind ein Navigationskonzept, in das Tabs sinnvoll integriert wurden (Abbildung 3.3 rechts). Ein weiteres einfaches Navigationselement, das in Wizards mit Tabs kombiniert wird, sind Funktionstasten (hier zum vorwärts und rückwärts gehen).

42 30 Mittel der Navigation Links Bei Links handelt es sich meist um blaue, unterstrichene Wörter oder Sätze, die den Inhalt eines Fensters ändern oder ein neues Fenster öffnen. Das Konzept ist aus Hypertextmedien, vor allem dem Internet, bekannt und wird intuitiv benutzt. Der Nachteil solcher Links ist ihre textuelle Repräsentation. Sie ist möglicherweise nicht eindeutig, platzraubend und belastet die kognitive Wahrnehmung Breadcrumb Trail und Undo Wird bei der Navigation durch eine Benutzungsoberfläche der Weg des Benutzers, d. h. welche Bildschirmseiten er gesehen hat oder auch welche Funktionen er betätigt hat, erfasst und hintereinander dargestellt, spricht man von einem Breadcrumb Trail. Diese Repräsentation des Weges wurde frei nach Hänsel und Gretel benannt. Sie gibt dem Benutzer Aufschlüsse über die Informationsstruktur und bietet außerdem eine Möglichkeit zur Navigation [24]. Der Breadcrumb Trail findet sowohl bei Anwendungsprogrammen als auch Websites Verwendung. Eine Variation ist die optische Hervorhebung bereits besuchter Links. Breadcrumb Trail ist die visualisierte Möglichkeit, um zu bereits gesehenen Bildschirmseiten zurückzunavigieren. Es ist nicht notwendigerweise eine Undo-Funktion damit verbunden. Undo ist ein mächtiges Konzept, meist erreichbar durch einen einzigen Button, Menüeintrag oder Tastatur-Shortcut. In [34] wird es erläutert und diskutiert Landmarks Als Landmarks bezeichnet man Elemente einer Benutzungsoberfläche, welche die Navigation visuell unterstützen, d. h. die durch Wiedererkennung den Benutzer auf den richtigen Weg führen. Dies setzt voraus, dass der Benutzer diesen Weg schon einmal gegangen ist oder aber, dass es sich um allgemein bekannte Landmarks handelt. Der Begriff ist abgeleitet aus der realen Welt, in der der Mensch sich Wege zum Beispiel durch eine Stadt am einfachsten anhand von signifikanten Punkten (z.b. Kirchen, Denkmäler, Brücken, etc.) merkt. Bei der Entwicklung von Auto-Navigationssystemen zum Beispiel wurde dies erkannt und explizit in die Benutzungsschnittstelle eingebaut: Nach 200 Metern an der Kirche rechts. Landmarks lassen sich mit vielen Navigationsmitteln kombinieren und sind ein einfaches und effektives Element zur Verbesserung der Navigation in Benutzungsoberflächen. Das Merken von Landmarks ist natürlich und dadurch einfach und intuitiv. Mit einer dreidimensionalen Darstellung von Landmarks lassen sich bessere Wiedererkennungsergebnisse und eine insgesamt höhere Zufriedenheit des Benutzers erzielen [44]. Die konsistente Verwendung von Landmarks in ganzen Produktfamilien erhöht den Nutzen von Landmarks. Genauso wie konsistente Icons ( gesterntes Dokument für

43 3.4 Navigationskonzepte 31 neu oder Diskette zum Abspeichern) wichtig sind, so ist es auch bei Landmarks einfacher, auf bekannte Symbole zurückzugreifen. Tatsächlich sind Icons und Landmarks sehr stark verwandt. Eine Datenbank zum Beispiel wird sowohl als Icon als auch als Landmark üblicherweise durch einen Zylinder repräsentiert. Benennung von Landmarks erhöht die Benutzbarkeit. Das Zusammenspiel von rechter und linker Gehirnhälfte wird dadurch gefördert, die eine verarbeitet den Begriff, die andere das Bild. 3.4 Navigationskonzepte Navigationselemente werden zu Konzepten kombiniert. Einige davon werden im folgenden Abschnitt vorgestellt Bäume und Variationen Datenobjekte einer Anwendung werden häufig als Listen und Bäume visualisiert. Der Baum eignet sich gut zur Darstellung hierarchischer Zusammenhänge. Graphen werden verwendet, um komplexere Relationen abzubilden. Bäume und verwandte Elemente werden außer zur Visualisierung auch zur Navigation benutzt. Ein dem Element zugeordnetes Fenster oder ein Fensterteil zeigt Detailinformationen zum in der Liste, dem Baum oder dem Graphen ausgewählten Element. Outlook Express zum Beispiel hat in der Standardkonfiguration einen Ordnerbaum, dazu eine Liste, in der die s in dem ausgewählten Ordner angezeigt werden und ein Detailfenster, in dem der Inhalt der in der Liste ausgewählten angezeigt wird. Es gibt eine Reihe von Graph-Visualisierungen, zum Beispiel Hyperbolic Trees. Diese bennötigen selbst eine komplexe Navigation (z. B. zur Änderung der Perspektive). Siehe dazu [19]. Als allein zur Navigation eingesetztes Konzept sind sie deswegen nicht geeignet. Bäume sind ein sehr häufiges Element in Anwendungen. Sie werden zum Beispiel fast immer zur Darstellung der hierarchischen Struktur von Dateisystemen verwendet. Abbildung 3.4 zeigt das Konzept der Treemaps, welches in der Diplomarbeit eine wichtige Rolle spielt. Der Baum wird dabei auf einer zweidimensionalen Fläche ausgebreitet. Es ist eine interessante Möglichkeit, die das Problem adressiert, dass bei sehr vielen Elementen in der klassischen Baumdarstellung kein Überblick vorhanden ist.

44 32 Mittel der Navigation Abbildung 3.4: Vom Baum zur Treemap

45 3.4 Navigationskonzepte 33 Treemaps Treemaps lassen sich unter zwei Aspekten klassifizieren: zum einen aufgrund ihrer visuellen Darstellung, zum anderen aufgrund der zugrunde liegenden Daten. In der abstraktesten Darstellungsform von Treemaps, der klassischen Treemap, wird die gesamte Fläche der Treemap aus Flächen der Blattknoten des zugrunde liegenden Baumes gebildet. Cushion Treemaps [43] setzen einen zur Mitte der Fläche gehenden graduellen Farbverlauf zur Differenzierung der Flächen ein. In anderen Darstellungsarten werden Grenzen nur durch feine Linien oder implizit durch unterschiedliche Farben der aneinander grenzenden Flächen deutlich. Die in Abbildung 3.5 dargestellte MarketMap von smartmoney.com ist ein solches Beispiel. Die Monitor Map für Statistic Details im Prototypen implementiert ebenfalls dieses Konzept. Abbildung 3.5: MarketMap von smartmoney.com Die hierarchische Struktur kann man in so genannten nested Treemaps klarer erkennen. Die Baumstruktur wird dabei durch eine Ineinanderschachtelung von Flächen deutlich gemacht. Die alles umschließende Fläche entspricht dem Wurzelknoten des Baumes. Rahmenbreite, Farbe und Abstand zwischen Rahmen und Inhalt kann dabei individuell gestaltet werden. Diese Form der Treemap wird im Prototypen von der Monitor Map für System Overview implementiert. Die visuelle Gestaltung einer Treemap hängt auch davon ab, ob den Blattknoten eine Gewichtung zugewiesen wird oder nicht. Das Gewicht wird in der Treemap von der Größe der Fläche dargestellt. Haben alle Knoten das gleiche Gewicht, so sollte der Anordnungsalgorithmus der Treemap allen Flächen der gleichen Hierarchiestufe die gleiche Größe geben. Eine zweite Klassifikation von Treemap leitet sich aus den zugrunde liegenden Daten ab. Es kann unterschieden werden zwischen statischen Treemaps, deren Anzahl der Flächen sich nicht ändert und dynamischen Treemaps, in denen Flächen hinzukommen und wieder entfernt werden. Einige Eigenschaften der Treemap werden dadurch beeinflusst.

46 34 Mittel der Navigation Attribute von Objekten in einer Treemap können mit folgenden Mitteln visuell codiert werden: Text Icons Farbe, Muster Form Animation (z. B. Blinken) Größe (bei gewichteten Treemaps) Alle diese Mittel sollten nur sparsam eingesetzt werden, d. h. nicht zu viel Text, nicht zu viele verschiedene Icons, Farben und Formen, Animation nur zur besonderen Hervorhebung. Ziel der Treemap ist es, den Benutzer zu entlasten und nicht durch zu viel visuelles Feedback zu überfordern. Es ist sinnvoll, dem Benutzer eine Legende anzubieten. Speziell der Einsatz von Icons, Mustern, Formen und Animation muss sorgfältig abgewogen werden, denn diese Darstellungsmittel erzeugen ein unruhiges Gesamtbild der Monitor Map. Größenunterschiede zur Codierung von Information sind problematisch, da der Mensch die Größe einer Fläche, abhängig von der Form und Farbe, oft falsch einschätzt. Abbildung 3.6 zeigt zwei solche optische Täuschungen: die Kreise in der Mitte sind jeweils gleich groß. Titchenerche Täuschung Die Kreise im Inneren sind jeweils gleich gross. Abbildung 3.6: Titchenersche Täuschung - Fehleinschätzung der Größe durch den Kontext Der Benutzer wird bei der Benutzung von Treemaps effizienter. Er erinnert sich an die Position bestimmter Flächen in der Treemap und kann diese schneller wiederfinden und ansteuern. Diese Leistung beruht auf dem räumlichen Denken und passiert unbewusst. Das kognitive Denken wird dabei nicht belastet. Dieser Effekt muss ausgenutzt werden. Reorganisation von Treemaps muss deshalb vermieden werden Sitemaps Viele Websites bieten Sitemaps an. Dabei handelt es sich um eine Zusammenfassung aller wichtigen Inhalte der Site und deren direkte Verlinkung, d. h., es kann ohne

47 3.4 Navigationskonzepte 35 Umwege, meist mit einem Mausklick, zu einer beliebigen Stelle der Site navigiert werden. Die Nielsen Norman Group hat in einer Studie [33] über Site Map Usability folgende Beobachtungen gemacht: Benutzer verwenden Sitemaps zur Navigation sehr selten. Benutzer sind sich der Anwesenheit von Sitemaps kaum bewusst. Manche Benutzer können die Sitemap nicht finden, selbst wenn sie explizit danach suchen. Schlussfolgerungen, die gezogen wurden, besagten, dass Sitemaps selbst keine Navigationsherausforderung sein dürfen. Sie müssen kurz und am besten statisch gestaltet werden. Durch den realen Kontext der Sitemaps und Landmarks verbindet (die Landkarte), erscheinen diese beiden Elemente besonders zur gemeinsamen Verwendung geeignet. Demgegenüber steht, dass Sitemaps meist sehr schlicht sind: Das ist wichtig, um den Benutzer nicht abzulenken und auch, um alle Inhalte auf einen Blick präsentieren zu können. Sitemaps visualisieren die Struktur des Informationsraumes und erzeugen im Kopf des Benutzers ein Modell, welches die Navigation innerhalb der Site unterstützt. Außerhalb des WWW werden Sitemaps bisher nicht eingesetzt. Ihre Eignung zur Navigation in Anwendungen ist zu untersuchen Suche Im WWW ist die Suche beziehungsweise die Ergebnisseite einer Suche zum Hauptnavigationsmittel geworden. Einzelne Websites bieten zudem interne Suchen an, und WikiWiki-Systeme sind gerade wegen dieser Möglichkeit beliebt. In einigen Bereichen ist die Suche auch in Anwendungsprogrammen verfügbar. Zum Beispiel sind die meisten Hilfesysteme so interaktiv, dass darin gesucht werden kann. Wenn Sitemaps für Programme, wie im obigen Abschnitt beschrieben, denkbar sind, dann ist der nächste Schritt eine Suche. Nielsen [33] bezeichnet die Suche als Alternative zur Sitemap Fenster und Drilldown Objekte und Funktionen einer Anwendung können in verschiedenen Fenstern gruppiert werden. Die Navigation zwischen diesen Fenstern erfolgt über die Taskleiste des Betriebssystems oder spezielle Menüs. Verschiedene Fenster in einem umgebenden Fenster, wie z. B. in Adobe Photoshop bezeichnet man als integrierte Oberflächen. In [11] werden Mehrfenstersysteme und integrierte Oberflächen verglichen. Ergebnis der Arbeit ist, dass sich nicht allgemein

48 36 Mittel der Navigation sagen lässt, dass das Eine den Benutzer besser in seiner Arbeit unterstützt als das Andere. Die Entscheidung muss individuell für jede Software getroffen werden. Um der Überfüllung der Taskleiste entgegenzuwirken, werden beispielsweise in Microsoft Windows XP gleichartige Fenster in der Taskleiste gruppiert. Damit werden viele Einträge mit einem weiteren Schritt zur Zielerreichung beherrschbar gemacht. Diesen Schritt vom Groben zum Feinen bezeichnet man als Drilldown. Ein Drilldown linearisiert den Weg des Benutzers durch das Programm. Wichtig dabei ist, dass ein Gedankenmodell aufgebaut wird. Der Benutzer muss stets wissen, wo er sich befindet. Dies kann zum Beispiel durch einen Breadcrumb-Trail unterstützt werden Direkte Navigation Mit direkter Navigation ist die Navigation durch Direkte Manipulation von Objekten in der Benutzungsoberfläche gemeint. Direkte Manipulation ist ein abstraktes Konzept, das sich vor allem aus der Visualisierung der Objekte ableitet. Aus Sicht der Benutzer sind Systeme, die dieses Konzept einsetzen, besonders einfach zu bedienen [18]. Folglich sollte es auch zur Navigation verstärkt eingesetzt werden Metaphern Metaphern in der Softwareentwicklung sind wie Metaphern der realen Welt, Mittel, um die Kommunikation zwischen Autor und Leser (bzw. Entwickler und Benutzer) zu erleichtern [16]. Metaphern unterstützen die Navigation in Benutzungsoberflächen, indem dem Benutzer durch eine Analogie in eine bekannte Domäne der Aufbau eines Gedankenmodells erleichtert wird. Zu vermeiden ist, dass die Metaphern zu restriktiv werden, d. h. die Benutzungsoberfläche soll durch die Metapher verbessert und nicht von ihr eingeschränkt werden [15]. Bekanntestes Beispiel ist die Desktop Metapher. Die reale Schreibtischumgebung mit Ordnern, Dokumenten, Papierkorb, etc. finden wir heute im Computer wieder Andere Konzepte Wizards sind ein aufgabenorientiertes Navigationskonzept. Der Benutzer wird geleitet und bei der Erfüllung seiner Aufgabe unterstützt. Die Komplexität der Anwendung wird vor ihm verborgen. Anwendungen, in denen die Analyse einer großen Anzahl von Objekten im Vordergrund steht (z. B. Monitoring Anwendungen, wie der DB2 Performance Expert), erfordern darüber hinaus Aufgabengenerierung und dafür geeignete Navigationskonzepte. Dreidimensionale, sprachliche und haptische Benutzungsoberflächen eröffnen weitere Möglichkeiten.

49 Kapitel 4 Eine Navigation für den DB2 Performance Expert In diesem Kapitel wird gezeigt, wie die in den vorhergehenden Kapiteln besprochenen Grundlagen zum Redesign von Benutzungsoberflächen mit Mitteln der Navigation in einem Projekt angewandt wurden. Eine verbesserte Navigation für den DB2 Performance Expert wurde entworfen, realisiert und getestet. Der erste Abschnitt gibt einen Überblick über dieses Projekt. Die folgenden Abschnitte sind jeweils einer Entwicklungsaktivität gewidmet: Analyse, Design, Spezifikation, Entwurf & Implementierung und Evaluation. 4.1 Das Projekt Aufgabenstellung Der DB2 Performance Expert ist ein System, dessen gewachsene Komplexität mit der bestehenden Benutzungsoberfläche nicht mehr beherrscht werden kann. Deswegen soll das Produkt durch Mittel der Navigation neu gestaltet werden. Der Abschnitt 1.3 der Einleitung führt die von Kunden vorgebrachten Beschwerden auf und motiviert, warum die Navigation im DB2 Performance Expert ein geeigneter Aspekt für das Redesign ist. Der Abschnitt 4.2 Analyse identifiziert und präsentiert die zu bearbeitenden Punkte. Das Redesign des DB2 Performance Experts ist prototypisch, d. h. das entwickelte Konzept wird anhand eines Beispiels realisiert. Es muss sicher gestellt sein, dass das Konzept auf das ganze Produkt übertragbar ist Projektablauf Das Redesign des DB2 Performance Expert kann in seiner Organisation als Softwareentwicklungsprojekt betrachtet werden. Das Projekt folgte einem iterativen Vor-

50 38 Eine Navigation für den DB2 Performance Expert gehensmodell, d. h., dass diese Folge von Aktivitäten mehrere Male durchlaufen wurde: Analyse Design Spezifikation Entwurf Implementierung Test / Evaluierung Solche Durchläufe nennt man Iterationen. Das Redesign des DB2 Performance Experts erfolgte in sechs Iterationen. Die erste Iteration war stark von der Analyse der bestehenden Benutzungsoberfläche geprägt. In der zweiten und dritten Iteration spielte Design eine wichtige Rolle. Recherchen in unterschiedlichsten Domänen dienten der Ideenfindung. Viele Alternativen und Möglichkeiten wurden gesammelt und parallel entwickelt. Es entstanden eine Reihe von kurzen Spezifikationen, von denen die Endgültige erst in einer späteren Iteration ausgewählt wurde. In diesen beiden Iterationen wurden die verschiedenen Konzepte in Low-Fidelity Prototypen umgesetzt. Es entstanden Freihandskizzen, mit Grafikprogrammen erstellte Bilder und PowerPoint-Prototypen. Ein großer Schwerpunkt der zweiten und dritten Iteration lag bei Ad-Hoc Tests, bei denen die Meinung der Benutzer zu verschiedenen Konzepten erfragt wurde. Dieses Vorgehen dient zum einen der frühen Evaluierung von Konzepten und generiert außerdem neue Ideen. In der vierten Iteration lag das Hauptaugenmerk auf der Spezifikation. Die Vielfalt der entstandenen Ideen wurde zu einem Gesamtkonzept verarbeitet. In einem Prototypen, wie er in dem Projekt entstehen sollte, besteht die Möglichkeit, Funktionen lediglich anzudeuten. Im Hinblick auf die zur Verfügung stehende Zeit wurde entschieden, inwieweit die einzelnen Funktionen implementiert werden sollten. An manchen Stellen war es erforderlich, Beispiele zu implementieren, um die Machbarkeit eines Konzeptes sicherzustellen. Eine fünfte Iteration beschäftigte sich mit der Implementierung des Prototypen. Dazu musste der vorhandene Code analysiert, die Schnittstellen entworfen und der neu entstandene Code getestet werden. Die letzte Iteration stand im Zeichen von umfassenden Usability Tests, Walkthroughs und einer Heuristischen Evaluierung. Die Implementierung wurde mit einem testbaren Prototypen abgeschlossen, und die standardisierten Tests wurden vorbereitet und durchgeführt. Das Vorgehen im Projekt wurde beeinflusst von den in Abschnitt 2.1 vorgestellten Methoden und Vorgehensweisen des User Centered Design. Zum Abschluss einer solchen Entwicklung sollten in einer letzten Iteration die Erkenntnisse der Evaluierung in den Prototypen eingearbeitet werden. Diese Iteration wurde im Rahmen der Diplomarbeit durch eine schriftliche Auswertung der Ergebnisse ersetzt (siehe 4.6).

51 4.2 Analyse Unterschiede zu anderen Softwareprojekten Das durchgeführte Projekt unterscheidet sich in vier Punkten von herkömmlichen Softwareprojekten. 1. Der Schwerpunkt lag darin, ein Navigationskonzept zu entwerfen. 2. Da es sich um ein Redesign handelt, mussten vorhandene Navigationsmöglichkeiten erhalten bleiben, oder sich vollständig im neuen Design widerspiegeln, um den Benutzern der vorherigen Version gerecht zu werden. 3. Es wurde ein Wegwerfprototyp entwickelt. 4. Nur eine Person war für die Durchführung des Projektes verantwortlich. Feedback kam immer von außerhalb des Projekts stehenden Personen. 4.2 Analyse Die Analyse der bereits bestehenden Benutzungsoberfläche des DB2 Performance Experts gliedert sich in mehrere Teile: Einleitend werden die bereits in Abschnitt 1.3 erwähnten Kundenanforderungen und eine interne IBM-Studie zu Benutzungsoberflächen der DB2 ausgewertet. Darauf folgt eine Analyse des Istzustands Kundenanforderungen Kunden des DB2 Performance Experts haben in der Vergangenheit Beschwerden über die Benutzbarkeit des Produktes geäußert: Schwierigkeiten, Funktionen zu finden nicht erkennbares Gedankenmodell der Oberfläche leichter zu bedienende Konkurrenzprodukte ungenügende visuelle Darstellung zu viele Fenster Die ersten drei Punkte deuten darauf hin, dass der Benutzer kein Gedankenmodell des DB2 Performance Experts aufbauen kann. Die in der Benutzungsoberfläche vorhandenen Interaktionsobjekte werden nicht mit den ihnen zugeordneten Funktionen verknüpft. Das führt dazu, dass der Benutzer Funktionen nicht finden kann. Im Redesign muss eine bessere Repräsentation für Systeme und Funktionen entworfen werden. Die ungenügende visuelle Darstellung wird vor allem mit dem Hinweis auf Konkurrenzprodukte geäußert. Diese verwenden viele farbige Grafiken zur Visualisierung einzelner Counter. Daraus lässt sich die Anforderung eines zusätzlichen visuellen Feedbacks über den Wert oder Zustand der textuell repräsentierten Counter-Werte ableiten.

52 40 Eine Navigation für den DB2 Performance Expert Zu viele Fenster werden geöffnet, um eine n:m Beziehung darzustellen: Es gibt im DB2 Performance Expert n konfigurierte Systeme, denen m verschiedene Komponenten zugeordnet sind. Für jede Komponente öffnet sich nur ein Fenster. Öffnet man zum Beispiel System Parameters für System A und danach dieselbe Komponente für System B, so werden die Daten in demselben Fenster angezeigt. Diese Lösung verwirrt den Benutzer zusätzlich. Die folgende Aufzählung fasst die aus dem Feedback der Kunden gewonnenen Anforderungen zusammen: schneller Zugriff auf Funktionen direkte Verknüpfung von Funktionen und Objekten (Datenbanken) Führung des Benutzers zu den Funktionen, die er braucht Visualisierung von Countern bzw. Anzeigen eines Systemstatus Beherrschung der Datenmenge und Komplexität, ohne viele Fenster zu öffnen eindeutige Zuordnung der Fenster - intuitive Bedienbarkeit Elemente der Benutzungsoberfläche von DB2-Produkten In einer internen Studie von IBM [8] wurden die Probleme bei der Bedienung der DB2 untersucht. In Abschnitt 1.3 wurde bereits darauf eingegangen. Die Schwierigkeit der Datenbankadministration ist mit dem explosiven Wachstum und der Zunahme an Komplexität bei heutigen Datenbankumgebungen gestiegen. Dem gegenüber steht ein Mangel an qualifizierten Administratoren [47]. Innovation zur Steigerung des Ease Of Use ist dringend erforderlich. Die Untersuchung des Benutzungsoberflächenmodells der DB2 hat ergeben, dass der Navigationsbaum mit zugeordnetem Detailfenster im DB2 Control Center dem Anstieg der Datenobjekte und Datenmengen nicht angepasst wurde. Dies lässt sich auf den DB2 Performance Expert übertragen. Auch darin werden zumeist Bäume zur Navigation benutzt. Die sich aus der Studie ableitenden Anforderungen ähneln den im vorigen Abschnitt herausgearbeiteten Kundenanforderungen. Die folgende Aufzählung enthält eine Liste der vorgestellten Eigenschaften einer verbesserten Benutzungsoberfläche: visuelle Hinweise, um dem Benutzer die Wahl des Weges zu erleichtern Anzeige von Beziehungen zwischen Objekten vereinfachte Darstellung: z. B. verschiedene Stufen von Wichtigkeit für Objekte und Funktionen Strukturen, die den realen Aufbau einer Datenbank widerspiegeln und das Verständis fördern Ausnutzung der räumlichen Wahrnehmung des Benutzers - Verschiebung der kognitiven Benutzerbelastung in den Bereich des Empfindens Berücksichtigung des Kontextes und Personalisierung, z. B. Entwurf einer rollenbasierten Benutzungsoberfläche

53 4.2 Analyse 41 Feedback über Systemstatus in Echtzeit Aufgabenorientierung Realisierung als Alternative, d. h. ergänzend zum bisherigen Aufbau der Benutzungsoberfläche Istzustand Der Abschnitt 2.4 hat den DB2 Performance Expert kurz vorgestellt. An dieser Stelle soll das bestehende Produkt vor allem im Hinblick auf die Navigation untersucht werden. Zur Übersicht dienen die Abbildungen 4.1 und 4.2. Der DB2 Performance Expert bietet Funktionen für Datenbanken auf z/os sowie auf Multiplatforms. Abbildung 4.1 zeigt die für Datenbanken auf beiden Plattformen angebotenen Funktionen. Alle sind über System Overview (a) erreichbar. Im Einzelnen handelt es sich bei den Funktionen um: Eine Hilfefunktion (b), die kontextabhängig Hinweise zur Benutzung bietet, die Übersicht der Locking Conflicts (c), die Übersicht der für das System geltenden Parameter (System Parameters (d)), System Health (e) zur Visualisierung und In-Zusammenhang-Setzung von Countern, das Performance Warehouse (f) zur Analyse von Countern und die Statistic Details (g). Alle diese Komponenten öffnen sich jeweils in einem neuen Fenster. Bei System Health und dem Performance Warehouse handelt es sich um eigenständig entwickelte Komponenten, die in den DB2 Performance Expert integriert sind. Im Rahmen der Neugestaltung der Navigation sollen diese Funktionen zugänglich bleiben, jedoch nicht mitverändert werden. Die Hilfefunktion soll in dieser Arbeit nicht weiter betrachtet werden. Die Counter in den Komponenten sind, wie man an den Screenshots in Abbildung 4.1 und 4.2 sehen kann, immer entweder in Tabellenform oder in thematisch gruppierten Bezeichner-Wert-Paaren angeordnet. Zur Navigation dient oft ein Baum auf der linken Seite. Im Falle von System Parameters (d) hat dieser Baum die Tiefe von eins. Der Baum von Statistic Details (g) hat die Tiefe von drei. Abbildung 4.2 zeigt die Funktionen des DB2 Performance Experts, die bei Multiplatform und z/os Systemen verschieden sind.

54 42 Eine Navigation für den DB2 Performance Expert Abbildung 4.1: Übersicht DB2 Performance Expert

55 4.2 Analyse 43 Abbildung 4.2: DB2 Performance Expert: Multiplatform- und z/os-funktionen

56 44 Eine Navigation für den DB2 Performance Expert Der DB2 Performance Expert auf Multiplatforms bietet zusätzlich zu den in Abbildung 4.1 dargestellten Funktionen: Buffer Pool Analysis (h) - ein eigenständiges, in den DB2 Performance Expert integriertes Tool, mit dessen Hilfe Reports über die Nutzung der Bufferpools gemacht werden können Application Summary (i) und Applications in Lock Conflicts (j) - weitere Sichten auf die Applikationen auf der ausgewählten Datenbank Folgende Funktionen sind zusätzlich für z/os verfügbar: Threads in Lock Conflicts (k) - Anzeige einander behindernder Threads in einem System Trace Activation (m) - Möglichkeit, Thread-Aktivitäten der Systeme zu beobachten Thread Summary und Thread Details (l) - genaue Sicht auf die Threads eines Systems Buffer Pool Analysis (n) - Möglichkeit, Befehle an die Datenbank abzusetzen Genauso wie bei den gemeinsamen Komponenten für Multiplatforms und z/os verwenden die Komponenten in Abbildung 4.2 meist Tabellen oder einfache Seiten mit Gruppierungen zur Darstellung der Counter. Zur Navigation wird eine flache Baumstruktur auf der linken Seite angeboten. System Overview als Hauptfenster des Produktes und Statistic Details als repräsentativer Vertreter der Komponenten wurden für das Redesign ausgewählt und werden im Folgenden genauer vorgestellt. System Overview System Overview ist das Einstiegsfenster des DB2 Performance Experts. Es ruft die anderen Fenster auf und steuert diese. Über einen Wizard können in System Overview zu beobachtende Systeme konfiguriert werden. Diese werden dann in einem Baum im linken Teil des Fensters angezeigt. Die Struktur des Baumes wird durch die Art der Systeme bestimmt. Der Ordner All DB2 Systems unterscheidet Multiplatform und z/os Systeme. Alle Multiplatform- Systeme befinden sich in einem weiteren Unterordner namens Instances. Der Ordner z/os enthält die Unterordner Subsystems, Data Sharing Groups und Gateways. Systeme, die zu der gleichen Data Sharing Group gehören, werden in einem weiteren Ordner, der den Namen der Data Sharing Group trägt, unter Data Sharing Groups angelegt, Gateways im Gateway Ordner und Subsysteme im Subsystems Ordner. Wurzelknoten des gesamten Baumes ist Monitored Objects. Neben All DB2 Systems befindet sich darunter ein weiterer Ordner namens My Folders. In My Folders kann der Benutzer nach Belieben eigene Ordner anlegen. Darin können Verknüpfungen mit unter All DB2 Systems konfigurierten Systemen angelegt werden. Sinn von My

57 4.2 Analyse 45 Folders ist es, dem Benutzer zu erlauben, sich eine eigene Sicht auf die konfigurierten Systeme zusammenzustellen. Zum Beispiel kann er einen Ordner für die wichtigsten Systeme anlegen, um schneller darauf zugreifen zu können. My Folders ist eine Funktion, die erst in der nächsten Version des DB2 Performance Experts verfügbar sein wird. Da ihre Entwicklung und Evaluation noch nicht abgeschlossen ist, wird in dieser Diplomarbeit nicht weiter darauf eingegangen. Im rechten Teil des Fensters befindet sich die Detailansicht des im Baum ausgewählten Knotens. Wählt man ein System, so werden dort die Namen der dafür zur Verfügung stehenden Komponenten angezeigt. Ist man nicht in ein System eingeloggt, so kann man das in dem Detailfenster tun. Über ein Icon kann man allgemeine Systeminformationen abfragen. Diese Informationen werden auch in der Tabelle im unteren Teil des Fensters angezeigt. Darin wird das ausgewählte System markiert. Ein weiteres in der nächsten Version des DB2 Performance Experts eingeführtes Element sind Grafiken, die einzelne Counter visualisieren. Die Grafiken können in der Komponente System Health für jedes System individuell konfiguriert werden und werden unter den Komponentennamen im Detailfenster angezeigt. Im unteren Teil des Fensters von System Overview werden, wie oben erwähnt, in einer Tabelle alle konfigurierten Systeme angezeigt. Man kann darin neben dem Namen, dem Serverstatus und dem Logonstatus erkennen, auf welcher Plattform ein System läuft und um welche DB2 Version es sich dabei handelt. Statistic Details Der Benutzer erreicht Statistic Details, indem er in System Overview eine Instanz bzw. ein Subsystem im Baum auswählt und im rechten Fensterteil auf Statistic Details klickt. Daraufhin öffnet sich Statistic Details in einem neuen Fenster. Die Komponente hat im oberen Teil eine Menüleiste, eine Toolbar und einen Schieberegler, der zur Navigation von gespeicherten Snapshotdaten dient. Der darunter liegende Fensterteil ist zweigeteilt. Links befindet sich ein Baum, der zur Steuerung der Detailansicht auf der rechten Seite verwendet wird. Der Baum hat eine maximale Tiefe von drei. Die Detailansicht besteht meist aus nochmals durch Überschriften gruppierten Name-Wert-Paaren (Countern), die sich in festgelegten Intervallen aktualisieren. Es ist keine weitere Interaktion möglich Anforderungen Neben einer den Benutzer unterstützenden Navigationsstruktur ist vor allem die Visualisierung und In-Zusammenhang-Setzung der Counter im DB2 Performance Expert wichtig, um die Benutzbarkeit zu erhöhen. Dies erfordert genaue Kenntnis über deren Bedeutung und Wertebereiche.

58 46 Eine Navigation für den DB2 Performance Expert System Overview System Overview ist der Einstieg in den DB2 Performance Expert und der Punkt, an den der Benutzer immer wieder zurückkehrt, um eine neue Aufgabe zu beginnen. Daraus leiten sich, neben den allgemein für GUIs geltenden Eigenschaften (siehe Abschnitt 2.1.1), die folgenden Anforderungen ab: übersichtlich: Struktur und Zusammenhang sollen für alle angeschlossenen Systeme ohne viel Interaktion erkennbar sein. informativ: Möglichst viele Eigenschaften der Systeme sollen ohne Drilldown ersichtlich sein. konfigurierbar/personalisierbar: Benutzer sollen in die Entscheidung der Erscheinung und Anordnung mit einbezogen werden. breit: Alle Funktionen sollen möglichst schnell erreichbar sein (d. h. geringe Navigationstiefe). lenkend: Der Benutzer soll bei der Entscheidung, was er tun möchte, unterstützt werden. Abbildung 4.3: System Overview mit ausgewähltem Ordner (Balkendarstellung)

59 4.2 Analyse 47 Tabelle 4.1 beschreibt aufgrund der vorher geforderten Eigenschaften die Schwächen der jetzigen Implementierung und bewertet diese mit der Priorität 1, 2 und 3. Dabei steht 1 für muss unbedingt geändert werden, 2 für sollte geändert werden und 3 für nice to have. Kurzname Beschreibung des Usability Problems Priorität Balkendarstellung Wählt man im Baum einen Ordner aus, erhält 1 (Abbildung 4.3) der Benutzer im rechten Teil der Sicht horizontale Balken, einen je darunter liegendem Ordner und System. Problematik: Struktur nicht mehr ersichtlich, sogar verwirrend; enthält, falls keine Grafiken konfiguriert sind, weniger Information als der Baum; keine Navigationsfunktion Loginzustand In der Balkendarstellung (Abbildung 4.3) 1 werden lediglich Systeme angezeigt, in die sich der Benutzer vorher eingeloggt hat. Dies ist daraus nicht ersichtlich. Die Darstellung wird deswegen als inkonsistent zum Baum empfunden. Versteckte Systeme um alle zu sehen, nach Öffnen des Ordners im Sind sehr viele Systeme konfiguriert, so muss, 1 Baum gescrollt werden. Status Weder im Baum, noch in der Detailsicht auf 1 ausgewählte Baumelemente, ist ein Status des Systems erkennbar, es sei denn, es wurden in System Health Grafiken konfiguriert, die vom Benutzer korrekt interpretiert werden können. Funktionszugriff Funktionen wie Statistic Details lassen sich 2 lediglich erreichen, wenn ein System ausgewählt ist. Dazu sind nach dem Starten des DB2 Performance Experts mindestens drei, üblicherweise fünf Mausklicks im Baum notwendig. Überforderung Dem unerfahrenen Benutzer wird kaum direkte 2 Hilfe zur Interpretation der ihm zu- gänglichen Counter gegeben. Viele Fenster Jede Komponente öffnet ein eigenes Fenster. 2 My Folders Bezeichnung weckt Erwartung, dass eigene 3 Systemverbindungen und nicht nur Shortcuts abgelegt werden können. Tabelle 4.1: Schwächen im Istzustand von System Overview

60 48 Eine Navigation für den DB2 Performance Expert Die Umgestaltung von My Folders ist wichtig und wird bereits bearbeitet; deswegen soll ihr in diesem Projekt keine weitere Aufmerksamkeit zuteil werden. Statistic Details Ein Datenbankadministrator wird typischerweise spezielle Counter suchen, wenn er diese Komponente benutzt. Eine Aufgabe wäre zum Beispiel, dass ein bestimmter Counter von zwei oder mehr Systemen verglichen werden soll. Eine andere Aufgabe wäre, den Counterwert mit einer Werteskala zu vergleichen, also herauszufinden, ob der Wert im Zielbereich, darunter oder darüber liegt. Aus dem vorgestellten Szenario lassen sich folgende Anforderungen herausarbeiten: vergleichbar: Es muss möglich sein, den gleichen Counter zweier Systeme zu vergleichen. personalisierbar: Die für den Benutzer wichtigsten Counter sollten in einer Sicht zusammengefasst werden können. informativ: Counter, die Grenzwerte überschritten haben, sollen leicht zu erkennen sein. schnell zugreifbar: Auf alle Informationen soll innerhalb kürzester Zeit zugegriffen werden können (sowohl in Hinblick auf Performance als auch für die Navigation relevant). einfach: Leicht zu verstehen und zu bedienen. Tabelle 4.2 beschreibt, welche Schwächen Statistic Details unter Berücksichtigung der aufgestellten Kriterien aufweist. Allgemeine Anforderungen Abschnitt nennt eine Reihe von allgemein anerkannten Gestaltungsprinzipien für Benutzungsoberflächen. Sie bilden neben den hier identifizierten Anforderungen an das Design eine zweite Checkliste, welcher die Ideen im Abschnitt 4.3 Design genügen müssen. Design beschreibt, wie die aufgestellten Anforderungen erfüllt und die Schwächen der bisherigen Benutzungsoberfläche durch eine neue Gestaltung ausgeglichen werden können.

61 4.3 Design 49 Kurzname Beschreibung der Usability Probleme Priorität Statusinformation Weder der Baum, noch die Detailansicht in 1 der rechten Fensterhälfte, geben Aufschluss darüber, ob die einzelnen Counter innerhalb gesteckter Grenzen sind oder nicht, selbst wenn Schwellwerte in System Health konfiguriert sind. Suchen Möchte man einen bestimmten Counter betrachten, 1 so muss man dessen Countergruppe erst im Baum suchen. Meist ist es erforderlich, mehrere Detailansichten anzuklicken. Statik Der Baum bzw. die Detailansichten lassen 2 sich nicht konfigurieren und personalisieren. Konfiguration Die Konfiguration von Schwellwerten ist nur 2 in System Health möglich - darauf gibt es von Statistic Details aus keinen Zugriff. Vergleichbarkeit Immer nur eine Detailansicht kann gleichzeitig geöffnet sein. Es ist schwierig, Counter aus verschiedenen Countergruppen oder Counterwerte zu verschiedenen Zeitpunkten zu vergleichen. Vergleicht man die Werte zweier verschiedener Systeme, muss der Benutzer die Baumnavigation synchronisieren Design Tabelle 4.2: Schwächen im Istzustand von Statistic Details Mit Design ist hier die Gestaltung der Benutzungsoberfläche aus ergonomischer Sicht gemeint. Der Begriff ist dabei nicht zu verwechseln mit der Aktivität Entwurf, die oft auch als Design bezeichnet wird. Der Abschnitt beschreibt, wie Ideen für den Prototypen entstanden sind. Einige der Designvorschläge werden im Abschnitt 4.4 Spezifikation wieder aufgenommen und weiterentwickelt Einführung Es ist in Ordnung, eine Benutzungsoberfläche erklären zu müssen, es ist nur nicht O.K., wenn man es ein zweites Mal tun muss. Auf der Abschlussrede der diesjährigen Computer Human Interaction sagte Donald A. Norman einen Satz, der sinngemäß dem Obigen entspricht. Dieser ist zur Richtlinie beim Redesign der Navigation im DB2 Perfomance Expert geworden. Die neue Benutzungsoberfläche muss nicht völlig intuitiv, im Sinne von walk-up-and-use, zu bedienen sein.

62 50 Eine Navigation für den DB2 Performance Expert Prozess Der Designprozess für das Redesign des DB2 Performance Experts basierte auf vier Säulen: Aufgabenanalyse Inspiration iteratives Vorgehen mit Skizzen und Low-Level Prototypen ständiges Feedback durch Ad Hoc Tests Die Aufgabenanalyse (vgl. Abschnitt 4.2) diente dazu, den Benutzer zu verstehen und seine Bedürfnisse zu identifizieren, sodass alle notwendigen Eigenschaften berücksichtigt werden können. Ihre Ergebnisse wurden für das Design in Szenarios zusammengefasst. Die Inspiration zum Redesign des DB2 Performance Experts wurde häufig im Alltag, Film und in netzbasierter Kunst gefunden. Softwareprodukte aus unterschiedlichsten Bereichen sowie Literatur zur Software-Ergonomie und themenverwandte Konferenzen (die Computer Human Interaction 2003 in Ft. Lauderdale, der Smart Graphics 03 in Heidelberg und die Mensch & Computer 2003 in Stuttgart) lieferten zahlreiche Ideen. Ständiges Feedback in Ad-Hoc Tests ermöglichte nach der Designphase die Entscheidung für das in der Spezifikation (Abschnitt 4.4) vorgestellte Design Designvorschläge In diesem Abschnitt werden Ideen, die während der Designphase entstanden sind, zusammengefasst. Jeder Designvorschlag gliedert sich in das Szenario, das die Notwendigkeit des Redesigns deutlich macht, die Beschreibung des Redesigns und möglicherweise Dinge, die es inspiriert haben und eine Diskussion des Designvorschlags. Der Diskussionsteil ist stichwortartig aufgebaut. Vorteile werden durch + eingeleitet, Nachteile durch - und allgemeine Hinweise durch!. Die hier vorgestellten Designvorschläge sind nicht alle im Prototypen umgesetzt worden. Viele bilden Ergänzungen zum Prototypen und werden im Abschnitt Evaluierung wieder aufgegriffen. Designvorschlag Integrierte Oberfläche Szenario Jede Komponente im DB2 Performance Expert öffnet ein eigenes Fenster. Neben dem System Overview Fenster ist also möglicherweise ein Fenster für Satistic Details,

63 4.3 Design 51 eines für System Parameters und eines für Thread Summary geöffnet. Diese Vielfalt überfordert den Benutzer - vor allem weil in jeder der Komponenten Details eines anderen Systems angezeigt werden können. Allein der Name des Systems in der Titelleiste gibt darüber Aufschluss, um welche Detaildaten es sich handelt. Redesign Webseiten bieten meist mehrere Wege (Links). Sie werden in einem Browser zusätzlich navigierbar gemacht: Es wird jeweils nur ein Weg vom Benutzer gewählt. Diese lineare Reihenfolge wird vom Browser erfasst und kann durch Buttons in der Toolbar zurück und dann wieder vorwärts gegangen werden. Der gesamte DB2 Performance Expert könnte in einem Fenster integriert werden. Ein Button zum Erreichen von System Overview ist bereits in der Toolbar jeder Komponente vorhanden, dieser entspricht dem Home-Button eines Browsers. Zugriff auf die Komponenten erfolgt in der integrierten Oberfläche, über weitere Buttons in der Toolbar oder eine Auswahl-Combo-Box. Eine weitere Combo-Box zur Auswahl des Systems steht zur Verfügung. Nach der Auswahl eines Systems in System Overview kann wie in einem Buch in den Komponenten dieses Systems geblättert werden. Diskussion + der Benutzer muss nicht mit mehreren Fenstern umgehen! die Information, wo sich der Benutzer befindet, muss deutlich angezeigt werden - die Systemauswahl über eine Combo-Box ist zu wenig präsent! der Baum von System Overview sollte immer sichtbar bleiben - das reduziert jedoch den Platz zur Anzeige der Komponenten - ist alles in einem Fenster integriert, können nicht mehr Counter aus verschiedenen Komponenten zur Analyse herangezogen werden; öffnet man dazu ein weiteres Fenster, wird mit dem Prinzip der integrierten Oberfläche gebrochen Wird ergänzt von Designvorschlag Note It und Designvorschlag Expertennavigation. Designvorschlag Note It Szenario Wenn ein Benutzer einen Counter von zwei oder mehreren Datenbanksystemen vergleichen möchte, muss er jeweils das System in System Overview und dann die Komponente auswählen. Die beiden Werte können nicht gleichzeitig betrachtet werden, da nur ein Fenster pro Komponente geöffnet wird. Der Benutzer muss sich also merken, was der erste Wert war, um ihn mit dem zweiten Wert zu vergleichen. Redesign Um die im Szenario beschriebene Aufgabe im ursprünglichen Design zu lösen, wird vermutlich ein Notizzettel benutzt. Dieser Notizzettel wird als Komponente in den DB2 Performance Expert eingefügt. Über das Kontextmenü kann dann jeweils ein Counter oder eine Countergruppe in den Notizzettel aufgenommen werden. Neben

64 52 Eine Navigation für den DB2 Performance Expert dem Namen des Counters und dem zugehörigen Wert gehören mindestens der Zeitstempel und der Name des Systems zu einer solchen Notiz. Da möglicherweise eine Reihe von Countern notiert wird, ist der Notizzettel für einen sinnvollen Vergleich sortierbar. Diskussion + alle Tester fanden diese Funktion sehr wichtig + Kombination von drei Funktionen: Notieren, Vergleichen und Navigieren - Ziel des Redesigns sollte es sein, Mängel zu beseitigen und nicht Notbehelfe des Benutzers in die Implementierung zu integrieren - die Vergleichsaufgabe des Benutzers wird zweigeteilt - erst muss er die Werte suchen, dann kann er sie vergleichen! sind notierte Counter Links, die den Counter in seinem Kontext öffnen, wird Note It zum Navigationskonzept! notierte Werte müssen mit aktuellen Werten synchronisiert werden Designvorschlag Expertennavigation Szenario Ein Telefonanruf, dass System D722 nicht ordnungsgemäß funktioniert, erreicht den Benutzer des DB2 Performance Experts. Daraufhin möchte dieser drei ihm namentlich bekannte Counter des Systems prüfen, weil die Fehlerbeschreibung darauf hindeutet, dass diese für das Problem verantwortlich sind. Er wählt D722 in System Overview aus und öffnet die Komponente Statistic Details. Darin sucht er zwei der Counter, die er prüfen möchte. Dann kehrt er zu System Overview zurück und öffnet die Komponente System Parameters, in der er den dritten Counter findet. Der Benutzer muss sehr viele Schritte ausführen, um seine Aufgabe zu erfüllen. Der Zugriff ist langsam. Redesign In Texteditoren, Hilfesystemen, auf Webseiten oder allgemein im WWW sind Suchen sehr nützlich, vor allem, wenn man genau weiß was man sucht. Zunächst muss in einer Combo-Box in der Toolbar von System Overview das System ausgewählt werden, in das navigiert werden soll. Abhängig von dieser Auswahl wird eine zweite Combo-Box gefüllt, in der der Benutzer den Counter, den er betrachten möchte, auswählt. Drückt er den Gehe-Zu-Button, so öffnet sich die Komponente, in der sich der Counter befindet, an der richtigen Stelle und mit markierter Selektion. Diskussion + unabhänging von jeder anderen implementierten Navigation! Nielsen bezeichnet Suchfunktionen als Alternativen zu Sitemaps [33]; in Tests wurde die Expertennavigation jedoch als eine Ergänzung des Designvorschlags Treemap gewünscht

65 4.3 Design 53! Counternamen im DB2 Performance Expert sind nicht eindeutig. Der Benutzer muss also nicht nur den Namen, sondern auch die zugehörige Countergruppe kennen Designvorschlag farbige Statusinformationen Szenario Überschreitet Counter A einen gewissen Wert, so ist ein Problem anzunehmen. In System Overview wird das Erreichen eines solchen Schwellwertes jedoch nicht angezeigt. Redesign Ein Desktopdrucker zeigt sowohl auf dem Bildschirm des Benutzers beim Drucken als auch durch eine kleine Lampe am Gerät an, wenn kein Papier mehr vorhanden ist. Die Systemrepräsentationen (im Baum oder in der Treemap) zeigen durch eine Farbe an, in welchem Zustand sich das System befindet. Die Ampelfarben Rot, Gelb, Grün und ihre Bedeutung sind für jeden eindeutig und werden deswegen eingesetzt, um Statusmeldungen zu visualisieren. Eine zusätzliche Farbe für Systeme, über die keine Informationen verfügbar sind, zum Beispiel weil sie gar nicht laufen, muss eingeführt werden. Grau erscheint dafür geeignet. Diskussion + sehr einfach und intuitiv + platzsparend und für eine große Menge an Datenobjekten geeignet + Führung des Benutzers (Event-Driven-Navigation)! Farbenblinde können mit dieser Codierung des Status nichts anfangen; für sie muss eine sekundäre Codierung angeboten werden - Farbe transportiert nur geringe qualitative Information, nämlich, dass mindestens ein Problem vorhanden ist; es wird keinerlei quantitative Aussage über die Anzahl der Probleme gemacht - der Zeitpunkt des Problems ist nicht ersichtlich Designvorschlag Treemap Szenario Der Benutzer muss in System Overview den Baum aufklappen, um alle Systeme zu sehen. Nur eine kleine Anzahl von Systemen kann gleichzeitig betrachtet werden. Der Fensterteil, in dem der Baum sich befindet, muss, wenn viele Systeme konfiguriert sind, gescrollt werden. Werden Statusinformationen im Baum angezeigt, verpasst der Benutzer diese möglicherweise, weil er sie nicht sieht. Bäume werden an vielen Stellen im DB2 Performance Expert zur Navigation eingesetzt, sind aber nicht unbedingt sinnvoll, so zum Beispiel in System Parameters, wo der Baum degeneriert ist und lediglich die Tiefe 1 hat.

66 54 Eine Navigation für den DB2 Performance Expert Die Ordner der Baumstruktur von System Overview (abgesehen von My Folders, der nicht weiter betrachtet wird) geben eine Struktur vor, die bereits durch verschiedene Icons für Multiplatform Instances, z/os Subsysteme und Gateways gegeben ist. Redesign Sitemaps auf Webseiten dienen der Navigation. Genauso wie Übersichtsfenster, zum Beispiel in Grafikprogrammen (vgl. Abbildung 4.4), erleichtern sie die Orientierung, obwohl darin wenig Details erkennbar sind. Abbildung 4.4: Adobe Photoshop Navigator und Denim Radar View Eine ähnliche Funktion im DB2 Performance Expert kann durch Treemaps 3.4.1, die auf den vorhandenen Bäumen aufbauen, implementiert werden. Abbildung 4.5: Erste Skizze zu System Overview (erstellt mit DEMAIS)

67 4.3 Design 55 Abbildung 4.5 zeigt eine erste Skizze für die Treemap in System Overview. Sie könnte durch einen Menüeintrag, einen Button in der Toolbar oder, wie in der Skizze dargestellt, auf einem eigenen Reiter (Tab) zugänglich sein. Abbildung 4.6: Treemap für System Overview (erstellt mit PowerPoint) Abbildung 4.6 zeigt eine weitere frühe Idee zum Thema Treemap in System Overview. Dabei geht es darum, alle konfigurierten Systeme in Applikationsgruppen zu ordnen und dann eine Selektion eines Systems oder einer ganzen Applikationsgruppe zu ermöglichen. Die Systemart sollte durch ein Icon visualisiert werden, der Status durch Farbe und mehr Information durch Mouseover zugänglich sein. Diskussion + man erkennt alles auf einen Blick + platzsparend und für eine große Menge an Datenobjekten geeignet, kein Scrollen + Statusfarben kommen darin gut zur Geltung + Memory-Effekt: der Mensch erinnert sich an Positionen und kann diese leicht wiederfinden - die hierarchische Struktur ist in Treemaps schwerer als im Baum erkennbar! die hierarchische Struktur der Bäume im DB2 Performance Expert ist für den Benutzer oft nicht besonders hilfreich oder erforderlich (relativiert vorhergehenden Minuspunkt)! erfordert einen Neuentwurf der Interaktion (vgl. Designvorschlag Mouseover) - manche Bäume im DB2 Performance Expert können nicht vollständig in einer Treemap abgebildet werden (vergleiche mit Abbildung 4.19)! Treemaps können als Alternative oder Ergänzung angeboten werden - Alternative heißt dabei nicht, dass der Baum ganz verschwindet, sondern nur, dass er nicht gleichzeitig mit der Treemap angezeigt wird. Ergänzung heißt, dass Baum und Treemap gleichzeitig angezeigt werden; dabei ist auf die Konsistenz der beiden Darstellungen zu achten. Ist mit Designvorschlag farbige Statusinformationen verknüpft.

68 56 Eine Navigation für den DB2 Performance Expert Designvorschlag Navigationsrahmen Szenario Die Treemap wird zur Navigation verwendet. Hat man sein erstes Ziel darin gefunden und klickt es an, verschwindet sie wieder. Werden dem Benutzer andere bekannte Navigationsmittel weiterhin angeboten, wird er aus Gewohnheit diese weiter benutzen und nicht wieder mithilfe eines Buttons in der Toolbar auf die Treemap wechseln. Die Treemap muss für den Benutzer präsenter sein. Redesign Muster werden vom Menschen sehr gut wiedererkannt. Eine Treemap bildet mit ihren Farben und Grenzen zwischen den Flächen ein solches Muster. Abbildung 4.7: Navigationsrahmen (Powerpoint Prototyp)

69 4.3 Design 57 Das Muster der Treemap wird, wie in Abbildung 4.7 dargestellt, im Rahmen eines Fensters widergespiegelt. Dadurch ist das Vorhandensein der Treemap für den Benutzer immer offensichtlich. Durch Anklicken des Rahmens kann er zu der Treemap gelangen. Diskussion! Verschiedene Treemaps erzeugen verschiedene Muster, also müssten auch verschiedene Rahmen implementiert werden + durch einen eindeutigen Rahmen erhält der Benutzer zusätzliches Feedback darüber, wo er sich im DB2 Performance Expert befindet + direkter Zugriff auf die Übersichtsfunktion - die Darstellung mit dem Rahmen wirkt unruhig Designvorschlag Zoom Szenario Der für eine Treemap verfügbare Platz lässt bei einer umfangreichen Treemap nicht zu, dass der Name auf den Flächen der Treemap angezeigt wird. Redesign Früher benutzte man eine Lupe, um die Straßennamen einer Landkarte zu lesen. Elektronische Landkarten benutzen einen Zoom. Auch in Gruppen einer Treemap kann hineingezoomt werden, dadurch steht mehr Platz für die einzelnen Einträge zur Verfügung und der Name z. B. kann direkt ohne Interaktion angezeigt werden. Wie im Acrobat Reader steht ein Zoom In Tool und Zoom Out Tool zur Verfügung. Die Verwendung der auch aus Grafikprogrammen bekannten Lupe zum Zoomen fügt dem DB2 Performance Expert ein zusätzliches Bedienungskonzept hinzu, nämlich, dass man erst ein Werkzeug zur Interaktion auswählen muss. Dies sollte vermieden werden. Hineinzoomen könnte allein durch Anklicken des Rahmens erreicht werden. Hinauszoomen hingegen wäre durch Anklicken eines zusätzlich eingeführten äußeren Rahmens oder durch bekannte Formen wie einen Toolbarbutton und einen Menüeintrag oder Kontextmenüeinträge erreichbar. Ist die klassische Baumdarstellung parallel zur Treemap sichtbar, kann auch darüber der Zoom realisiert werden: Es wird immer der im Baum ausgewählte Ordner als Treemap angezeigt. Diskussion + Detailinformationen und Wahrung der Treemap + gut bei vielen Datenobjekten, die bei der Vollansicht zu klein werden + geeignet zum Drilldown bei Auftreten eines Events (Event-Driven-Navigation) - nicht intuitiv - die Lupe ist bekannt, nicht visuell dargestellte Zoomfunktionalität muss erlernt und erinnert werden

70 58 Eine Navigation für den DB2 Performance Expert - Verlust des Überblicks - Verlust eines Teils des Kontexts Designvorschlag Mouseover Szenario Die Treemap gibt dem Benutzer einen Überblick über den Status aller durch Flächen repräsentierten Objekte. Navigiert der Benutzer durch zum Beispiel Doppelklick in ein solches Objekt, verliert er den Gesamtüberblick. Redesign Fokus & Kontext bedeutet, dass bei detaillierterer Betrachtung eines Objektes der Kontext nicht verschwindet, das Objekt selbst aber in den Fokus gerückt wird und mehr Details dazu betrachtet werden können. Dieses Prinzip führte zum Design der Mouseover-Interaktion mit der Treemap. Man kann annehmen, dass der außerhalb der Norm liegende Wert, der die Farbe einer Fläche in der Treemap auf rot oder gelb setzt, das ist, was den Benutzer interessiert. Weiter wird davon ausgegangen, dass bereits eine kurze Information den Benutzer befriedigt. Diese Information kann beim Bewegen der Maus über eine Fläche in der Treemap in einem so genannten Mouseover gegeben werden. Es erfolgt keine Navigation weg von der Treemap. Ein Mouseover wird ähnlich einem Tooltip über allem anderen angezeigt. Im Gegensatz zum Tooltip kann es bei Bedarf selbst als Interaktionsobjekt dienen. Diskussion + Mouseovers sind intuitiv, sie werden bei der Exploration einer Software schnell entdeckt + der Kontext der Systeme bleibt erhalten - der Benutzer befindet sich weiterhin in System Overview und braucht kein gedankliches Modell aufzubauen, wie er wieder dahin zurückfindet + wird die Maus von dem System wegbewegt, verschwindet das Mousover automatisch, keine weitere Navigation des Benutzers ist erforderlich + der Zugriff auf die Information erfolgt sehr schnell + durch die im Mouseover angezeigte Information werden die nächsten Schritte des Benutzers bestimmt + das Mouseover ist selbst Interaktionsobjekt (Links), Darstellung und Navigation sind vereint + Links sind ein bekanntes Konzept! sowohl als Nachteil, also auch als Vorteil wirkt, dass nur begrenzter Platz zur Darstellung der Information zur Verfügung steht - die angezeigte Information wird gefiltert - ein Teil des Kontextes wird durch das Mouseover verdeckt

71 4.3 Design 59 Im Abschnitt 4.4 Spezifikation wird eine Variante von halbtransparenten Mouseovers präsentiert, die den Kontext nicht verdecken. Designvorschlag Aufgabenliste Szenario In der Treemap von System Overview erkennt der Benutzer möglicherweise mehrere Systeme, die seiner Aufmerksamkeit bedürfen. Er braucht die Möglichkeit, diese zu ordnen und nacheinander abzuarbeiten. Abbildung 4.8: Papierprotoyp der Aufgabenliste Redesign Die Aufgabenliste ist eine Weiterentwicklung des Designvorschlags Note It. Sie ist stark mit der in enthaltenen Spezifikation des Designvorschlags Treemap für System Overview verknüpft. Im Kontextmenü einer jeden Systemrepräsentation kann der Benutzer den Eintrag add to TaskList... wählen. Daraufhin erscheint ein Dialog, in dem der Benutzer keine bis alle der den Systemzustand betreffenden Nachrichten (Messages) auswählen kann. Diese werden zusammen mit einem optional einzugebenden Kommentar in die Aufgabenliste aufgenommen. Die Aufgabenliste ist als zusätzlicher Reiter in System Overview vorhanden. Sie bietet zwei Sichten: Eine tabellarische Darstellung entsprechend dem Designvorschlag Note It und eine grafische wie in Abbildung 4.8 skizziert.

72 60 Eine Navigation für den DB2 Performance Expert Oberhalb eines von links nach rechts gehenden Zeitstrahls wird für jeden vom Benutzer vorgenommenen Eintrag in die Aufgabenliste eine quadratische Systemrepräsentation eingefügt. Mit dieser kann, wie mit der Systemrepräsentation in der Treemap, interagiert werden. Der Unterschied zum System in der Treemap ist, dass es sich nicht um den aktuellen Status des Systems handelt, sondern um einen Snapshot von Status und Countern zu dem Zeitpunkt, als der Eintrag in die Aufgabenliste vorgenommen wurde. Das Strichmännchen auf den Systemen oberhalb des Zeitstrahls verdeutlicht, dass es sich um einen vom Benutzer vorgenommenen Eintrag handelt. Unter dem Zeitstrahl sieht man diagonal geteilte quadratische Systemrepräsentationen. Sie werden jedes Mal, wenn sich der Status eines Systems ändert, automatisch vom DB2 Performance Expert in die Aufgabenliste eingetragen. Die obere Ecke zeigt den Status des Systems vor dem Snapshot an, die untere den Status danach. Diskussion + vergleiche Designvorschlag Note It + gleiche Interaktion wie Treemap - kein Lernaufwand! durch Filterfunktionen auf die grafische Darstellung der Aufgabenliste kann der Benutzer seine Aufgaben schnell definieren! werden Komponenten aus der Aufgabenliste heraus geöffnet, muss deutlich gemacht werden, dass es sich um Snapshotdaten handelt, zum Beispiel durch eine Veränderung der Fensterfarben - hoher Aufwand für Halten und Organisieren der Snapshotdaten Designvorschlag Landmarks Szenario Der DB2 Performance Expert stellt fast alle zur Verfügung stehende Information textuell dar. Der Benutzer muss viel lesen, um etwas wiederzufinden. Redesign Abbildung 4.9 zeigt eine Treemap für Statistic Details, in der jeder Countergruppe ein Icon zugeordnet wurde. Dieses dient als Landmarks zur Wiedererkennung. Diskussion + es muss nicht gelesen werden + durch die angezeigten Icons weiß der Benutzer, in welcher Komponente er sich befindet - sehr viele Icons müssen erinnert und zugeordnet werden

73 4.3 Design 61 Abbildung 4.9: Powerpoint Skizze der Treemap in Statistic Details Designvorschlag Animation Szenario Die Datenobjekte im DB2 Performance Expert (Systeme oder Counter) verändern sich. Der Benutzer braucht eine Möglichkeit, diese Veränderung nachzuvollziehen. Dieses betrifft einzelne Counter, deren Werte sich verändern oder auch die Statusfarben der Systeme in der Treemap. In fast allen Komponenten besteht bisher die Möglichkeit, mit einer Zeitachse (Abbildung 4.10) Snapshotdaten abzufragen. Redesign Abbildung 4.10: Zeitachse in Statistic Details Durch eine Funktion in der Toolbar oder Menüleiste lässt sich ein vorher spezifizierter Zeitabschnitt im Zeitraffer anschauen. Die sich verändernden Werte in der betrachteten Darstellung werden dabei hervorgehoben. Bei der Animation der System Overview Treemap, wie sie in Abschnitt 4.4 spezifiziert ist, besteht das Highlighten darin, das Mouseover des sich verändernden Systems anzuzeigen.

74 62 Eine Navigation für den DB2 Performance Expert Diskussion + einfache Bedienung + im Gegensatz zur Aufgabenliste wird keine neue Darstellung benutzt - zusätzliche Kontrollfunktionen für das Starten, Stoppen und Pausieren der Animation erforderlich Ausgewähltes Design Das Konzept der Treemap und einige der damit verbundenen Designvorschläge wurden aufgrund der Diskussion für den mit Mitteln der Navigation redesignten Prototypen des DB2 Performance Experts ausgewählt. In der Spezifikation (Abschnitt 4.4) werden diese Designvorschläge weiter ausgearbeitet und ihre Implementierung im Prototypen durch Screenshots illustriert. 4.4 Spezifikation Im vorhergehenden Abschnitt wurden verschiedene Möglichkeiten für das Redesign des DB2 Performance Experts diskutiert. Dieser Abschnitt stellt die später implementierten Designvorschläge im Detail vor. Die Funktionalität wird anhand von Screenshots des Prototypen erläutert. Implementiert wurden zwei Treemaps, die im Folgenden als Monitor Maps bezeichnet werden. Sie dienen der Navigation der im DB2 Performance Expert enthaltenen Daten System Overview Abbildung 4.11 zeigt einen Screenshot System Overview. In der unteren Fensterhälfte sieht man die Systemtabelle, links den klassischen Baum und rechts die Monitor Map. Bis auf Letzteres sind alle Elemente des Fensters, auch Menü und Toolbar, gleich geblieben. Ohne mit der Monitor Map zu interagieren, lassen sich folgende Elemente und Eigenschaften erkennen: Quadrate in den Farben Grau, Grün, Gelb und Rot sich verändernde Farben weiße betitelte Rahmen, so genannte Groupboxes, zur Gruppierung der farbigen Quadrate, die den Ordnern im Baum entsprechen Hintergrundfarbe der Groupboxes: je tiefer in der Hierarchie, desto blauer Zusammenhang zwischen Blattknoten pro Ordner im Baum und Quadraten pro Groupbox in der Monitor Map

75 4.4 Spezifikation 63 Abbildung 4.11: System Overview Monitor Map Die Farben stehen für: grau nicht eingeloggt, keine Zustandsinformationen verfügbar grün keine Warn- oder Alarmmeldungen für das System sind vorhanden gelb eine oder mehrere Warnmeldungen für das System sind vorhanden rot mindestens eine Alarmmeldung, möglicherweise auch eine oder mehrere Warnmeldungen (gelb) für das System sind vorhanden Diese Bedeutung der Farben ist in unserem Kulturkreis üblich, muss jedoch zum Verständnis der Monitor Map nochmals bestätigt bzw. gelernt werden. Gelernt wird durch Exploration, ein Handbuch oder eine elektronische Form der Hilfe. Interaktion mit der System Overview Monitor Map Mouseover Mit der Monitor Map kann mit einem Mouseover über die Systeme, mit Mausklicks in Flächen und auf Systeme und über den Baum interagiert werden. Bringt man die Maus über eines der Systeme in der Monitor Map, erscheint relativ zu dem Mauszeiger ein Fenster (Mouseover), wie in Abbildung 4.12 dargestellt. Ein blauer Rahmen markiert das selektierte System.

76 64 Eine Navigation für den DB2 Performance Expert Abbildung 4.12: Mouseover in System Overview Im Titelbalken des Mouseovers ist der Name des Systems angegeben. Seine Balkenfarbe gibt den Systemstatus wieder. Handelt es sich um ein System, auf dem der Benutzer nicht eingeloggt ist (grau), so erscheint vor dem Namen im Titelbalken ein Icon, das den Serverstatus wiedergibt. Dieses Icon wird in der ersten Spalte der Systemtabelle ebenfalls verwendet und erlaubt Rückschlüsse darauf, ob es möglich ist, sich auf dem System einzuloggen. Das Mouseover hat zwei Inhaltsgruppen, zum einen eine Name-Wert Liste mit Informationen zum System, zum anderen eine Liste mit Messages. Messages sind vom DB2 Performance Expert erzeugte Nachrichten über den Systemzustand. Man unterscheidet zwischen Warnung und Alarmzustand. Ein gelbes oder rotes Icon gibt Auskunft darüber. Es kann mehrere Messages für ein System geben. Im Prototyp wird davon ausgegangen, dass diese Messages durch über- oder unterschrittene Schwellwerte bestimmter Counter ausgelöst werden. In diesem Fall besteht die Nachricht aus dem Namen des Counters und seinem aktuellen Wert. Die Messages sind blau und unterstrichen. Analog zu der aus dem WWW bekannten Darstellung handelt es sich um Links. Wenn der Benutzer darauf klickt, öffnet sich eine der Komponenten des DB2 Performance Experts in einem neuen Fenster, in dem die angezeigte Message im Detail und im Kontext betrachtet werden kann. Der Link gibt keinen Aufschluss darüber, welche Komponente sich öffnen wird. Doppelter Mausklick links Bei Doppelklick auf ein gelbes oder rotes System erscheint ein kleines modales Fenster mit den Messages des angeklickten Systems (siehe Abbildung 4.13). Der Benutzer

77 4.4 Spezifikation 65 Abbildung 4.13: Doppelklick Auswahlfenster in System Overview wird aufgefordert darin den Counter auszuwählen, den er betrachten möchte. Angezeigt werden dieselben Messages, wie im Mouseover, ergänzt durch die Information in welcher Komponente sich der Counter befindet. Die Messages sind ebenfalls blau und unterstrichen und sind funktionierende Links. Das Doppelklick-Auswahlfenster verschwindet bei der Auswahl eines Links. Wird das Fenster über das Kreuz in der rechten oberen Ecke geschlossen, wird die Auswahlaktion abgebrochen. Abbildung 4.14: Markierte und unmarkierte Systeme in System Overview Einfacher Mausklick links Klickt man mit der linken Maustaste auf ein System, so wird dieses mit einem Haken markiert (vgl. Abbildung 4.14). Klickt man auf ein bereits markiertes System, verschwindet der Haken wieder. Dem Benutzer steht frei, zu welchem Zweck diese Markierung verwendet wird. Im Prototypen ist keine weitere Aktion damit verknüpft. Ein einfacher Mausklick in die freien blauen Flächen löst einen Zoom in die gewählte Gruppe aus. Abbildung 4.15 zeigt einen Zoom auf die Gruppe z/os. Sofern mehr Platz zur Verfügung steht, werden auch die Systeme größer, wodurch zusätzliche Information, wie zum Beispiel der Name angezeigt werden kann. Mit dem gezoomten Ausschnitt kann in gleicher Form interagiert werden wie mit der nicht gezoomten Monitor Map. Der Zoom ist nur für die Gruppe z/os im Prototypen implementiert. Menü- oder Toolbareinträge zum Hinauszoomen wurden nicht angelegt. Interaktion über den Baum Wird ein Ordner im Baum ausgewählt, so zeigt die Monitor Map nur den Inhalt dieses Ordners an. Der zusätzlich verfügbare Platz wird von den Systemen ausgenutzt, indem alle Systeme größer werden. Falls möglich werden Zusatzinformationen darauf angezeigt. Zuerst ist das der Name, ist noch mehr Platz verfügbar kommen Messagelinks hinzu. Es handelt sich um dieselbe Form des Zooms wie oben beschrieben. Klickt man auf ein System, so wird nur dieses System angezeigt. Der verfügbare

78 66 Eine Navigation für den DB2 Performance Expert Abbildung 4.15: Zoom auf z/os Platz wird ausgenutzt für Zusatzinformationen, Messagelinks und Zugriff auf die Komponenten. Bei Systemen, auf denen man nicht eingeloggt ist, erscheint ein Link zum Logon-Dialog. Diese Funktion ist im Prototypen nur angedeutet. Einfacher Mausklick rechts Wird die rechte Maustaste über einem System gedrückt, erscheint ein Kontextmenü. Es entspricht bis auf die ersten drei Punkte dem Kontextmenü der Systemknoten im Baum. Über das Submenü Monitor lassen sich alle Komponenten des Systems erreichen. Der erste Eintrag Open message enthält ein dynamisches Menü aller für dieses System aktuellen Messages. Die Auswahl einer Message öffnet, wie bei den Links im Mouseover oder dem Doppelklick-Auswahlfenster, die entsprechende DB2 Performance Expert-Komponente. Die Einträge add to TaskList... und add all to TaskList deuten die im Prototypen nicht implementierte Taskliste an (vgl. Abschnitt Design 4.3) Statistic Details Abbildung 4.16 zeigt auf der linken Seite die ursprüngliche Sicht auf Statistic Details und rechts einen Screenshot der Monitor Map im Prototypen. Es handelt sich dabei um eine alternative Sicht, die über einen Button in der Toolbar erreicht werden

79 4.4 Spezifikation 67 Abbildung 4.16: Statistic Details: Ursprüngliches Design und alternative Monitor Map kann. Der Button ist im linken Screenshot mit einem blauen Kreis markiert. Die Monitor Map spiegelt alle Baumeinträge wieder. Jeder Knoten des Baumes wird durch eine Fläche in der Monitor Map dargestellt. Einem Knoten im Baum und analog einer Fläche in der Monitor Map ist jeweils eine Gruppe von Countern zugeordnet. Die 18 Knoten der ersten Ebene sind repräsentiert durch 18 große Flächen, die in drei Reihen zu je sechs Flächen angeordnet sind. Reihenfolge ist dabei Leserichtung, d. h. von links oben zeilenweise nach rechts unten. Dieses Layout entspricht nicht dem der klassischen Treemap, bei der die erste Ebene entweder spalten- oder zeilenweise angeordnet ist. An Quadrate angenäherte Flächen wurden gewählt, weil diese besser selektierbar sind. Durch die gleiche Größe ist es leicht zu erkennen, dass es sich um die gleiche Hierarchiestufe handelt. Flächen, die Blattknoten des Baumes repräsentieren, haben keine weitere Unterteilung. Die rote Fläche, in der in Abbildung 4.16 rechts dargestellten Monitor Map, ist nicht unterteilt und repräsentiert einen Blattknoten. Der zu der grünen Fläche daneben gehörende Ordnerknoten ist viergeteilt. Die obere Hälfte der Fläche repräsentiert den Knoten selbst, in der unteren Hälfte sind drei darunter liegende Blattknoten dargestellt. Diese Hierarchiedarstellung ist nicht optimal, wird jedoch mithilfe der im nächsten Abschnitt beschriebenen Mouseoverinteraktion deutlicher. Die Flächen der Monitor Map in Statistic Details können drei Farben haben: grün bedeutet, dass in der von dieser Fläche repräsentierten Countergruppe keiner der Counter einen gesetzten Schwellwert überschritten hat gelb steht für einen oder mehrere Counter in der Gruppe, die gesetzte Warnstufen überschritten haben rot bedeutet, dass mindestens ein Counter eine Alarmstufe überschritten hat und möglicherweise auch ein oder mehrere Warnstufen erreicht sind

80 68 Eine Navigation für den DB2 Performance Expert Abbildung 4.17: Mouseover in der Monitor Map von Statistic Details Interaktion mit der Statistic Details Monitor Map Die Interaktion mit der Monitor Map in Statistic Details umfasst drei Formen: Mouseover, Einfachklick und Doppelklick. Mouseover Befindet sich die Maus über einer Fläche der Monitor Map, dann erscheint ein halbtransparentes Mousover über der Monitor Map. Das Mouseover enthält die gleichen Daten, die in der ursprünglichen Sicht rechts vom Baum erscheinen, wenn man einen Knoten auswählt. Die Größe des Mouseovers wird bestimmt durch die Größe dieses Datenfeldes. Der Default für die Position der linken oberen Ecke des Mouseovers ist die Mauszeigerposition. Kann das Mouseover an dieser Position verankert, nicht ganz über der Treemap angezeigt werden, wird seine Position verschoben, bis seine ganze Fläche sichtbar ist. Ist das Fenster von Statistic Details so klein, dass das Mouseover, selbst wenn es den ganzen Platz ausnutzt, nicht ganz angezeigt werden kann, so erscheint es gar nicht. In diesem Fall wird lediglich ein blauer Selektionsrahmen um die Fläche angezeigt. Um die zugehörigen Daten zu sehen, muss die Monitor Map vergrößert werden. Der Selektionsrahmen wird immer, auch wenn das Mouseover sichtbar ist, angezeigt. Er dient zusätzlich zur Erkennung der hierarchischen Struktur einer Fläche (vgl. Abbildung 4.18). Hat eine selektierte Fläche die Farbe gelb oder rot, so bedeutet das, dass ein oder mehrere Schwellwerte von Countern in der repräsentierten Countergruppe überschritten wurden. Im Mouseover erkennt man anhand von entsprechenden farbigen Markierungen, um welche Werte es sich handelt (vgl. Abbildung 4.17). Einfacher Mausklick links Klickt man mit der linken Maustaste einmal auf eine Fläche der Monitor Map,

81 4.5 Entwurf und Implementierung 69 Abbildung 4.18: Selektion in Statistic Details verändert sich das Mouseover. Es wird undurchsichtig, sodass sein Inhalt besser lesbar wird. Wird die Maus auf eine andere Fläche in der Monitor Map bewegt, verschwindet dieser Effekt wieder. Doppelter Mausklick links Doppelklickt der Benutzer auf eine Fläche der Monitor Map, wechselt die Sicht. Im Baum zur Linken ist dann der Knoten ausgewählt, der zu der Fläche, die geklickt wurde, gehört. Auf der rechten Seite wird die Countergruppe angezeigt, die vorher im Mouseover zu sehen war. 4.5 Entwurf und Implementierung Die Aufgabenstellung (siehe 4.1.1) verlangte, dass der Prototyp, wie der DB2 Performance Expert selbst, in Java implementiert wird. Nicht alle Teile der Benutzungsoberfläche werden in das Redesign miteinbezogen. Der Prototyp sollte in den bestehenden Produktcode eingefügt werden. Es war nicht gefordert, dass es sich dabei um eine saubere Integration in die Architektur handelt. Der Prototyp soll die entworfene Funktionalität demonstrieren und muss sie dafür nicht vollständig implementieren, sondern darf sie sogar simulieren. Modularität, Erweiterbarkeit und Wiederverwendbarkeit spielen keine Rolle Entwurf Oben genannte Anforderungen machten einen Architekturentwurf unnötig. Die für diese Aktivität im Softwareentwicklungsprozess veranschlagte Zeit wurde darauf verwendet, sich in die bestehende Architektur einzuarbeiten. Es ging darum, herauszufinden, über welche Schnittstellen die für die Monitor Maps benötigten Daten abgefragt werden können und an welcher Stelle sich der Code für die Monitor Maps selbst einfügen lässt. Der dadurch entstandene Aufwand war sehr hoch, da der Code

82 70 Eine Navigation für den DB2 Performance Expert des DB2 Performance Experts in einer sehr komplexen Architektur implementiert ist. Generische Konstrukte, die der Erweiterbarkeit dienen, erfordern eine lange Einarbeitungszeit und machen den Code zunächst schwer lesbar und kaum verständlich Implementierung System Overview Die Monitor Map in System Overview wird folgendermaßen erstellt: Im ersten Schritt wird der Wurzelknoten des darzustellenden Baumes (detailnode) und das zugrunde liegende Panel (rootpanel) einer rekursiven Funktion Namens addsubpanel übergeben. Darin werden nacheinander die Kinder des Wurzelknotens durchlaufen: Handelt es sich um einen Ordnerknoten, so wird ein Panel erzeugt und dessen Farbe und Titel gesetzt. Dieses Ordnerpanel wird zu dem im Parameter übergebenen Panel (rootpanel) hinzugefügt. Hat der Ordner Kindknoten, so ruft die Funktion sich selbst mit dem Ordnerknoten als detailnode und dem daraus erzeugten Panel als rootpanel Parameter auf. Wird in der Funktion beim Durchlaufen ein Blattknoten, also ein System gefunden, so wird das dazu gehörende Panel erzeugt. Verschiedene Attribute wie Farbe und Name werden darauf gesetzt. Es wird unterschieden zwischen dem ersten Auftreten eines Systems und einem Shortcut. Die erzeugte Monitor Map wird mithilfe der Funktion layoutpanel angeordnet. Zum Layout von Ordnern in Ordnern wird ein BoxLayout verwendet, Systempanels erhalten ein FlowLayout. Die Funktion changecolor wird von einem Timer regelmäßig aufgerufen. Es wird zufällig ein nicht graues Systempanel ausgewählt und seine Farbe und gegebenenfalls die Farbe der zugehörigen Shortcuts geändert. Es handelt sich bei der gewählten Statusfarbe im Prototypen um eine reine Simulation. Eine Reihe von weiteren Funktionen, die implementiert wurden, dienen der Interaktion mit der Monitor Map. Sie werden aufgerufen aus MouseListenern, die den System- oder Ordnerpanels zugeordnet sind. Eine Besonderheit in der Implementierung sei hier noch erwähnt: Es handelt sich dabei um einen Timer, der aufgerufen wird, sobald die Maus ein Systempanel verlässt. Wird nicht innerhalb von 700 Millisekunden das angezeigte Mouseover mit der Maus erreicht, so verschwindet dieses. Diese Verzögerung musste implementiert werden, damit der Benutzer das Mouseover-Panel erreichen kann. Statistic Details Die Layoutfunktion der Monitor Map in Statistic Details ordnet die erste Baumebene in einem sechsspaltigen GridLayout an. Existieren Kindknoten, so wird in das Panel der ersten Ebene ein Panel eingefügt, welches das Elternpanel zweiteilt. Die Kindknoten werden in einem einspaltigen GridLayout in dieses neue, im Elternpanel enthaltene Panel eingefügt. Dieses Layout ist keine sehr gute Darstellung der Hierarchie.

83 4.5 Entwurf und Implementierung 71 Tree Map A1 A1 B1 B2 B3 A3 A2 B1 B2 B3 A1 A2 A3 B1 A2 B2 B1 A3 B3 B2 A2 A3 B3 Abbildung 4.19: Treemap Prinzip, Venn-Diagramme, Slice & Dice Treemaps Ein klassischer Treemap Algorithmus wie zum Beispiel Slice & Dice wurde aus zwei Gründen nicht angewandt: 1. Slice & Dice teilt zum Beispiel die ungeraden Hierarchieebenen vertikal und die geraden horizontal. Im Falle des Baumes von Statistic Details würde das bedeuten, dass die erste Ebene aus 18 schmalen Spalten bestehen würde. Im Abschnitt Spezifikation wurde erklärt, dass durch die implementierte Lösung mit drei Zeilen für die erste Ebene 18 selektierbarere Flächen entstehen. 2. Die zweite Schwierigkeit mit Slice & Dice wird in Abbildung 4.19 deutlich: Nur Blattknoten werden von diesem Algorithmus als Flächen dargestellt. Die Treemap rechts unten enthält keine Fläche A1, diese setzt sich implizit aus B1, B2 und B3 zusammen. Für Statistic Details bildet das ein Problem, da auch den Ordnern im Baum jeweils eine Countergruppe zugeordnet ist. Ein sinnvoller Treemap Algorithmus für Statistic Details erfordert die Elimination der Ordner mit zugehöriger Detailsicht durch ein Redesign der Daten. Die implementierte Lösung für zu schmale Flächen, nämlich das Verteilen auf mehrere Zeilen, kann beibehalten werden. Interessant bei der Implementierung von Statistic Details sind die halbtransparenten Mouseovers. An dieser Stelle wird kurz erklärt, wie dieser Effekt in Java implementiert war. Zunächst werden alle Komponenten einem Container hinzugefügt und darin angeordnet. Der Container mitsamt seinen Komponenten wird danach durch folgende Funktion halbtransparent:

84 72 Eine Navigation für den DB2 Performance Expert public void settransparency(component component, int transparency){ Color color = component.getbackground(); Color newcolor = new Color(color.getRed(), color.getgreen(), color.getblue(), transparency); component.setbackground(newcolor); if (component instanceof Container){ Container container = (Container)component; Component[] children = container.getcomponents(); for (int i=0; i < container.getcomponentcount(); i++){ settransparency(children[i], transparency); } } } Die Funktion erhält die transparent zu machende Komponente und den Transparenzwert (Alphawert zwischen 0 und 255) als Übergabeparameter. Die Farbe der Komponente wird auf eine neue Farbe, bestehend aus den Rot-, Grünund Blau-Anteilen der ursprünglichen Farbe und dem übergebenen Alphawert, gesetzt. Handelt es sich bei der Komponente um einen Container, der wiederum Komponenten enthält, so werden diese rekursiv genauso behandelt. In Statistic Details wurde ein Alphawert von 120 gewählt Zusammenfassung Entwurf und Implementierung Es handelt sich bei dem in diesem Projekt entstandenen Code um einen Wegwerfprototypen. Er dient einzig und allein dazu, eine mögliche Implementierung des Monitor Map Konzeptes zu demonstrieren und die Machbarkeit zu beweisen. Diesen Zweck hat er erfüllt. 4.6 Evaluierung Die entworfene und prototypisch implementierte Navigation im DB2 Performance Expert wurde zum Abschluss des Projektes verschiedenen Tests unterzogen. Deren Art, Aufbau und Auswertung werden in diesem Abschnitt beschrieben Evaluierungsmethoden Zur Evaluierung des DB2 Performance Experts wurden verschiedene Evaluierungsmethoden verwendet. Diese lassen sich einteilen in Methoden mit Benutzerbeteiligung und Methoden ohne Benutzerbeteiligung. Die in Tabelle 4.3 aufgeführten und in der Evaluierung benutzten Methoden prüfen die Funktionen des Prototypen hinsichtlich deren Bedienbarkeit. Der Schwerpunkt der Implementierung lag darin, viele Funktionen der Treemap im Prototypen zu zeigen. Die einzelnen Funktionen wurden dabei nur soweit ausgearbeitet, wie es zur Evaluierung der Bedienung notwendig ist.

85 4.6 Evaluierung 73 mit Benutzerbeteiligung Usability Tests Experten-Walkthroughs Ad-Hoc Tests ohne Benutzerbeteiligung Heuristische Evaluierung Tabelle 4.3: Zur Evaluierung des DB2 Performance Experts angewandte Methoden Als Usability Test werden hier durch Fragebögen standardisierte und strukturierte Benutzertests bezeichnet. Sie dienen dazu, eine quantitative Basis zur Bewertung des Prototypen zu erheben. In den Experten-Walkthroughs wurden im Hinblick auf den DB2 Performance Expert oder das Thema Usability besonders geschulte Tester um ein Feedback gebeten. Als Ad-Hoc Tests bezeichnet man nicht standardisierte Tests, die während der Entwicklung des Prototypen häufig durchgeführt werden. Dabei werden bereits frühe Skizzen und Papierprototypen mit Benutzern in einem informellen, nicht standardisierten Gespräch diskutiert. Auf Grundlage dieser Diskussion wird, wenn mehrere Designvorschläge vorhanden sind, derjenige ausgewählt, welcher in dem endgültigen Prototypen realisiert werden soll. Die unterschiedlichen Hintergründe der Tester (DB2 Performance Expert-Kenner, Power PC-User, Informatiker, Psychologe) liefern wichtige Erkenntnisse. Ohne Beteiligung von anderen Personen wurde eine heuristische Evaluierung durchgeführt. Dabei wurde der Prototyp anhand einer allgemeinen Kriterienliste bewertet. Bis auf die Ad-Hoc Tests wurden alle Tests in der letzten Iteration des Projektes durchgeführt, d. h. die Ergebnisse dieser Tests sind nicht in die Entwicklung des Prototypen eingegangen. Im folgenden Abschnitt werden die durchgeführten Tests beschrieben. Die Auswertung der Tests erfolgt im Abschnitt Die Ergebnisse werden dabei nicht explizit den einzelnen Tests zugeordnet, sondern thematisch zusammengefasst Beschreibung der Tests In der Beschreibung der Tests wird neben einer Beschreibung des Ablaufes Auskunft über Versuchspersonen, Testdauer, Materialien, unabhängige und abhängige Variablen gegeben. Variablen beeinflussen die Auswertung eines Testes. Als unabhängige Variablen bezeichnet man zum Beispiel Eigenschaften der Tester, aber auch vom Testleiter geschaffene Testvoraussetzungen. Abhängige Variablen sind während dem Test erhobene Daten. Usability Test mit Fragebögen Versuchspersonen (Tester) Die Teilnehmer der Tests wurden hauptsächlich im IBM-Labor für Forschung und Entwicklung in Böblingen rekrutiert. Dort befand sich auch das Testlabor.

86 74 Eine Navigation für den DB2 Performance Expert Die Tabelle 4.4 fasst Informationen über die Tester der Usability Tests und Experten- Walkthroughs zusammen. Usability Test # Tester Altersgruppen 10 7mal mal mal Usability DB2 Performance Kenntnisse Expert-Kenntnisse 5 von 10 6 von 10 Tabelle 4.4: Testteilnehmer Usability Test Testdauer jeweils eine bis anderthalb Stunden Materialien Windows-Rechner mit installiertem DB2 Performance Expert Prototyp Server mit Datenbanken, auf die vom Prototypen aus zugegriffen werden kann Demo-Film Rechner, auf dem das Testprotokoll mitgeschrieben wurde Fragebögen Unabhängige Variablen Die Tester arbeiten hauptsächlich im IBM-Labor und damit in räumlicher Nähe des Testlabors - dadurch wurde die Testteilnahme vereinfacht. Daneben waren Wissen über Software Ergonomie (Usability Kenntnisse) und Kenntnis des DB2 Performance Experts oder zumindest ein Grundverständnis der behandelten Thematik wichtige Auswahlkriterien. Alle Testpersonen sind mit dem Betriebssystem Windows vertraut, einige davon haben Erfahrung mit Linux, zwei der Testpersonen benutzen regelmäßig einen Mac. Bis auf eine Person waren alle Testpersonen männlich. Abhängige Variablen Zu den abhängigen Variablen gehören die ausgefüllten Fragebögen und ein Protokoll des Testleiters, in dem das laute Denken des Testers festgehalten wurde. Beschreibung Der folgende Abschnitt gibt einen Überblick über den stets gleichen Ablauf der Usability Tests und beschreibt dabei auch, warum der Test in dieser Form aufgebaut wurde. Abbildung 4.20 zeigt den Ablauf der durchgeführten Usability Tests mit Fragebögen. Die zehn Tester wurden in zwei Gruppen zu jeweils fünf Personen eingeteilt. Gruppe 1 bestand aus Personen, die den Prototypen zum ersten Mal im Test gesehen haben. Einige Personen in Gruppe 2 hatten vor dem Usability Test bereits an Ad-Hoc-Tests

87 4.6 Evaluierung 75 Aufbau der Benutzertests Begrüssung & Testeinf+ührung Angaben zur Person Exploration - System Overview A1 Exploration System Overview Exploration - Statistic Details A2 Exploration - Statistic Details A3 Exploration - Erster Eindruck VIDEO: Monitor Maps Exploration B1 System Overview - Aufgaben B2 System Overview - Aufgabenfragebogen B3 Statistic Details - Aufgaben B4 Statistic Details - Aufgabenfragebogen B5 Letzter Fragebogen T e s t A T e s t B Abbildung 4.20: Testaufbau teilgenommen. Der Test für Gruppe 1 bestand aus Teil A und Teil B des Ablaufs, Gruppe 2 führte nur Teil B aus. Das wird nochmals in Tabelle 4.5 verdeutlicht. Teil A Teil B Beschreibung Gruppe 1 x x Exploration, Demo-Film, Aufgabenteil Gruppe 2 - x Demo-Film und Aufgabenteil Tabelle 4.5: Gruppen beim Usability Test mit Fragebögen

88 76 Eine Navigation für den DB2 Performance Expert Einführend füllten alle Testteilnehmer einen Fragebogen zur Person aus, der sie außerdem über die beiden wichtigsten Punkte bei einem Benutzertest informierte: Nicht Sie werden getestet, sondern der Prototyp. und Denken Sie laut.. Die erste Instruktion ist Grundlage eines jeden Benutzertests - es geht um das Testobjekt und nicht um den Tester. Die zweite adressiert eine Methode namens Thinking Aloud (siehe Abschnitt 2.3.2, bei der die Gedanken des Testers verbalisiert werden sollen, sodass sie vom Testleiter ausgewertet werden können. Beide Punkte müssen dem Tester durch den Testleiter immer wieder in Erinnerung gerufen werden. Gruppe 1 erhält vorab keine Einführung in den DB2 Performance Expert und das Konzept der Treemaps und startet mit Teil A. Die Tester werden nacheinander mit den beiden Treemap-Darstellungen konfrontiert und sollen diese erst ohne, dann mit Interaktion explorieren und dabei laut zu denken. Sobald der Testteilnehmer der Meinung war, eine Treemap genügend erforscht zu haben, wurde jeweils ein Fragebogen zu dieser Treemap vorgelegt. Den Abschluss von Teil A bildete ein dritter Fragebogen zu beiden Treemaps. Gruppe 1 und Gruppe 2 haben Teil B des Testes durchgeführt. Teil B wird von einem 6-minütigen Demo-Film eingeleitet. Die Tester erhalten darin eine kurze Einführung in den DB2 Performance Expert und eine Erklärung zur Funktionsweise der darin prototypisch implementierten Treemaps. Der Demo-Film sorgt dafür, dass alle Tester einen bestimmten Kenntnisstand erreicht haben. Zu beachten ist, dass Gruppe 1 durch die vorausgegangene Exploration bereits mehr Erfahrung mit dem Prototypen besitzt. Dies wird jedoch dadurch ausgeglichen, dass fast alle Testteilnehmer der Gruppe 2 den Prototypen kennen, da sie in seine Entwicklung mit eingebunden waren. Nach einer kurzen Explorationsphase erhält der Tester in Teil B einen Aufgabenbogen zu System Overview. Nach dessen Abarbeitung werden die Erfahrungen in einem Fragebogen festgehalten. Auch zu Statistic Details gibt es kleine Aufgaben und einen dazugehörigen Fragebogen. Der letzte Fragebogen des Tests bezieht sich auf beide zu evaluierende Darstellungen. Er enthält viele offene Fragen. Ziel des Tests war es in erster Linie, die Akzeptanz und Zufriedenheit der Benutzer mit dem Konzept zu erheben. Das Verständnis der neuartigen Darstellung spielt dabei eine wichtige Rolle. Teil A, bei dem die Testpersonen ohne jede Einführung mit dem Prototypen interagieren, soll zeigen, wie intuitiv die entworfene Benutzungsoberfläche zu bedienen ist. Probleme in der Bedienung sollen aufgedeckt werden. Dazu dient neben Teil A vor allem der Aufgabenteil von Teil B, bei dem beobachtet wird, wie die gestellten Aufgaben gelöst werden. Offene Fragen in den Tests dienen dazu, ausgewählte Bedieneigenschaften zu diskutieren und Erweiterungsalternativen abzuwägen. Aufgaben und Fragen geben Aufschluss über Präferenzen gegenüber der Treemap in System Overview und Statistic Details. Die in der Abbildung 4.20 aufgeführten Frage- und Aufgabenbögen sind im Anhang der Arbeit enthalten. Sie haben den Testablauf strukturiert und dazu beigetragen, die zur Zielerreichung notwendigen Informationen zu erheben.

89 4.6 Evaluierung 77 Die Fragebögen wurden angelehnt an das DaTech Prüfhandbuch Gebrauchstauglichkeit [9] entworfen. Die Gestaltung der Fragebögen bezieht folgende Überlegungen mit ein: Neben ihrer Einfügung in den thematischen Zusammenhang dienen offene Fragen auch der Auflockerung der Testsituation. Um das angestrebte Feedback zu bekommen, ist es wichtig, dass der Tester das Gefühl hat, dass seine Bemühungen gewürdigt werden; müssen lediglich Felder angekreuzt werden, vergisst der Tester das Verbalisieren seiner Gedanken. Fragen, die die Vorstellungskraft des Testers ansprechen, fördern auch seine Kreativität und führen zu einem erfolgreicheren Test und einer Bereicherung des gesamten Entwurfsprozesses. 1. Ich halte diese Darstellung von Statistic Details für sinnvoll. triff gar nicht zu trifft eher nicht zu weder noch trifft eher zu trifft voll zu Wie lautet der System Name von D722 (z/os)? Benutze nur die Treemap zum Lösen dieser Aufgabe. 7. Sie haben die Möglichkeit Icons in die Darstellung einzufügen. Würden Sie das tun? Wenn ja an welcher Stelle und in welcher Form? Abbildung 4.21: Beispiele aus den Fragebögen Die meisten geschlossenen Fragen geben die in Abbildung 4.21 enthaltene Skala trifft gar nicht zu bis trifft voll zu zur Beantwortung vor. Der stets gleiche Aufbau und die Aussageform der Frage vereinfacht die Beantwortung und vermeidet Missverständnisse. Vorgegebene Antwortmöglichkeiten erlauben es auch eine quantitative Auswertung der Ergebnisse vorzunehmen. Diese muss jedoch unbedingt durch eine qualitative Auswertung der Testprotokolle ergänzt werden. Einige der Aufgaben und Fragen dienen der ausschließlichen Erhebung qualitativer Aussagen. Quantitative und qualitative Fragestellungen wechseln sich ab. Teil B enthält neben Fragebögen mit offenen Fragen und zu wertenden Aussagen auch Aufgabenfragebögen. Darin werden dem Tester einfache Aufgaben gestellt, bei

90 78 Eine Navigation für den DB2 Performance Expert deren Bearbeitung er mit dem Prototypen interagieren soll. Bei der Gestaltung wurde darauf geachtet, dass manche Tester kaum über Datenbank- und DB2 Performance Expert Kenntnisse verfügen. Es wurden nur durch den Demo-Film eingeführte Begriffe verwendet. Die Aufgaben dienten dazu, den Benutzer zu beobachten. Teil A und B enthalten zusammen ca. 45 zu wertende Aussagen, offene Fragen und Aufgaben. Das Verhältnis dabei ist 2,5 Aussagen zu 1,0 Fragen zu 1,0 Aufgaben. Experten-Walkthrough Versuchspersonen (Tester) An den Experten-Walkthroughs des Performance Experts nahmen drei einzelne Tester und eine aus drei Personen bestehende Testergruppe teil. Die Tabelle 4.6 gibt einen Überblick über die einzelnen Tester. Bei dem Walkthrough mit der Testergruppe handelte es sich um ein in einer kombinierten Web- und Telefonkonferenz abgehaltenes Interview. Daten über das Alter der Tester wurden dabei nicht erhoben. # Tester Altersgruppen 6 3mal 41-50, 3mal k. A. Experten- Walkthrough Usability DB2 Performance Kenntnisse Expert-Kenntnisse 5 von 6 6 von 6 Tabelle 4.6: Testteilnehmer Experten Walkthrough Testdauer Eine bis zwei Stunden Materialien Windows-Rechner mit installiertem DB2 Performance Expert Prototyp Server mit Datenbanken, auf die vom Prototypen aus zugegriffen werden kann Demo-Film Rechner, auf dem das Testprotokoll mitgeschrieben wurde (Telefon und Webkonferenzcenter) Unabhängige Variablen Zu den unabhängigen Variablen der Experten-Walkthroughs gehörte das Wissen, dass jeder der Tester mitbrachte. Alle Testpersonen kannten den DB2 Performance Expert vor dem Test. Fünf von sechs Testern sind Experten im Bereich Usability und Visual Design; einer der Tester ist Experte für den DB2 Performance Expert. Abhängige Variablen Die Experten-Walkthroughs wurden anhand des Testprotokolls ausgewertet.

91 4.6 Evaluierung 79 Beschreibung Die bei diesem Projekt durchgeführten Walkthroughs hatten Gesprächscharakter. Zunächst wurde der Demo-Film, der auch für die Usability Tests verwendet wurde, gezeigt. Danach wurde der Prototyp ausprobiert und besprochen. Die Tester haben den Prototyp anhand ihrer speziellen Erfahrung bewertet: Usability Experten und Visual Designer haben den Aspekt Accessibilty, speziell den Zugang für Menschen mit einer Farbsehschwäche oder eingeschränkten Eingabemöglichkeiten, genauer beleuchtet. Das Feedback des DB2 Performance Expert-Experten hat viele Punkte aufgezeigt, in denen das Konzept angepasst werden muss, um inhaltlich den Ansprüchen eines DB2 Performance Expert-Benutzers zu genügen. Ad-Hoc Test Im Gegensatz zu allen anderen vorgestellten Testmethoden, die am Ende der Entwicklung angewand wurden, fanden Ad-Hoc Tests während des gesamten Entwicklungsprozesses statt. Versuchspersonen (Tester) Insgesamt sechs Testpersonen unterschiedlichen Alters haben jeweils ein bis mehrmals während der Entwicklung an Ad-Hoc Tests teilgenommen. Testdauer eine halbe bis zwei Stunden Materialien Je nach Projektstatus wurden verwendet: mit der Hand oder elektronisch gefertigte Skizzen Powerpoint-Prototypen Screenshots andere Beispielanwendungen zur Demonstration von Konzepten Windows-Rechner mit installiertem DB2 Performance Expert Prototyp Server mit Datenbanken, auf die vom Prototypen aus zugegriffen werden kann Immer in den Ad-Hoc Tests gebraucht wurde: Windows-Rechner mit installiertem DB2 Performance Expert (unveränderte Software) Server mit Datenbanken, auf die mit der unveränderten Version der Software zugegriffen werden kann Papier und Stift zur Erläuterung und zum Schreiben von Notizen Unabhängige Variablen Die Kenntnisse des DB2 Performance Experts und der Partizipationsgrad an der Entwicklung spielten eine entscheidende Rolle.

92 80 Eine Navigation für den DB2 Performance Expert Abhängige Variablen Feedback aus Ad-Hoc Tests wurde in handschriftlichen Skizzen und Aufzeichnungen erfasst. Beschreibung Die Ad-Hoc Tests spielten im Designprozess eine wichtige Rolle. Es handelt sich dabei um informelle, nicht standardisierte Gespräche mit unterschiedlichen Personen. Ihre Ergebnisse sind in das entwickelte Design mit eingeflossen und bestimmen auch die in der Auswertung enthaltenen Vorschläge für die Weiterentwicklung und Verbesserung. Heuristische Evaluierung Abschnitt hat die Grundlagen dieser Testmethode erläutert. Im Rahmen der Evaluation des Redesigns des DB2 Performance Experts wurde eine Heuristische Evalutation durchgeführt. Testdauer inklusive Ausarbeitung ca. fünf Stunden Materialien Windows-Rechner mit installiertem DB2 Performance Expert Prototyp Server mit Datenbanken, auf die vom Prototypen aus zugegriffen werden kann Heuristiken (Erläuterte Prinzipien von Tognazzini [41]) Textverarbeitungsprogramm zum Erfassen der Notizen Beschreibung Der Prototyp wurde von seinem Entwickler anhand der Heuristiken untersucht. Aufgrund dieser Personalunion von Tester und Entwickler wurden bereits in die Auswertung der Heuristischen Evaluierung Verbesserungsvorschläge mit aufgenommen Auswertung Der erste Teil des Abschnitts enthält die Auswertung der Heuristischen Evaluierung. Die darauf folgende quantitative Auswertung beruht auf den Ergebnissen des Usability Tests mit Fragebögen, die qualitative Auswertung bezieht außerdem Ergebnisse der Experten-Walkthroughs und Ad-Hoc Tests mit ein. Zusammengefasst wird diese Analyse im letzten Abschnitt Monitor Maps, wo ein Fazit für eine mögliche Realisierung der prototypischen Entwicklung gezogen wird.

93 4.6 Evaluierung Auswertung der Heuristischen Evaluierung Der Prototyp des DB2 Performance Experts wurde aufgrund der Prinzipien von Tognazzini [41] bewertet. Erfüllung der Prinzipien, Mängel in der Realisierung und Verbesserungsmöglichkeiten werden in diesem Abschnitt aufgezeigt. Antizipation Erfüllung des Prinzips durch den Prototypen Die Treemaps haben in erster Linie das Ziel, dem Benutzer zu zeigen, wo seine Aufmerksamkeit erforderlich ist und zu ermöglichen, direkt dahin zu gelangen. Diese Funktionalität der Benutzerführung wird vom Prototypen erfüllt. Mängel Jedem System wird die gleiche Wichtigkeit zugeordnet. Beispielsweise erzeugen Testsysteme die gleiche Aufmerksamkeit wie Produktivsysteme. Verbesserungsmöglichkeiten Das Konstrukt My Folders bietet dem Benutzer die Möglichkeit, die für ihn wichtigen Systeme in einem Ordner zusammenzustellen und zu betrachten. Ein Zoom auf diesen Ordner eliminiert das Problem. Bei der Konfiguration eines Systems könnte man den Benutzer die Wichtigkeit des Systems einstufen lassen. Die Monitor Map könnte dann über eine Filterfunktion an ein solches Wichtigkeitslevel angepasst werden. Autonomie Erfüllung des Prinzips durch den Prototypen In der Treemap wird auf einer hohen Abstraktionsstufe Information zu allen Systemen auf einen Blick angezeigt. Ein Step-Konzept (erst Farbe, dann Mouseover, dann Detailinformation) unterstützt den Entscheidungsprozess des Benutzers und überflutet ihn nicht mit der gesamt verfügbaren Information. Der Benutzer kann selbst entscheiden, welche Funktionen er wählt. Es ist keine Reihenfolge vorgegeben. Mängel Die Reihenfolge der Bearbeitung wird nicht gelenkt. Verbesserungsmöglichkeiten Auch an dieser Stelle können Filterfunktionen zum Beispiel nach Fehlerkategorien den Benutzer besser unterstützen. Eine weitere Möglichkeit wäre, dem Benutzer eine Aufgabenliste anzubieten, in der er alles erstmal notieren kann. Sortierfunktionen in dieser Liste erleichtern dann die Auswahl der zuerst zu betrachtenden Information. Farbenblindheit Erfüllung des Prinzips durch den Prototypen Farbe spielt eine entscheidende Rolle bei den Treemaps. Ein hoher Kontrast reicht auch bei Farbfehlsichtigkeit aus, um die Farben zu unterscheiden. Mängel Ausgeprägte Farbenblindheit macht es unmöglich, die Monitor Map zu benutzen. Verbesserungsmöglichkeiten Ein sekundäres Mittel zur Codierung der Statusinformation wären Formen, zum Beispiel Quadrat, Kreis, Dreieck und Raute für Grau, Grün, Gelb und Rot. Die-

94 82 Eine Navigation für den DB2 Performance Expert se Darstellung könnte durch einen Menüeintrag aktiviert werden, sollte aber aus Gründen der Einfachheit nicht als Default eingestellt sein. Konsistenz Erfüllung des Prinzips durch den Prototypen Allen Treemaps in dem Prototypen liegt das gleiche intuitive Ampel-Farbkonzept zugrunde. Die Menge der zur Verfügung stehenden Interaktionsformen ist gleich. Mängel Die Interaktion mit den Monitor Maps in System Overview und Statistic Details ist unterschiedlich. Das Mouseover in Statistic Details ist zu flüchtig. Zumindest, wenn man es durch einen Mausklick undurchsichtig macht, erwartet man damit in irgendeiner Form interagieren zu können, wie zum Beispiel mit den Mouseovers in System Overview. Verbesserungsmöglichkeiten Da es sich bei System Overview und Statistic Details um unterschiedliche Darstellungen handelt, wird die Inkonsistenz teilweise relativiert. Die Benutzertests haben gezeigt, dass es möglich sein muss, auf das durch einen Mausklick materialisierte Mouseover in Statistic Details zu gehen, ohne dass es verschwindet oder seine Position verändert. Zwar ist im Moment keine weitere Interaktion mit den Feldern des Mouseovers möglich, aber allein schon die Möglichkeit, mit der Maus einen bestimmten Wert zu markieren, würde die Zufriedenheit der Benutzer steigern. Defaults Das Kriterium ist auf den Prototypen nicht anwendbar, jedoch sehr wichtig für die tatsächliche Implementierung des Konzeptes: Die Schwellwerte müssen durch sinnvolle Defaults voreingestellt sein. Die Domäne des Performance Experts ist sehr komplex, deswegen sollte der Benutzer die Möglichkeit haben, aus einer Menge an Defaults auszuwählen. Sämtliche möglichen Zusatzfunktionen, wie die Formrepräsentation für Farbenblinde, sollten aktivierbar sein und nicht direkt angezeigt werden. Effizienz des Benutzers Erfüllung des Prinzips durch den Prototypen Durch die stufenweise Zugänglichmachung der Information wird die Effizienz des Benutzers gesteigert. Es kommt der Aufnahmefähigkeit des Menschen entgegen, dass durch die Treemap Details zunächst verborgen bleiben. Die Mouseover-Interaktion hat einen eher vorläufigen Charakter, zeigt aber schon mehr Information, und der Mausklick bringt letztendlich die Details, für die sich der Benutzer entschieden hat. Aus Sicht des Systems wäre es effizient, sofort alles verfügbar zu machen. Mängel Sucht ein Benutzer ein bestimmtes System in System Overview oder eine bestimmte Countergruppe in Statistic Details, muss diese in der Monitor Map gesucht werden. Verbesserungsmöglichkeiten Da die Monitor Maps jeweils als Ergänzung oder Alternative implementiert sind, kann der Benutzer, wenn er genau weiß, was er tun möchte, auf den klassischen Baum zur Navigation zurückgreifen. Die Suche in den Monitor Maps könnte durch eine Suchfunktion unterstützt werden.

95 4.6 Evaluierung 83 Gibt der Benutzer den Suchbegriff ein, so wird dieser automatisch ergänzt, und es erfolgt eine Markierung (zum Beispiel durch Blinken) in der Monitor Map. Explorierbare Benutzungsoberflächen Erfüllung des Prinzips durch den Prototypen Die im vorhergehenden Punkt beschriebene Mouseover-Interaktion kommt dem Kriterium der Explorierbarkeit sehr entgegen. Anders als bei einem Mausklick muss der Benutzer nicht befürchten, etwas falsch zu machen. Alle Aktionen im Prototypen, auch Mausklicks, sind natürlich reversibel. Da ohne Interaktion keinerlei textuelle Information angezeigt wird, wird die Erforschung der Treemaps gefördert. Benutzer werden von der ungewohnten Form der Treemap-Darstellung länger gefesselt als von einer konventionellen Benutzungsoberfläche. Mängel Die Explorierbarkeit der Monitor Maps wird als ausreichend gut eingestuft. Verbesserungsmöglichkeiten Keine Maßnahmen zur Verbesserung der Explorierbarkeit sind erforderlich. Fitt s Law Erfüllung des Prinzips durch den Prototypen Fitt s Law besagt, dass je weiter ein zu selektierendes Ziel weg ist, desto größer muss es sein. Die Treemap in Statistic Details ist statisch. Die selektierbaren Flächen sind ausreichend groß. In System Overview wird die Größe der Systeme, mit denen interagiert wird, dynamisch bestimmt. Bei einer anzunehmenden durchschnittlichen Anzahl von nicht mehr als 50 Systemen ist die Größe der ein System repräsentierenden Quadrate in System Overview ausreichend. Die Größe der Systeme lässt sich außerdem durch Hineinzoomen verbessern. Mängel Je mehr Systeme in System Overview konfiguriert sind, desto kleiner werden die selektierbaren Flächen. Verbesserungsmöglichkeiten Abbildung 4.22 zeigt, dass weit über 1000 Systeme mit einer Größe von 10x10 Pixeln in der System Overview Monitor Map dargestellt werden können. Fitt s Law impliziert folgende Verbesserungsmöglichkeit: Bildung von Gruppen zu beispielsweise neun (3x3) Systemen. Im ersten Schritt der Selektion versucht der Benutzer zuerst, zum größeren Ziel, der Gruppe zu navigieren; erst wenn er sich dort befindet, selektiert er das gewünschte System. Damit ist das Ziel zur Überbrückung der langen Distanz deutlich größer als das eigentliche Ziel, das erst angesteuert wird, sobald der Benutzer sich mit dem Zeigeinstrument in dessen Nähe befindet. Ein weiterer Vorteil, unabhängig von Fitt s Law, ist, dass diese Gruppierung dazu führt, dass der Benutzer sich die Position eines bestimmten Systems besser merken kann.

96 84 Eine Navigation für den DB2 Performance Expert Abbildung 4.22: System Overview: Wie viele System können gleichzeitig beobachtet werden? Menschengerechte Bedienobjekte Erfüllung des Prinzips durch den Prototypen Objekt der Betrachtung im DB2 Performance Expert sind Datenbanksysteme. In der Monitor Map von System Overview repräsentiert jedes Kästchen ein solches System. Alle für das System verfügbaren Funktionen können mithilfe dieser Repräsentation aufgerufen werden. Die Bedienobjekte in der Treemap-Darstellung von Statistic Details werden von eng aneinander gesetzten farbigen Flächen gebildet. Durch die Selektionsrahmen sind diese ausreichend gut voneinander zu unterscheiden. Die Monitor Map von Statistic Details, als Zusammensetzung aller Flächen, bildet ein eigenständiges Objekt. Die abstrahierte Darstellungsform vermittelt die einfache Information, ob alles in Ordnung ist oder nicht. Ein geübter Benutzer kann durch die Position und Größe einer roten oder gelben Fläche die Gruppe der betroffenen Counter erkennen. Monitor Maps sind selbst Bedienobjekte, die den Ansprüchen des Menschen gerecht werden. Mängel Die Interaktion mit den Flächen in Statistic Details und vor allem mit den Mouseovers muss optimiert werden. Die Baumstruktur ist ohne Interaktion nicht ausrei-

97 4.6 Evaluierung 85 chend deutlich erkennbar. Verbesserungsmöglichkeiten Die Treemap Darstellung in Statistic Details kommt der klassischer Treemaps sehr nahe. Ein passender Layout-Algorithmus muss aus diesem Forschungsfeld ausgewählt werden, um die Struktur der Treemap deutlicher zu machen. Geeignet erscheinen squarified Treemaps wie in dem SequoiaView Tool der Universität Eindhoven [10]. Verringerung von Latenzzeiten Performance war kein Kriterium bei der Implementierung des Prototypen. Natürlich muss bei tatsächlicher Umsetzung des Konzeptes darauf geachtet werden, dass nur solche Informationen auf den ersten Blick im Mouseover angezeigt werden, die in vertretbarer Zeit vom System angezeigt werden können. Eventuell ist eine Optimierung der Funktionen notwendig. Erlernbarkeit Erfüllung des Prinzips durch den Prototypen Trotz der ungewohnten Darstellung sind die implementierten Interaktionsformen nicht neu. System Overview erfordert nur geringen Lernaufwand. Viel ist aus anderen Bereichen bekannt und kann schnell übertragen werden: Bedeutung der Farben Interaktion über Mouseover, Mausklick, Doppelklick und Kontextmenüs Links im Mouseover Gelernt werden muss, die Struktur einer Treemap auf die bekannte Baumdarstellung zu übertragen und die Zoomfunktion zu benutzen. Der dazu notwendige Aufwand ist angemessen. Mängel In der Monitor Map von Statistic Details ist die Lernkurve, bis man weiß, welche Countergruppe von welcher Fläche dargestellt wird, zu groß. Verbesserungsmöglichkeiten Die Anzeige der Gruppenüberschriften in der Monitor Map von Statistic Details ist bereits implementiert. Sie kann sowohl über eine im Menü wählbare Funktion als auch als Default gesetzt werden. Das Farbenlernen könnte durch das Hinzufügen einer Legende unterstützt werden. Zur Verbesserung der Erlernung von Monitor Maps und auch zur Unterstützung der Arbeit mit dem DB2 Performance Expert könnte eine Funktion implementiert werden, die auf Knopfdruck nacheinander, wie in einem Film, die Treemap aktiviert und zuerst alle roten, dann gelben, dann grünen und dann (bei System Overview) die grauen Objekte selektiert und deren Mouseovers anzeigt. Eine solche Funktion ist in dem Bereich der Hilfe anzusiedeln und hat keine hohe Priorität. Benutzung von Metaphern Erfüllung des Prinzips durch den Prototypen Der Name Treemap oder Monitor Map assoziiert Landkarten, deren Eigenschaft es ist, alles auf einen Blick anzuzeigen. Die Abstraktionsstufe ist dabei unter Umstän-

98 86 Eine Navigation für den DB2 Performance Expert den sehr hoch. Ohne eine Lupe kann man Namen zum Beispiel nicht erkennen. Im Falle der Monitor Maps ist der Zoom diese Lupe. Oft verwendet man auch den Finger, um sich auf einer Landkarte zu orientieren - analog dazu verwendet der Benutzer der Treemap die Maus, um mehr Informationen zu bekommen. Eine zweite Metapher, die benutzt wurde, ist die Ampel. Sie wurde erweitert um die Farbe Grau, die in der Computerwelt für undefiniert steht. Die Benutzertests haben die Validität der Assoziation bestätigt. Auch den halbtransparenten Mouseovers liegt eine Metapher zugrunde: Wie eine Fata Morgana in der Wüste sind sie nicht greifbar. Mängel Die beiden ersten Metaphern funktionieren gut. Die letzte, die der Fata Morgana, wird jedoch gebrochen, wenn durch einen Mausklick das Mouseover undurchsichtig wird. Der Benutzer erwartet, dass dann auch eine Interaktion damit möglich ist. Verbesserungsmöglichkeiten Siehe Verbesserungsmöglichkeiten unter Konsistenz. Schutz der Arbeit des Benutzers Dieses Prinzip findet beim Prototypen ebenfalls keine Anwendung, da keine Arbeitsergebnisse erzeugt werden. Wird die im ersten Punkt (Autonomie) beschriebene Taskliste implementiert, muss dabei darauf geachtet werden, dass diese niemals durch einen Systemabsturz oder versehentlich vom Benutzer gelöscht wird. Auch Schwellwerte, Filtereinstellungen etc. müssen bei einem Neustart des Systems erhalten bleiben. Lesbarkeit Die in den Monitor Maps enthaltenen Texte wurden hinsichtlich Schriftgröße und Kontrast geprüft. Zwei Stellen wurden dabei genauer untersucht: Die kleinere Schriftgröße zur Benennung der Groupboxen in System Overview ist ausreichend und die halbtransparenten Mouseovers in Statistic Details sind gut lesbar. Außerdem lässt sich die Lesbarkeit eines halbtransparenten Mouseovers durch einen Mausklick verbessern. Verfolgen des Benutzers Über den Benutzer werden von den Monitor Maps keinerlei Daten erhoben. Das erscheint bei den gegebenen Aufgabenszenarien nicht notwendig. Sichtbare Navigation Erfüllung des Prinzips durch den Prototypen Alle navigierbaren Objekte werden von den Monitor Maps gleichzeitig dargestellt. Gegenüber dem klassischen Baum, in dem Objekte durch zugeklappte Ordner oder zu wenig verfügbaren Platz versteckt werden, ist das eine Verbesserung der sichtbaren Navigation. Mängel Die eigentlichen Funktionen sind im Kontextmenü oder auf dem Mouseover und damit versteckt. Verbesserungsmöglichkeiten Die entworfene Zoomfunktion kommt diesem Prinzip entgegen. Soweit Platz verfügbar ist, werden Links direkt auf den quadratischen Systemrepräsentationen in System Overview dargestellt. Der Prototyp implementiert bereits eine Zoomstufe,

99 4.6 Evaluierung 87 bei der der Name auf dem Quadrat zu sehen ist. In der nächsten Stufe wäre es denkbar, Links auf die Messages hinzuzunehmen und in der höchsten Zoomstufe, der Sicht auf ein einzelnes System, kann man zusätzlich wie bisher auch direkte Navigation zu den einzelnen Komponenten ermöglichen. Die Flächen in Statistic Details können bereits ohne Zoom dazu genutzt werden, Navigationslinks darauf zu platzieren, zum Beispiel einen Link auf den abnormen Wert. Bei dieser Monitor Map ist jedoch darauf zu achten, dass das Gesamtbild nicht zu hektisch wird und der Vorteil der hohen Abstraktion zunichte gemacht wird. Eine stets präsente Suche in der Toolbar von System Overview (vgl. Prinzip Effizienz) könnte erweitert werden mit einem Gehe zu. Diese Expertennavigation erlaubt es dem Benutzer dann, System und aufzurufende Funktion direkt zu wählen. Zusammenfassung der Heuristischen Evaluation Die Tabelle 4.7 gibt einen schnellen Überblick über die Erfüllung oder Nichterfüllung der geprüften Heuristiken. Dabei wird eine Symbolskala von ++ für sehr gut, + für gut, 0 für unentschieden, - für mangelhaft und - - für nicht ausreichend verwendet. Durch - - und - wird also ein dringender Verbesserungsbedarf angezeigt. Prinzip Wertung Kommentar Antizipation + Gleiche Wichtigkeit aller Systeme. Fein granularere Abstimmung wünschenswert Autonomie + Autonomie heißt nicht keine Lenkung! Filter wären eine Verbesserung. Farbenblindheit k. A. Zufriedenstellende Lösung ist vorhanden. Implementierung ist nicht Teil der Aufgabe. Konsistenz 0 Die beiden Treemaps sind nicht zueinander konsistent. Defaults k. A. Prinzip auf den Prototypen nicht anwendbar. Effizienz des Benutzers + Für einige Aufgaben ++. Explorierbarkeit ++ Dieses Prinzip ist voll erfüllt. Fitt s Law ++ Sehr gut für typische Anzahl der Systeme in System Overview. Menschengerechte Bedienobjekte +/- + für System Overview, - für Statistic Details. Verringerung von Latenzzeiten k. A. Prinzip nicht auf den Prototypen anwendbar. Erlernbarkeit +/0 + für System Overview, 0 für Statistic Details Benutzung von Metaphern +/0 + in System Overview, 0 in Statistic Details

100 88 Eine Navigation für den DB2 Performance Expert Prinzip Wertung Kommentar Schutz der Arbeit des Benutzers k. A. Nicht auf den DB2 Performance Expert anwendbar (Persistenz von Fenstergröße etc. ausgenommen). Lesbarkeit ++ Schriften und Kontraste sind gut gewählt. k. A. Erscheint im Konzept der Monitor Maps nicht notwendig. Verfolgen des Benutzers Sichtbare Navigation + Mouseover und Kontextmenü sind nicht permanent sichtbar, aber ausreichend zugänglich. Tabelle 4.7: Ergebnistabelle der Heuristischen Evaluation anhand der Prinzipien von Tognazzini Quantitative Auswertung Die Tabelle im Anhang B gibt alle zählbaren Ergebnisse der Fragen mit vorgegebener Antwortskala wieder. Wie im Kapitel Grundlagen (2.3.1) besprochen, reicht bereits eine geringe Anzahl an Testern aus um den Großteil der Usability-Probleme einer Software aufzudecken. Jedoch können nur Tendenzen und keine statistisch signifikanten Aussagen über die Zufriedenheit, Präferenz und Interaktion gemacht werden. Unter Berücksichtigung der verbalen Anmerkungen der Tester und Beobachtungen des Testleiters werden diese im Folgenden zusammengefasst. Zufriedenheit Die Fragen danach, für wie sinnvoll und nützlich die Monitor Maps gehalten werden, sind von den Testern sehr positiv beantwortet worden. Die Tabelle 4.8 gibt einen Überblick über die diese Aspekte adressierenden Fragen des explorativen Teils A des Usability Tests. Alle Teilnehmer des Usability Testes wurden im abschließenden Fragebogen zur allgemeinen Zufriedenheit mit den Monitor Maps im Prototypen befragt. Fünf der zehn Tester gaben an, dass sie voll zufrieden sind, zwei, dass sie eher zufrieden sind und lediglich einer gab an, dass für ihn weder Zufriedenheit noch Unzufriedenheit mit dem Konzept besteht. Abbildung 4.23 zeigt dieses Ergebnis noch einmal in einem Tortendiagramm. Präferenz Die quantitative Auswertung der Frage danach, welche der beiden Monitor Maps besser gefallen hat (Fragen A3.2 und B5.2), lässt keine klare Tendenz erkennen (siehe Abbildung 4.24).

101 4.6 Evaluierung 89 A1.1 Ich halte die Darstellung im rechten Teil des Fensters für nützlich. (System Overview) A1.4 Diese Darstellung ist zur Erfüllung der Aufgaben eines Benutzers des Performance Experts nützlich. (System Overview) A2.1 Ich halte diese Darstellung von Statistic Details für sinnvoll. A3.1 Ich glaube, dass die beiden Darstellungen für den Benutzer des Performance Experts nützlich sind % steht für die Antwort trifft voll zu, + für trifft eher zu. % für weder noch, - für trifft eher nicht zu und für trifft gar nicht zu. Tabelle 4.8: Fragen zu Sinn und Nützlichkeit der Monitor Maps (Gruppe 1 mit 5 Testern) Ich bin mit der Darstellung der Navigationsbäume zufrieden. (Frage B5.1) Antworten: 5mal : trifft voll zu 4mal: trifft eher zu 1mal: weder noch Abbildung 4.23: Zufriedenheit der Benutzer mit den Monitor Maps im Prototypen Zieht man die im Anhang enthaltenen Fragen nach Zufriedenheit und Nützlichkeit der jeweiligen Treemaps zur Ermittlung der Präferenz hinzu (das sind für System Overview: A1.1, A1.4, B2.1 B2.3, B5.3, für Statistic Details: A2.1, A2.2, A2.4, B4.1, B4.2, B4.4, B5.4), so erhält die Darstellung in System Overview ein insgesamt positiveres Urteil. Die Frage, welche der beiden Treemaps besser ist, kann jedoch so nicht geklärt werden. Da es sich nicht um Alternativen handelt, ist es überhaupt unmöglich, einen absoluten Vergleich anzustellen. An dieser Stelle sei auf den Abschnitt qualitative Auswertung verwiesen, der die Fragestellung nochmals aufgreift und beleuchtet.

102 90 Eine Navigation für den DB2 Performance Expert Anzahl der Antworten Welche Darstellung hat Ihnen besser gefallen? Frage A3.2 (Teil A) Frage B5.2 (Teil B) Gruppe 1 Gruppe Abbildung 4.24: Präferenzen für Monitor Maps in System Overview oder Statistic Details Interaktion Hier werden einige ausgewählte Ergebnisse der quantitativen Befragung zur Interaktion mit den Treemaps im Prototypen vorgestellt. Die im Usability Test gestellten Aufgaben dienten der Erhebung von Selbstbeschreibungsfähigkeit, Steuerbarkeit und Erwartungskonformität. Aussagekräftige Auswertungen dazu beziehen Bearbeitungszeit, Weg und auftretende Probleme mit ein und sind in der qualitativen Auswertung der Tests enthalten. Fünf von zehn Testern gaben bei der nach der Bearbeitung des Aufgabenteils von System Overview gestellten Frage: Es ist mir leicht gefallen, die Aufgaben auszuführen. an, dass das voll zutrifft; die anderen fünf antworteten mit trifft eher zu. Das lässt zwei Schlüsse zu: entweder die Aufgaben waren zu leicht oder die vorausgegangene Einführung und die Bedienbarkeit sind ausreichend gut. Vermutlich spielten beide Faktoren eine Rolle. Sowohl bei den Aufgaben zu System Overview als auch den Aufgaben zu Statistic Details gab es keine Aufgaben, die nicht gelöst werden konnten. Testteil A, bei dem von Gruppe 1 ohne jegliche Einführung die neue Benutzungsoberfläche erforscht wird, fragt (A1.2), welche Eigenschaften von System Overview entdeckt wurden. Ziel der Frage ist es, herauszufinden, wie intuitiv die Bedienung ist, also ob die Benutzer nach einer kurzen Exploration die für die Interaktion notwendigen Eigenschaften und Bedienelemente entdeckt haben. Die Ergebnisse der fünf Tester sind in Tabelle 4.9 dargestellt.

103 4.6 Evaluierung 91 Interaktionsform entdeckt von * von 5 Testern Farbwechsel 5 Mouseover 5 Counter in Mouseover 1 Linkeigenschaft im Mouseover 2 Kontextmenü 2 Doppelklick Auswahlfenster 1 Markierung durch Einfachklick 4 Zoomfunktion (Baum) 0 Zoomfunktion (Map) 0 Zusammenhang zwischen Baum und 3 Monitor Map Tabelle 4.9: Von Gruppe 1 bei Exploration entdeckte Interaktionsformen in System Overview Die Ergebnisse werden durch folgende Aspekte erklärt und relativiert: Zur Exploration war weder ein Szenario noch eine Aufgabe vorgegeben. Das erklärt möglicherweise, warum das Kontextmenü, der Doppelklick und der Link im Mouseover kaum entdeckt wurden. Den Testern war unklar, was mit Countern im Mouseover gemeint ist. In der Abbildung ist dies daran erkennbar, dass zwei Personen angegeben haben, die Linkeigenschaft dieser Counter wahrgenommen zu haben, jedoch nur eine davon den Counter an sich entdeckt hat. Alle Tester haben die Mouseovereigenschaft entdeckt und damit gezeigt, dass es sich um eine intuitive Interaktionsform handelt. Eine wichtige Erkenntnis ist, dass keiner der Tester irgendeine Art von Zoom entdeckt hat. Vermutlich, weil er zum einen nur an einer Stelle im Prototyp implementiert war und zum anderen gar nicht visualisiert ist. Die Frage (A2.4), ob die Interaktion durch Mouseover bei der Treemap von Statistic Details den Erwartungen entsprach, beantworteten alle Tester mit trifft voll zu. Das lässt darauf schließen, dass Mouseover und farbige Flächen durch die erste Treemapdarstellung bereits miteinander verknüpfte Eigenschaften sind und die Interaktion gelernt wurde. Die darüber hinausgehende Interaktion mit Statistic Details wurde von den Testern sehr uneinheitlich empfunden. Die Ergebnisse im Aufgabenteil zeigen, dass diese Monitor Map weit weniger ausgereift ist (vergleiche qualitative Analyse) Qualitative Auswertung Die meisten Ergebnisse des standardisierten Tests mit Fragebögen lassen sich aus dem qualitativen Feedback der Tester ableiten. Zusammen mit den Aussagen in den Ad-Hoc Tests und Walkthroughs lassen sich die Zielfragen des Tests beantworten:

104 92 Eine Navigation für den DB2 Performance Expert Zufriedenheit Die durch den Fragebogen erhobene sehr hohe Zufriedenheit der Tester mit dem Konzept der Treemaps und dessen Integration in den DB2 Performance Expert hat sich im Gespräch immer wieder bestätigt. Alle Testpersonen konnten sich vorstellen, das Konzept in den DB2 Performance Expert zu integrieren. Dabei wurde neben der direkten Navigation vor allem das durch die Farben gegebene Real-Time-Monitoring als must have identifiziert. Die ungewohnte, bunte Darstellung stieß auf große Zustimmung. Über den so genannten Joy of Use - die Freude bei der Bedienung - liegen keine quantitativen Aussagen vor, jedoch bestätigten alle Testpersonen abschließend, dass der Test ihnen Spaß gemacht hat. Präferenz Die quantitative Untersuchung, welche Darstellung besser gefallen hat, lässt keine eindeutige Aussage über die Präferenz zu. Die Gesprächsprotokolle lassen jedoch darauf schließen, dass diejenigen Personen, die sich für die Treemap in Statistic Details ausgesprochen haben, ihre Entscheidung weniger aufgrund des Nutzens für den DB2 Performance Expert, sondern vielmehr aus Spaß an der neuen Darstellung trafen. Die halbtransparenten Datenpanels wurden vielfach als cool bezeichnet. Die notwendige Exploration der Treemap machte diesen Testern Spaß. Sie waren offen dafür, auf gewohnte Elemente wie eine textuelle Repräsentation zu verzichten. Bei der Implementierung einer solchen Treemap muss untersucht werden, inwieweit eine solche erste Reaktion bei der Zielgruppe vorhanden ist und ob sie zum Erlernen und effizienten Bedienen des Interfaces ausreicht. Interaktion mit System Overview Die Beobachtung der Interaktion im Aufgabenteil hat ergeben, dass die Mouseovers sehr gut angenommen und intensiv genutzt werden. Beispielsweise haben alle Tester die Aufgabe des Navigierens von System Overview zu einem der Counter im Alarmzustand über den Link im Mouseover bewältigt, obwohl andere Möglichkeiten wie Kontextmenü und Doppelklick im Film eingeführt wurden. Interaktion mit Statistic Details Den Aufgaben B3.T1 und B3.T3 im Aufgabenteil von Statistic Details liegt die These zugrunde, dass der Mensch Positionen gut mit Begriffen verknüpfen und sich Positionen gut merken kann. In dem den Testpersonen vorgeführten Film wird die Position des Overview Mouseovers explizit gezeigt und benannt. Die beiden Aufgaben erfordern, dass eben dieses Mouseover in der Statistic Details Treemap wiedergefunden wird. Sechs von zehn Testpersonen haben sich bereits bei der ersten Frage an die im Film gezeigte Position erinnert, zwei hatten Schwierigkeiten, die Frage zu verstehen und zwei haben einfach gesucht. Bei der zweiten Frage nach diesem Mouseover haben alle Testpersonen sofort gewusst, wo zu suchen ist Monitor Maps im DB2 Performance Expert Die Auswertung der Tests hat gezeigt, dass es sich bei dem Prototypen um ein erfolgreiches Redesign des DB2 Performance Experts handelt. Die Benutzer waren

105 4.6 Evaluierung 93 sehr zufrieden mit der durch die Treemaps verbesserten Übersicht und betrachteten das Konzept als sinnvoll und nützlich. Entscheidend in der Darstellung ist die durch die Farben gegebene Möglichkeit zu sehen, wo etwas passiert. Die Kombination von Farben und Flächen wird unter dem Begriff Monitor Maps zusammengefasst. Dieser Abschnitt bildet ein Fazit für die Entwicklung von Monitor Maps im DB2 Performance Expert. Integration in bestehende Architektur Nachrichten (Messages), die den Status eines Systems auf Gelb oder Rot setzen, werden im Prototypen lediglich simuliert. Im DB2 Performance Expert sind sie zum jetzigen Zeitpunkt noch nicht implementiert. Die Komponente Exception Processing bietet jedoch eine Grundlage, die es ermöglichen würde, solche Statusinformation zu generieren. Abgesehen von den Messages ist die Relevanz der derzeit im Mouseover angezeigten Daten gering. Expertenwissen ist notwendig, um den Platz mit wichtigen Informationen für den Datenbankadministrator zu füllen. Dabei muss auf die dadurch entstehende Performancebelastung für das Gesamtsystem geachtet werden. Notwendige Erweiterungen des Prototypen Die zeitliche Komponente der Monitoring-Aufgabe ist ein Aspekt, den der Prototyp nicht behandelt. Folgendes Szenario macht die Notwendigkeit darauf einzugehen deutlich: Wert A löst im DB2 Performance Expert bei Überschreiten der Schwelle r den Alarmzustand rot aus, denn die Arbeit mit diesem System ist dann unmöglich. Eines Tages tritt diese Situation ein, und die Nutzer des Systems beschließen deswegen ihre Mittagspause vorzuverlegen. Dadurch, dass keine einzige Person mehr an der Datenbank arbeitet, sinkt der Wert wieder unter die Schwelle r und der DB2 Performance Expert zeigt keinerlei Ausnahmezustand mehr an. Für den Benutzer des DB2 Performance Experts wird das Problem erst wieder sichtbar, wenn die Nutzer des betroffenen Systems zurückkehren und der Counter die Schwelle erneut überschreitet. Der Handlungsbedarf bestand jedoch schon vorher. Es muss also eine Möglichkeit geben, den zeitlichen Verlauf des Systemzustandes zu erkennen. Zum Beispiel könnte das eine Zeitachse sein. Nachteil dabei: das Problem ist nicht auf den ersten Blick erkennbar. Eine andere Lösung, die während der Tests von einem DB2 Performance Expert- Experten vorgeschlagen wurde, wäre, den angezeigten Zustand bei Bedarf zwar zu erhöhen ( d. h. aus Grün wird Gelb, aus Gelb wird Rot), jedoch nicht automatisch wieder zu senken, auch wenn ein Problem nicht mehr aktuell ist. Die Messages müssen in diesem Modell aktiv vom Benutzer abgehakt werden. Im Abschnitt wurden diese und weitere Lösungsansätze diskutiert. Links als Navigationselement Die Tests haben gezeigt, dass Links gut angenommen und sogar bevorzugt benutzt werden. Sie ermöglichen eine direktere Navigation als Mausklicks oder Kontextmenüs. Analog zum WWW spielt dabei die Adresse eine untergeordnete Rolle. Für die Links im Mouseover des System Overview Prototypen heißt das: dem Benutzer ist egal, welche Komponente geöffnet wird, um den Wert genauer zu betrachten. Links sind eine Navigationsform, deren Einsatz in dem Anwendungsfeld des DB2

106 94 Eine Navigation für den DB2 Performance Expert Performance Expert sehr sinnvoll erscheint. Sie sind ein platzsparendes Mittel zum direkten Zugriff auf Funktionen, deren Anzahl nicht durch das in der Software implementierte Wissen reduziert werden kann. Umsetzung von Statistic Details Jeden Counter in der Komponente Statistic Details zu bewerten, ist zum jetzigen Zeitpunkt nicht möglich. Es erfordert eine große Menge an Wissen über Datenbanken im Allgemeinen und die ausgewählte Datenbank im Speziellen. Aus diesem Grund ist genau zu prüfen, wie eine Treemap ohne bzw. mit einigen wenigen Statusinformationen in Statistic Details integriert werden kann. Beide Monitor Maps sind ungewohnt. Die in Statistic Details gewählte Darstellungsform weicht dabei stärker von dem ab, was man kennt, als die Treemap in System Overview. Viele der Dialoggestaltungsprinzipien (Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität) werden dadurch teilweise ausgesetzt. Es gilt zu prüfen, ob Benutzer einer Monitor Map wie in Statistic Details bereit sind, die Oberfläche zu lernen und wie ihnen das benötigte Wissen vermittelt werden sollte. Für die in Statistic Details gezeigte Halbtransparenz lässt sich mit Java ein effektives Framework bauen. Es ist eine sehr interessante Möglichkeit, in einer Benutzungsoberfläche eine weitere Dimension hinzuzugewinnen ohne tatsächlich schon den Schritt nach 3D zu gehen. Die sehr positiv überraschten Reaktionen der Benutzer auf eine solche Technik sollten unbedingt zur Aufwertung des DB2 Performance Experts benutzt werden. Das Design von Statistic Details wird in folgendem Beispiel noch einmal umgestellt, unter der Verwendung einer Treemap und Halbtransparenz: Abbildung 4.25 zeigt ein über der klassischen Darstellung von Statistic Details schwebendes, halbtransparentes Panel mit einer Monitor Map. Geht man mit der Maus darüber, wird es undurchsichtig, vielleicht sogar größer, und man kann direkt zu dem roten Counter navigieren, den man im zugeklappten Baum gar nicht wahrgenommen hätte. Mögliche Erweiterungen des Prototypen Der Prototyp implementiert nur einen Teil der entworfenen Funktionalität. Die durchgeführten Benutzertests haben zusätzlich eine große Zahl an Möglichkeiten, Erweiterungen und Verbesserungen aufgezeigt. Die entworfenen Funktionen Filter und Show All Names wurden im Test vorgestellt und diskutiert. Abbildung 4.26 zeigt die zugehörige Auswertung. Beide wurden von den Testern als eher nützlich und sinnvoll eingestuft. Der Implementierung von Show All Names, einer Funktion, die zum Beispiel mit Sprechblasen für einen Moment alle Namen der dargestellten Systeme oder Countergruppen anzeigt, spricht nichts entgegen. Eine vollständige Implementierung der Zoomfunktion ist jedoch wichtiger. Außerdem wurde angeführt, dass eine Suchfunktion eventuell die bessere Alternative ist. Ein Eingabefeld in der Toolbar nimmt dabei den gesuchten Wert auf. Wird nach dem Drücken eines Suchen-Buttons dann ein entsprechendes Feld in der Treemap gefunden, so beginnt dieses zum Beispiel zu blinken.

107 4.6 Evaluierung 95 Halbtransparente Monitor Maps zur Navigation halbtransparente kleine Monitor Map zur Übersicht Mouseover - grosse, undurchsichtige Map, Tooltip, Interaktion durch Mausklick Navigation erfolgt - halbtransparente kleine Monitor Map Abbildung 4.25: Alternativer Designvorschlag für Statistic Details, der ebenfalls eine Treemap und Halbtransparenz verwendet Abbildung 4.26: Mögliche unterstützende Monitor-Map-Funktionen - Bewertung der Tester

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten?

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? Messen von Usability Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? 1 Motivation Warum Usability messen? Usability Probleme frühzeitig erkennen Unterschiedliche Bedienelemente / Interaktionsmöglichkeiten

Mehr

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert. Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt

Mehr

Claudia Hewelt Sarah Waschkewitz

Claudia Hewelt Sarah Waschkewitz Claudia Hewelt Sarah Waschkewitz Ziele der Softwareevaluation Anforderungen an die Software Methoden Expertenevaluation Benutzerevaluation Ergebnisse auswerten Optimierung/ Vergleich von Software Benutzerfreundlichkeit

Mehr

User Interface Guidelines - Möglichkeiten und Grenzen

User Interface Guidelines - Möglichkeiten und Grenzen Folie Titel User Interface Guidelines - Möglichkeiten und Grenzen Ellen Reitmayr relevantive AG World Usability Day Berlin 3. November 2005 www.openusability.org Übersicht 1 Einführung Wozu User Interface

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte!

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Aufgabe 1: Grundlagen (5 Punkte) a) Definieren Sie kurz Usability und User Experience.

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Inhalte der Einheit Was ist Usability? Wieso ist Usability wichtig? Vorlesung 2009W Usability Engineering (Christoph Wimmer) Sicherheit in der Softwareentwicklung

Mehr

Uxtâàç á bçäç f~ Ç WxxÑ

Uxtâàç á bçäç f~ Ç WxxÑ Uxtâàç á bçäç f~ Ç WxxÑ Zur Qualität von Software-Oberflächen Prof. Dr. Kurt Schneider Lehrstuhl Software Engineering Leibniz Universität Hannover www.se.uni-hannover.de ks@inf.uni-hannover.de Tel. 0511/762-19666

Mehr

Johannes Rahn 29.07.2010. Usability und User Experience

Johannes Rahn 29.07.2010. Usability und User Experience Johannes Rahn 29.07.2010 Usability und User Experience Seite 2 Inhalt Begriffsdefinitionen: Was ist Usability und was User Experience? Was sind die Unterschiede? Warum ist Usability und User Experience

Mehr

Mit User Experience Design effizient Produkte entwickeln, die begeistern

Mit User Experience Design effizient Produkte entwickeln, die begeistern Mit User Experience Design effizient Produkte entwickeln, die begeistern Die Benutzer machen das Produkt zum Erfolg Der Erfolg eines Softwareprodukts wird in den meisten Fällen an seinem Return On Investment

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Das Lösen von Usabilityund Accessibility-Problemen im IBM Entwicklungsprozess

Das Lösen von Usabilityund Accessibility-Problemen im IBM Entwicklungsprozess Das Lösen von Usabilityund Accessibility-Problemen im IBM Entwicklungsprozess Dirk Willuhn IBM Deutschland Entwicklung GmbH User-Centered Design November 2004 The Early Days User Driven Integration of

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Human-Computer Interaction

Human-Computer Interaction Human-Computer Interaction Masterstudiengang Medieninformatik WS 2013 / 2014 Prof. Dr. Robert Strzebkowski Usability Grundlagen / Einige wesentliche Ansätze 4& Agenda 1.! HCI / Software-Ergonomie / Usability

Mehr

«Web und Multimedia» Usability

«Web und Multimedia» <Grundlagen und Technologien> Usability «Web und Multimedia» Usability 1 Usability: Definition Was ist Usability? Der Begriff «Usability» tritt bei verschiedenen Gelegenheiten z.b. Produkte, Gegenstände, Software...

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Software Ergonomie. als Teil des Software Engineerings

Software Ergonomie. als Teil des Software Engineerings Software Ergonomie als Teil des Software Engineerings Prof. Dr. Ing. Markus Dahm Informatik + Software Ergonomie FH Düsseldorf FB Medien Prof. Dr.-Ing. Markus Dahm RWTH Aachen Wer? Elektrotechnik, TI,

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

FH Trier Entwicklung gebrauchstauglicher Systeme

FH Trier Entwicklung gebrauchstauglicher Systeme Entwicklung gebrauchstauglicher Systeme Inhalt: Gebrauchstauglichkeit: Was ist das? Wie erreicht man das? Begriffe: MMI MMK MCI MMI HMI HCI CHI UCD GUI FH Trier Mensch-Maschine-Interaktion Mensch-Maschine-Kommunikation

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

User Experience und Design

User Experience und Design User Experience und Design Anja Endmann User Experience Researcher 23.04.2014! ? 1. Wie könnte dem Alien geholfen werden? Unterstützt das Wissen um die Does und Don ts im Design? 2. Brauche ich immer einen

Mehr

Portfolio Susann Hamann. Master of Arts Design Bachelor of Arts Interface Design

Portfolio Susann Hamann. Master of Arts Design Bachelor of Arts Interface Design Portfolio Susann Hamann Master of Arts Design Bachelor of Arts Interface Design Die digitale Sanduhr 2006 Teamwork mit Fabian Hemmert Idee, Konzeption, Programmierung & Hardware Prototyping Die digitale

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Content Management Usability. Markus Nix

Content Management Usability. Markus Nix Content Management Usability Markus Nix Usability als Trendthema Immer populärer im deutschsprachigen Raum Content Management Usability (1/51) Contentmanager.days 2004 Usability als Trendthema Immer populärer

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Usability in der Praxis Über uns

Usability in der Praxis Über uns USABILITY USER EXPERIENCE USER INTERFACE DESIGN 3. Juni 2014 Usability in der Praxis Über uns Michael Bechinie Über Uns USECON 2014 2 USECON Experience Design & Consulting Usability, User Experience &

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Without knowledge management our services would be unthinkable. Arthur D. Little

Without knowledge management our services would be unthinkable. Arthur D. Little Without knowledge management our services would be unthinkable. Arthur D. Little Weshalb Wissensmanagement? Wissen ist die Gesamtheit der Informationen, Kenntnisse und Fähigkeiten einer Person, die zur

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

UX Erlebnisse am Frontend

UX Erlebnisse am Frontend creating brand experience ALM Testing UX Erlebnisse am Frontend NOSE Industrial Design 22.04.2013 2 Agenda 1. UI Design 2. UX Design 3. Design folgt Regeln 4. Design macht Marken 5. Design definiert Regeln

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Schön, dass Sie da sind. 16. Juni 2008. E-Commerce im Handel SS 2008 Lehrbeauftragte: Maria-Christina Nimmerfroh

Schön, dass Sie da sind. 16. Juni 2008. E-Commerce im Handel SS 2008 Lehrbeauftragte: Maria-Christina Nimmerfroh Schön, dass Sie da sind. 16. Juni 2008 E-Commerce im Handel SS 2008 Lehrbeauftragte: Maria-Christina Nimmerfroh Personalisierung (Online- Marketing) Anpassung des Angebotes/der Seite/der Elemente an den

Mehr

Forms2Net Die neue Migrations-Software

Forms2Net Die neue Migrations-Software Forms2Net Die neue Migrations-Software Forms2Net transportiert Ihre Oracle Forms Anwendungen perfekt nach Microsoft.NET Darauf haben viele gewartet. Vielleicht auch Sie! Forms2Net ist ein Produktpaket,

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor

Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor WiMi-Care Zwischenworkshop Alexander Steffen 04. November 2010 Agenda 01. Einleitung 02. Normen als Grundlage 03.

Mehr

Vom Funktionieren zum Erleben

Vom Funktionieren zum Erleben Vom Funktionieren zum Erleben Mit höherer Produkt- und Servicequalität zum nachhaltigen Unternehmenserfolg Michael Bechinie Usability User Experience User Interface Design Wozu Usability User Experience

Mehr

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Das Szenario in der Technischen Dokumentation

Das Szenario in der Technischen Dokumentation Workshop mit Silke Schwarzhaupt & Friederike Länge RG-Treffen Stuttgart 25.4.2007 Folie 1 von 21 Workshop Vorstellungsrunde Theoretische Einführung: Szenario und Personas Beispiele aus dem Alltag Pause

Mehr

Human-Computer-Interaction (HCI)

Human-Computer-Interaction (HCI) Human-Computer-Interaction (HCI) von Christian El Boustani im Seminar: Informationsfluss: Dokumentation und Kommunikation im Unternehmen 05.11.2008 Inhalt Einleitung und Motivation Schnittstellen zwischen

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Qualitatives und Quantitatives Usability Testing ein Hybrider Testansatz

Qualitatives und Quantitatives Usability Testing ein Hybrider Testansatz Mensch & Computer 2004, Paderborn Tim Bosenick, SirValUse Consulting Matthias Müller-Prove, Sun Microsystems Die Ausgangslage StarOffice / OpenOffice.org StarOffice Marktführer unter Linux / Solaris /

Mehr

Nutzerzentrierung in der Softwareentwicklung. Herausforderungen im Produkt- & Projektgeschäft

Nutzerzentrierung in der Softwareentwicklung. Herausforderungen im Produkt- & Projektgeschäft Nutzerzentrierung in der Softwareentwicklung Herausforderungen im Produkt- & Projektgeschäft Holger Bär Mitglied der Geschäftsführung CAS Ecosystems 25.09.2013 Marktführer für CRM im deutschen Mittelstand

Mehr

http://www.nvu-composer.de

http://www.nvu-composer.de Kapitel 16 Seite 1 Ein portabler Web-Editor Wer viel Zeit in eine Website investieren will ist gut beraten, eine professionelle Software für Webdesigner zu beschaffen. Diese Programme sind sehr leistungsfähig,

Mehr

Vorwort. Zu dieser Reihe. Autoren. Vorwort

Vorwort. Zu dieser Reihe. Autoren. Vorwort Vorwort 9 10 Vorwort Vorwort Herzlich Willkommen zu einem Fachbuch von Comelio Medien, ein Bereich der Comelio GmbH. Dieses Buch aus unserer Reihe zur.net-entwicklung ist das Ergebnis einer Forschungsarbeit,

Mehr

Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps

Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps Steffen Hess steffen.hess@iese.fraunhofer.de Mobile Business Apps Business Prozesse Services Backend 2 3 Potential von mobilen Business Apps

Mehr

Formwerk AG. Die Sicherstellung konsistenter Nutzungserlebnisse über den gesamten SW-Produktlebenszyklus durch Human Centered Design.

Formwerk AG. Die Sicherstellung konsistenter Nutzungserlebnisse über den gesamten SW-Produktlebenszyklus durch Human Centered Design. Formwerk AG Die Sicherstellung konsistenter Nutzungserlebnisse über den gesamten SW-Produktlebenszyklus durch Human Centered Design. Design on Strategy UX über den Produkt Life Cycle Vor der Nutzung In

Mehr

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python.

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python. 1.3 Aufbau des Buchs lichkeiten offen. Auf die Unterschiede der beiden Versionen gehe ich besonders ein, sodass ein späterer Umstieg von der einen zur anderen Version leichtfällt. Erste Zusammenhänge werden

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Wie misst man Qualität?

Wie misst man Qualität? Software Systems Engineering Wie misst man Qualität? Dr. Privat-Doz. A Herrmann Institut Software Systems Engineering Ziele dieses Workshops Workshop Wie misst man Qualität? Methoden lernen: Herleitung

Mehr

Grafische Benutzerschnittstellen

Grafische Benutzerschnittstellen Grafische Benutzerschnittstellen Benjamin Rust 22. Dezember 2006 Software Engineering Projekt Gliederung 1. Teil: Ergonomie und Gestaltung 1. Die ersten GUIs 2. Software-Ergonomie 2.1. ISO 9241-110 2.2.

Mehr

Usability & Softwareergonomie

Usability & Softwareergonomie Usability & Softwareergonomie Dr. Martina Manhartsberger VÖSI - 14.12.06 About Interface Consult GmbH Gründung: 1994 Positionierung: - Erste österreichische Usability Agentur - Wissenschaftlicher Background

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Software-Ergonomie und Usability Engineering. Anforderungsanalyse Gestaltung Evaluation Ergonomic Customizing Zertifizierung Projektmanagement

Software-Ergonomie und Usability Engineering. Anforderungsanalyse Gestaltung Evaluation Ergonomic Customizing Zertifizierung Projektmanagement Software-Ergonomie und Usability Engineering Anforderungsanalyse Gestaltung Evaluation Ergonomic Customizing Zertifizierung Projektmanagement bao Büro für ARBEITS- und ORGANISATIONSPSYCHOLOGIE GmbH 02

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

UX DESIGN. Kapitel 14 - creating useful persona profiles. Kapitel 15 - designing usable information architectures

UX DESIGN. Kapitel 14 - creating useful persona profiles. Kapitel 15 - designing usable information architectures UX DESIGN Kapitel 14 - creating useful persona profiles Kapitel 15 - designing usable information architectures Kapitel 16 - using sketching to generate and communicate ideas Lukas Christiansen, Martin

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Institut für angewandte Informationstechnologie (InIT)

Institut für angewandte Informationstechnologie (InIT) School of Engineering Institut für angewandte Informationstechnologie (InIT) We ride the information wave Zürcher Fachhochschule www.init.zhaw.ch Forschung & Entwicklung Institut für angewandte Informationstechnologie

Mehr

Benutzbare Produktlinien

Benutzbare Produktlinien Benutzbare Integration von und aspekten in der Anforderungsanalyse Isabel John, Kirstin Kohler, Klaus Schmid Erlangen November 2003 Fraunhofer Institut Experimentelles Software Engineering Sauerwiesen

Mehr

modern - sharp - elegant

modern - sharp - elegant modern - sharp - elegant Das Konzept für Ihre Webseite Wir sind Ihnen gerne bei der Konzeption Ihrer neuen Webseite behilflich. Gemeinsam mit Ihnen analysieren wir Ihre Anforderungen, erarbeiten die Ziele

Mehr

Jazz Rational Team Concert. InfoPoint, 10. Juni 2009 Silver Scherrer

Jazz Rational Team Concert. InfoPoint, 10. Juni 2009 Silver Scherrer Jazz Rational Team Concert InfoPoint, 10. Juni 2009 Silver Scherrer Inhalt Was ist Jazz? Mehrwert von Jazz Jazz Community Rational Team Concert Rational Team Concert Funktionalität Screenshots, Demo Fazit

Mehr

Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache

Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache Dipl. Ing. (FH) Hans-Peter Kiermaier Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache 1 Allgemeines Die Geschichte von VisualBasic oder kurz VB: 1991 Visual

Mehr

Website-Usability - Überprüfung der Gebrauchstauglichkeit von Websites

Website-Usability - Überprüfung der Gebrauchstauglichkeit von Websites Website-Usability - Überprüfung der Gebrauchstauglichkeit von Websites Wie kann man die Gebrauchstauglichkeit feststellen? Es gibt hierzu unterschiedliche Möglichkeiten und Ansätze, die teilweise an die

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

CASE STUDY. CMControl Touchscreen UI. OMICRON electronics GmbH www.omicron.at. Centigrade GmbH www.centigrade.de

CASE STUDY. CMControl Touchscreen UI. OMICRON electronics GmbH www.omicron.at. Centigrade GmbH www.centigrade.de OMICRON electronics GmbH www.omicron.at Centigrade GmbH www.centigrade.de CASE STUDY CMControl Touchscreen UI Hi-Fidelity Prototyping mit Silverlight und SketchFlow Veröffentlicht unter Creative Commons

Mehr

Ergonomische Softwaregestaltung und Barrierefreiheit

Ergonomische Softwaregestaltung und Barrierefreiheit Ergonomische Softwaregestaltung und Barrierefreiheit Steffen Lutter Ergonomische Softwaregestaltung und Barrierefreiheit 1 Motivation 1) Gesundheitliche Aspekte schlechte Software verursacht körperliche

Mehr

Software Engineering Projekt (SEP) mit ROBOCODE

Software Engineering Projekt (SEP) mit ROBOCODE Software Engineering Projekt (SEP) mit ROBOCODE Klaus Knopper Stand: 2014 http://robocode.sourceforge.net/ Kurzbeschreibung Es wird mit den Methoden des Software Engineering in Teamarbeit

Mehr

Eclipse User Interface Guidelines

Eclipse User Interface Guidelines SS 2009 Softwarequalität 06.05.2009 C. M. Bopda, S. Vaupel {kaymic/vaupel84}@mathematik.uni-marburg.de Motivation (Problem) Motivation (Problem) Eclipse is a universal tool platform - an open, extensible

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf

IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Pressemeldung Frankfurt am Main, 02. Februar 2012 IDC-Studie: Software Quality Assurance Unternehmen in Deutschland haben Nachholbedarf Software Quality Assurance wird nicht geliebt aber praktiziert. Die

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features Seite 2 von 11 1. Übersicht MIK.mobile for ipad ist eine Business Intelligence

Mehr

Software-Konfiguration leicht gemacht

Software-Konfiguration leicht gemacht Software-Konfiguration leicht gemacht Marta del Pozo Lagneaux Interface Designer ELO Digital Office GmbH ELO Digital Office GmbH Softwarehersteller seit 1996 Dokumentenmanagement (DMS) Enterprise Content

Mehr

Benutzer-orientierte Gestaltung nach ISO 13407 Der Usability-Engineering-Prozess Evaluationsmethoden Usability und Wirtschaftlichkeit

Benutzer-orientierte Gestaltung nach ISO 13407 Der Usability-Engineering-Prozess Evaluationsmethoden Usability und Wirtschaftlichkeit HCI - 12 - Usability Engineering Benutzer-orientierte Gestaltung nach ISO 13407 Der Usability-Engineering-Prozess Evaluationsmethoden Usability und Wirtschaftlichkeit BHT Berlin Ilse Schmiedecke 2010 Benutzer-orientierte

Mehr

Barrierefreie Software praktisch implementiert. Java-Forum Stuttgart 09.07.2015 Pierre Heim, T-Systems International GmbH

Barrierefreie Software praktisch implementiert. Java-Forum Stuttgart 09.07.2015 Pierre Heim, T-Systems International GmbH Barrierefreie Software praktisch implementiert Java-Forum Stuttgart 09.07.2015 Pierre Heim, T-Systems International GmbH Verbreitete Annahmen zur Barrierefreiheit (I) Realisierung wird oft unterschätzt

Mehr

Programmieren? Das kann ich auch! Bau dir deinen eigenen Bildschirmschoner

Programmieren? Das kann ich auch! Bau dir deinen eigenen Bildschirmschoner Programmieren? Das kann ich auch! Bau dir deinen eigenen Bildschirmschoner Christiane Taras Institut für Visualisierung und interaktive Systeme Universität Stuttgart GEFÖRDERT VON AKTIONSPARTNER Vorstellungsrunde

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

"15 Jahre APM - Wieso haben heutige Projekte immer noch Performance Probleme?"

15 Jahre APM - Wieso haben heutige Projekte immer noch Performance Probleme? "15 Jahre APM - Wieso haben heutige Projekte immer noch Performance Probleme?" Dienstag, 13. Mai 2014-16:45 bis 17:45 Goldsaal B JAX 2014 Stefan Siegl Stefan.siegl@novatec-gmbh.de NovaTec Consulting GmbH

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr