Neue Konzepte in der angewandten Informatik Workbook zur Vorlesung an der Berufsakademie Thüringen, Gera, April 2008

Neue Konzepte

Leitfaden für das UI-orientierte Vorgehen in der Softwareentwicklung Paul Chlebek [[email protected]] http://www.benutzeroberflaeche.de http://www.projectpeople.net/chlebek https://www.xing.com/profile/Paul_Chlebek/

Entwickeln von User Interfaces

User Interface Workbook

Seite 1 von 127

Ein paar Stichworte zum Seminarinhalt

Informatik stellt Lösungen zur Organisation, Vermittlung und Umformung von Informationen bereit. Mit dem Aufkommen von elektronischen Rechnersystemen ist die Informatik zu einer eigenen wissenschaftlichen Disziplin geworden.

Entwickeln Informatik

Know How

Software

Wettbewerber Technologie

Markt

Die Arbeit von Informatikern besteht oft im Entwickeln von Softwarelösungen für eingebettete und nicht eingebettete Rechnersysteme; in der Regel ist die Hardware- und Betriebssystemumgebung dabei vorgegeben. Die als Rechnersystem bezeichnete Art von Hardware ist vom Prinzip her gesetzt: Wir verwenden in der Praxis seit Jahrzehnten fast ausschliesslich Von-Neumann-Rechner, freilich mit immer besseren Prozessoren, Speichern, Ein- und Ausgabegeräten und Betriebssystemen. Das technologische Umfeld der Softwareentwickler ist durch PCs, grafische Oberflächen und Fenster-SDKs, Java, XML, etc. ebenfalls relativ klar umrissen. Die Werkzeuglandschaft ist nach wie vor vielfältig, die Unterschiede zwischen den Werkzeugen und Migrationshürden werden aber kleiner (zum Beispiel wegen Eclipse und Java). Zunehmend wichtig wird daher neben technologischer Kompetenz der Entwickler die Methodenkompetenz beim Entwickeln von Anwendungsszenarien, und beim Erarbeiten von Anforderungen zusammen mit Anwendervertretern (einschließlich der sozialen Kompetenz). Die Aufgaben des Informatikers verlagern sich in Zukunft von der Arbeit mit Maschinen zur Arbeit mit Menschen.

In der praktischen Informatik werden heute hauptsächlich individuelle Softwarelösungen erstellt und verkauft. Markt und Wettbewerb bestimmen die Rahmenbedingungen für Softwareprojekte.

User Interface Workbook

Der Markt gibt vor, welche Lösungen gewünscht werden. Der Wettbewerb sorgt für Kostendruck. Das Beherrschen der Technologien wird z.B. durch das Geschäft mit Offshore Implementierung billiger. Es reicht nicht die Technologie zu beherrschen um im Wettbewerb zu bestehen. Prozesse: Wie man in einem Projekt alles zusammenbringt, was dabei alles passieren kann und wie man das Erwünschte begünstigt und das Unerwünschte vermeidet. Methoden und Tools: Wie bestimmte Aufgaben am besten bewältigt werden („best practices“) und was man dazu verwenden kann. Wichtig Abgrenzung zwischen Methode und Werkzeug (z.B. UML & Together, Loch bohren & Hilti). Seite 2 von 127

Seminarüberblick Montag

Dienstag

#01

#04

Mensch und Informatik

Informationsmodell eines User Interface

#07 Von der Skizze zur Implementierung

#02

#05

MMI Arten und Typen

UIs Modellieren mit UML und DSLs

Requirement-, KonfigurationsÄnderungs- und Testmanagement

11:3013:00

#03

#06

#08

UI Modelle erlebbar machen

Projektmanagement

13:3014:15

Spezifikationsbedarf und Spezifikationsformen

08:0009:30

09:4511:15

User Interface Workbook

-

Donnerstag

Das Seminar wird im Blockunterricht an drei Tagen gehalten. Einige Themen bauen aufeinander auf, die meisten erfordern jedoch kein besonderes Vorwissen. Das Seminar richtet sich an Informatik-Studenten ab dem 5. Semester und an Softwareentwickler. In dem vermittelten Stoff geht es um die Praxis der Auftragsentwicklung von Software, insbesondere um die þ þ þ

Abstimmung der Features zwischen Auftraggeber und Softwarehersteller, die Modellierung der Anwendung aus Anwendersicht, und um die Bestätigung / Nachweis der zugesicherten Features.

Insofern ist das Seminar auch für bereits berufstätige Entwickler und Projektleiter interessant. Eine weiterführende Sicht auf benutzerzentrierte Entwicklungsstrategien finden im Buch „User Interface orientierte Softwarearchitektur“ von Paul Chlebek.

Neue Vorgehensweisen etablieren Weiterführende Themen

Seite 3 von 127

Anmerkungen zu den Unterrichtseinheiten #01 Mensch und Informatik

#05 UIs Modellieren mit UML und DSLs

Seminar-Überblick, Menschen und ihre Werkzeuge, Werkzeugbauer und Werkzeugnutzer, Mensch- Maschine Schnittstelle

Was verwendet man wann und wo setzt man Schwerpunkte: Use Case Diagramme, Sequenzdiagramme, Aktivitätsdiagramme, Klassendiagramme.

Vom Faustkeil zur Software, nicht unbedingt ein Fortschritt (der Faustkeil lag besser in der Hand). Excel: Ein Faustkeil der Informatik oder ein Schweizer Taschenmesser? Was ist überhaupt eine Mensch-Maschine-Schnittstelle oder ein User Interface und gibt es das erst seit es Computer gibt?

Domänenspezifische Sprachen drücken bei hoher Informationsdichte fachliche Sachverhalte kurz und effizient aus. Probleme bei Anwendung von DSLs können durch unterschiedliche Interpretation der Sprachkonstrukte und durch variierende implizite Annahmen bei ihrer Verwendung auftreten.

#02 MMI Arten und Typen

#06 Modelle erlebbar machen

(Keine) Mensch-Maschine Kommunikation, Funktion und Aufbau eines User Interface, Geschichtlicher Überblick, Verschiedene Formen von User Interfaces

Datenstrukturen für eine UI Simulation.

Maschinen verwendet man, aber man kommuniziert mit ihnen nicht. Äußerst wichtig und entscheidend für den Projekterfolg dagegen ist die Kommunikation zwischen den an der Entstehung einer Software beteiligten Personen. Heute überwiegen formular-, listen- und menüorientierte, grafische UIs, aber es gibt auch andere UIs.

Architektur einer Ablaufmaschine, die User Interface Modelle verarbeitet und diese z.B. als Maskenprototypen darstellt, als Simulation oder als Echtmodul verfügbar macht.

#03 Spezifikationsbedarf und Spezifikationsformen Was im Pflichten/Lastenheft bzw. in der Spezifikation steht, das soll die Software am Ende leisten. Dafür gibt es verschiedene Möglichkeiten mit eigenen Schwierigkeitsgraden, Vor- und Nachteilen. #04 Informationsmodell eines User Interface Hat man das UI einer Software vollständig beschrieben, dann ist aus Benutzersicht alles festgelegt, was die Anwendung können und machen soll. Für diese wertvollen Informationen lässt sich ein Datenmodell aufstellen, mit dem sich die Angaben strukturieren und validieren lassen.

User Interface Workbook

Generieren von Prototypen, Codegerierung, Model-Engines, Beispiel: Dialog-Seitengenerator mit XML,XSL und HTML

#07 Verwaltungsmethoden Requirement-, Konfigurations-, Änderungs- und Testmanagement

Test-Management: Wie man die Erfüllung von Anforderungen und andere Eigenschaften des SW-Produkts nachweist. Cross Life Cycle Management: Warum die in einem bestehenden SW-Produkt gewachsenen fachlichen Anforderungen an Funktion und Handhabung der SW wertvoll sind und wie man diese in die nächste Generation des SW Produkts hinüberrettet. #08 Projektmanagement, neue Vorgehensweisen etablieren Do’s und Don’t Do’s des Projektmanagements, Rollenverteilung, Kompetenzabgrenzung, Konflikt- und Risikomanagement. In einer Organisation stoßen Innovationen oft auf Skepsis. Aus Sicht des Managements kann diese Skepsis das Kosten/Nutzen Verhältnis der neuen Methoden betreffen. Aus Sicht der Entwickler kann die Angst vor Mehrbelastung und vor Verlust des Expertenstatus Ursache für Ablehnung neuer Vorgehensweisen sein. Weiterführende Themen: Links zu HCI/MDA Ressourcen im Web, GUI Generatoren, Entwicklungstendenzen in der UI Gestaltung, XML- UML- und DSL Werkzeuge im Überblick

Requirement-Management: Wie man die Anforderungen an die Software erhebt, verwaltet und mit Lösungskonzeption, Umsetzung, und Funktionsnachweis verknüpft. Konfigurations-Management: Wie man verschiedene Stände und Zustände der Entwicklungsartefakte verwaltet, ablegt, findet, nachvollzieht und wiederherstellt. Änderungs-Management: Wie man Die Quellen, Ursachen und Inhalte von Änderungen an Anforderungen, Konzeption, und Umsetzung verwaltet, und mit den Entwicklungsartefakten (z.B. mit Spezifikationen) verknüpft.

Seite 4 von 127

#01

Definitionen: þ

Mensch und Informatik

þ

þ

Human–computer interaction (HCI), alternatively manmachine interaction (MMI) or computer–human interaction (CHI), is the study of interaction between people (users) and computers. It is an interdisciplinary subject, relating computer science with many other fields of study and research. Interaction between users and computers occurs at the user interface (or simply interface), which includes both software and hardware, for example, general purpose computer peripherals and large-scale mechanical systems such as aircraft and power plants. Human-computer interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them. (Definition der ACM SIGCHI) Der Begriff Interaktion setzt sich aus Inter (=drückt etwas aus, das sich „verbindet“) und Aktion (=Synonym für Handlung, Tat, Ereignis) zusammen. Also eine gegenseitige Beeinflussung von Handlungen zwischen verschiedenen Handelnden. [Auer]

Lernziele für #01: þ þ

Erklären können was ein UI ist, und wie es vom Rest eines Werkzeugs abgegrenzt wird. Grundbegriffe, die mit dem UI zu tun haben, erklären können.

Informatiklaien begegnen der Informatik im Alltag durch das Anwenden von Computerprogrammen. Informatikspezialisten nehmen in verschiedenen Rollen am Entwickeln und am Betreiben von Informatikanwendungen teil.

User Interface Workbook

Seite 5 von 127

Roter Faden: Was sollen neue Konzepte bringen?

Pole Position ist: þ

Als Entwickler in der Pole Position stehen

Prozesse und Vorgehensweisen

þ

Interessante Projekte Gute Erträge Planungssicherheit

þ

Methoden & Tools Deeper understanding on what we work

Understanding the subject: þ þ

Lösungsbedarf und Lösungsansätze

Ausgangssituation in der angewandten Informatik von heute; Problemstellungen der Anwendungsentwicklung

Die eigentlichen Ziele der neuen Konzepte sind in der Ausbildung nur als Potentiale erreichbar. Sie liegen außerhalb des zusicherbaren Ergebnisraums einer Informatikerausbildung.

User Interface Workbook

Erlebbar qualitativ hochwertige Produkte und Leistungen herstellen, weil man dann als Anbieter von Entwicklungsleistungen in die engere Auswahl potentieller Auftraggeber kommt. Ein Set aus Vorgehensweisen, Methoden und Tools in Petto haben, das den Kunden effizient und zufriedenstellen in den RE-, SE-, TM- und QA Prozess einbezieht, weil man dann als Kompetenter Anbieter empfohlen wird. Kostengünstig, schnell, transparent und für Kunden erlebbar entwickeln, weil man dann als Dienstleister überzeugt und mit größter Wahrscheinlichkeit einen Auftrag bekommt.

þ

Conditions of Software Development: Wann wird Zeit / Arbeit / Geld in die Entwicklung einer Software investiert? Entstehungsprozess einer Software in Phasen / Aufgaben / Meilensteinen / Teilergebnissen. Architektur einer Anwendungssoftware. Funktions-weise und Aufbau einer Softwareoberfläche.

Situation, Complication, Prospects: þ

þ

þ

þ

Standardsoftware ist entwickelt. Individualsoftware und Customizing wird von finanzstarken Unternehmen in Auftrag gegeben. Oft lange Projektlaufzeiten, hohe Kosten, enttäuschende Ergebnisse. Nachbesserung in CRs. Kostenreduktionsversuche mit Offshore-Engineering. Software wird of am Kunden vorbei entwickelt. Prototypisches Entwickeln hilft, wird aber nur in der frühen Projektphase praktiziert. Kunden fordern Teilergebnisse und Spezifikationen, die sie als Informatiklaien verstehen und nachvollziehen können.

Seite 6 von 127

Persönlicher roter Faden

Übung: Beantworten Sie die Fragen aus eigener Sicht, Zeit: 15 Minuten

Als Entwickler in der Pole Position stehen

Welche Prozesse würden Ihnen helfen?

Woran messen Sie, dass Sie ein erfolgreicher Informatiker sind?

Welche Methoden bräuchten Sie, um besser zu arbeiten? Welche Werkzeuge würden Ihnen helfen? Was ist eigentlich Softwareentwicklung? Was macht ein Informatiker als SW-Entwickler?

Was gefährdet Ihre Position im Unternehmen als Entwickler etc.? Wie können Sie als Entwickler etc. Ihre Position im Unternehmen stärken? Was würde Ihnen helfen, im Wettbewerb mit Offshore-Engineering gut da zu stehen? Haben sie coole Projekte, klasse Produkte und volle Auftragsbücher? Was stört sie, wenn Sie an die tägliche Arbeit als Informatiker denken? Welche Widerstände erfahren sie?

Berufliche Ziele hängen von der eigenen Situation und von der persönlichen Sichtweise des Betrachters ab.

User Interface Workbook

Seite 7 von 127

Überlegungen zum Bau von Werkzeugen, Gebäuden und Software Thesen: • Software ist ein abstraktes Werkzeug, ihre Benutzeroberfläche ein realer Zugang zu diesem Werkzeug • Beim Bauen von Software erleben wir Formulierungs- und Kommunikationsprobleme. Die für Häuser- und Werkzeugbau entwickelten Techniken wurden für den Softwarebau adaptiert. Software-Projekte verlaufen aber oft anders als geplant. Schlussfolgerungen: • Die Adaption von Ingenieurmethoden genügt nicht, weil die Bestandteile einer Software während ihres Baus gar nicht und nach ihrer Vollendung nur mittelbar (über ihre Benutzeroberfläche) anfassbar sind. • Die Abstraktheit von Software und von Sprache kann sich gegenseitig verstärken (weil beide keine physikalischen Grenzen haben). Deshalb ist die Benutzeroberfläche als einziges erlebbares und anfassbares Teil einer Software wichtig für die Kommunikation zwischen den am Bau einer Software beteiligten Personen. User Interface Workbook

Vergleich von Softwarebau mit Häuser- und Werkzeugbau: Software bildet Vorgänge aus der realen Welt nach. Genauso wie bei einem Gebäude muss man bei einer Software ihre Teile und Verbindungen zwischen ihnen planen (Architektur). Wie bei einem herkömmlichen Werkzeug muss man bei einer Software ihre Verwendungs- und Funktionsweise planen. þ þ þ

Konfuzius: Jedes Ding hat ein Ziel und ein Prinzip Wittgenstein: Was man nicht beschreiben kann, das darf es nicht geben Volksmund: Was der Bauer nicht kennt das frisst er nicht

„Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt“ (Tractatus 5.6). In diesem Sinne gibt Wittgenstein im Vorwort der Logisch-philosophischen Abhandlung an: „Man könnte den ganzen Sinn des Buches etwa in die Worte fassen: Was sich überhaupt sagen lässt, lässt sich klar sagen; und wovon man nicht sprechen kann, darüber muss man schweigen.“ Diese Interpretation Wittgensteins berücksichtigt nicht, dass Sprache in ihrer ständigen Weiterentwicklung zunächst unscharfe Inhalte transportiert, die erst im Lauf der Verwendung in einer kleinen Domäne zu scharf abgegrenzten Begriffen werden. Beispiel hierfür sind Fachsprachen (domänenspezifische Sprachen), z.B. Ärztelatein, Amtschinesisch, Entwicklerdenglisch. Eine Fachsprache (auch Fachjargon) ist ein Jargon, der in einem Fachgebiet oder einer Branche benutzt wird. Zur Fachsprache gehören vor allem Fachbegriffe und Fremdwörter (Fachvokabular), die entweder außerhalb des Fachgebietes sehr ungebräuchlich sind oder in diesem eine andere Bedeutung haben. Auch Grammatik und Intonation können sich unterscheiden.

Seite 8 von 127

Entscheidungsbäume enthalten explizite und implizite Informationen; Beispiel: Das Tee-Auswahl-Phänomen

Die Auswahl des Getränks nach dem nebenstehenden Ritual ist, wenn man sich auskennt, höchstens lästig, nicht weiter schwierig.

• Tee bitte.

Übertragen Sie aber den Dialog auf einen Dienst- oder Werkauftrag, z.B. über die Herstellung eines Tisches, einer Spezialmaschine, oder einer Software, wird schnell klar, dass man mit jeder bewusst angeforderten bzw. aus dem Angebot ausgewählten Eigenschaft des Produkts implizite Entscheidungen über weitere Eigenschaften trifft, die man als Kunde vielleicht nur ungern in Kauf nimmt, oder diese aber das Produkt für den Kunden unbenutzbar machen.

• Was für einen Tee? Früchtetee, Pfefferminz, Schwarztee? Wir haben auch Lassi, ist gut gegen Durst.

Kännchen oder Tasse? Asam oder Earl Grey? Sollen die Tischfüße mit Spannkrallen oder mit gespoilten Aluspannern am Tisch befestigt werden? Möchten Sie ein doppelgegenverdröhntes FTP-Snapbackprotokoll an Ihrer Verwaltungssoftware?

• Irgendeinen Tee, nur keinen Aufwand.

Werkzeugbauer und Werkzeugnutzer, Untersuchen der Parallelen zur Rollenverteilung von Restaurantbesucher, Kellner und Koch.

• Ich habe Durst. Hast Du einen Schluck Tee oder Kaffee? • Was möchtest Du trinken? Kaffe, Tee oder lieber etwas Kaltes?

• Du musst schon selbst wissen, welchen Tee Du haben willst. Kamille?

Übung:

• Lieber schwarzen Tee.

Dialoge zwischen Besteller und Dienstleister.

• Mit Milch und Zucker oder mit Zitrone?

Versuchen Sie den Dialog aufzuschreiben bei

• Milch und Zucker. • Brauner Zucker, Kandiszucker, Kristallzucker? • Egal. • Mit Kandiszucker? Oh, der schwarze Tee ist aus. Möchtest Du vielleicht vorerst ein Lassi?

Zeit: 15 Minuten þ þ þ

Bestellen eines Schreibtisches (Bettes, Schranks) beim Schreiner Bestellen eines Computers beim Fachhändler Bestellen eines Maßanzugs für ...

Wählen Sie ein Fallbeispiel aus oder konstruieren Sie eine selbst erdachte Situation. Gehen Sie auf die Unsicherheiten beim Verwenden der Fachsprache und versuchen Sie sicherzustellen, dass das georderte exakt Ihren Vorstellungen entsprechen wird.

• Ja bitte. Was ist das? User Interface Workbook

Seite 9 von 127

Informations- und Prozessarchitektur für die benutzerzentrierte Softwareentwicklung – Fokussierung Ziele: • Überblick über benutzerzentrierte Entwicklungsstrategien • Anwenden von ausgewählten Entwicklungsmustern

Software entsteht aus dem Bedarf heraus, eine wiederholbare Funktionalität zur Verfügung zu stellen. Der Anspruch an die Softwareusability steigt, weil das Verwenden von Computern zu einer üblichen Kulturtechnik wie Lesen, Schreiben oder Telefonieren geworden ist. Es gehört zum Alltag des modernen Menschen, Software anzuwenden. Dadurch wird Software wie ein täglicher Gebrauchsgegenstand (keine Mystik, keine Ehrfurcht) verwendet und bewertet. Schlussfolgerung: Neue Konzepte sind notwendig, um den steigenden Anspruch an Benutzerfreundlichkeit und Integration von Software-Anwendungen zu erfüllen.

Themen: • Begriffsklärung, Zweck, Nutzen, Motivation • Wir brauchen eine bessere Architektur, weil wir sonst am Auftraggeber (Kunden, Anwender) vorbei arbeiten • Ansätze für Prozessarchitektur, Ansätze für Informationsarchitektur • Entwicklungsmuster (Patterns) für das benutzerzentrierte Entwickeln (z.B. Use Cases, Aktivitätsdiagramme, Dialogdiagramme und User Interface Spezifikationen, auf Informationsarchitektur gestützte Oberflächenprototypen)

User Interface Workbook

Seite 10 von 127

Begriff „User Interface“

In der DIN EN ISO 9241-110 ist der Begriff der Benutzungsschnittstelle definiert als „Alle Bestandteile eines interaktiven Systems (Software oder Hardware), die Informationen und Steuerelemente zur Verfügung stellen, die für den Benutzer notwendig sind, um eine bestimmte Arbeitsaufgabe mit dem interaktiven System zu erledigen.“

Ein User Interface ist das, womit wir ein Werkzeug oder eine Maschine benutzen, z.B. der Griff einer Schaufel, der Henkel einer Tasse, der Cockpit eines Fahrzeugs, Dialogfenster, Knöpfe, Sprachinterpreter, u.v.m.

þ

The user interface is the aggregate of means by which people (the users) interact with a particular machine, device, computer program or other complex tool (the system). The user interface provides means of Input, allowing the users to manipulate a system, and Output, allowing the system to produce the effects of the users manipulation.

Es gibt verschiedene Arten von Benutzungsschnittstellen. Sie unterstützen unterschiedliche Formen der Mensch-Maschine Interaktion, haben unterschiedliche Dialogmittel und werden in unterschiedlicher Weise eingesetzt

User Interface Workbook

HCI = Human Computer Interaction HMI = Human Machine Interface MMI = Mensch Maschine Interface MMS = Mensch Maschine Schnittstelle UI = User Interface GUI = Graphical User Interface VUI = Voice User Interface

Fachliche Schwerpunkte der HCI sind zum Beispiel: þ þ þ þ þ

þ þ þ

Grundlagen der Software-Ergonomie Gestaltung und Evaluation von Benutzungsschnittstellen Vorgehensweisen und Methoden zur Systemgestaltung (z.B. Prototyping, partizipative Systemgestaltung) Entwicklungswerkzeuge für Benutzungsschnittstellen Neue Formen der Mensch-Rechner-Interaktion, wie z.B. Multimedia, Eingabe durch Sprache, Handschrift oder Gestik, virtuelle Realität, nomadic and wearable Computing Adaptive Benutzungsschnittstellen Gestaltung für Personengruppen mit besonderen Anforderungen (z.B. Barrierefreiheit für Behinderte) Anwendungen software-ergonomischer Systemgestaltung, z.B. bei Gestaltung rechnerunterstützter Arbeits-, Lernund Kooperationsprozesse sowie von Wissensmedien

Seite 11 von 127

Begriff „Usability“ Zu Deutsch: Gebrauchstauglichkeit, Benutzbarkeit Der Begriff Usability stammt aus dem amerikanischen Englisch. Er setzt sich aus zwei Worten zusammen, dem Verb to use (benutzen) und dem Nomen ability (Fähigkeit). Übersetzt wird der Begriff oft mit Gebrauchstauglichkeit und Brauchbarkeit. Mensch und Benutzungsschnittstelle stehen zueinander in einer engen Beziehung. Die Qualität dieser Beziehung wird als Gebrauchstauglichkeit bezeichnet. Gemeint ist damit, dass man etwas ohne Probleme benutzen kann. Ziel des Usability Engineering: Man soll etwas herstellen, was „handlich“, also angenehm und effektiv im Gebrauch ist Die Gebrauchstauglichkeit beruht unter anderem auf Gebrauchsgewohnheiten und den Bedürfnissen des Nutzers; somit gibt es neben einer objektiven Beurteilung auch eine subjektive Erfahrung, die von Individuum zu Individuum sehr unterschiedlich ausfallen kann.

User Interface Workbook

Bei traditionellen Werkzeugen und Maschinen (solchen, die keinen Softwareanteil haben) sind User Interfaces ein integraler Bestandteil (z.B. Griffe, Hebel, Drehregler, Knöpfe). Oft fließen Erfahrungen von Generationen in die Bau- und Verwendungsweise dieser Werkzeuge ein. Computerbasierte Werkzeuge und deren User Interfaces sind ebenfalls diesen Erfahrungsprozessen unterworfen. Der Henkel einer Tasse ist ihre Benutzerschnittstelle. Ein auf der Innenseite der Tasse angebrachter Henkel funktioniert zwar mechanisch genauso, stellt jedoch den Anwender beim Verwenden des Henkels, insbesondere in Kombination mit Heißgetränken, vor große Herausforderungen. In der ISO Norm 9241 wird Usability als das Ausmaß definiert, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufrieden stellend zu erreichen. [Schumacher] þ

þ

þ

Die Effektivität oder der Wirkungsgrad beschreibt alle funktionalen und nichtfunktionalen Aspekte des Produktes, wie seine Verlässlichkeit und Haltbarkeit. Die Effizienz beschreibt die Anstrengung des Nutzers, sein Ziel zu erreichen im Verhältnis zu den dazu benötigten Arbeitsschritten. Die Zufriedenheit ist die subjektive Bewertung der Effektivität durch den Nutzer und beschreibt keine technischen Attribute. Der Nutzungskontext besteht aus den Benutzern, Arbeitsaufgaben, Arbeitsmitteln (Hardware, Software und Materialien) sowie der physischen und sozialen Umgebung, in der das Produkt eingesetzt wird.

Seite 12 von 127

Usability (II) - Erwartungshaltungen

Aktionserwartung þ þ þ

Anwender: Was muss ich (als Anwender) machen, damit die Anwendung etwas macht? Oberfläche: Oberfläche wartet auf Ereignisse, die sie interpretieren kann. Entwickler: Eingabeelemente, über die die Oberfläche der Anwendung die Anweisungen des Benutzers empfängt.

Beispiel: Um einen neuen Kundendatensatzes zu erfassen, wird der Punkt ‚Neuer Kunde…’ aus dem Menü gewählt. Reaktionserwartung

Anwender à Reaktionserwartung

Oberfläche ß Aktionserwartung

þ þ þ

Beispiel: Wenn ein Punkt aus dem Menü gewählt wird, wird die zu diesem Punkt passende Dialogseite eingeblendet. Konvergenzerwartung þ

à Konvergenzerwartung à Erfahrungserwartung à Funktionserwartung Der Anwender verwendet einen Computer auf Grundlage seines sozialen und kulturellen Hintergrunds. Seine Erwartungen an das User Interface beruhen auf diesem Hintergrund.

Anwender: Was tut die Anwendung, wenn ich das mache? Oberfläche: Alle Aktionen wahrnehmbar quittieren. Entwickler: Welche Reaktionen zeigt die Anwendung auf Eingaben (oder auf Eingabeversuche) des Anwenders?

þ þ

Anwender: Wenn ich das Gleiche wieder mache, macht die Anwendung auch wieder das Gleiche oder etwas anderes? Oberfläche: Die Reaktionen der Oberfläche sollen für den Anwender einem leicht nachvollziehbaren Muster folgen. Entwickler: Wann folgen auf die gleichen Eingabefolgen die gleichen Reaktionen der Anwendung?

Beispiel: Wenn zwei Mal hintereinander ‚Speichern’ gewählt wird, könnte in der Statusleiste ‚Speichern nicht nötig.’ erscheinen. Die Oberfläche könnte auch die Aufforderung zum Speichern ignorieren oder jedes Mal Speichern. Erfahrungs- und Funktionserwartung þ þ þ

Anwender: Tun die Knöpfe das, wonach sie aussehen? Oberfläche: Die Bedienungsmetaphern sollen sich an der Alltagswelt orientieren. Entwickler: Kann der Anwender aus Bedienungselementen und aus Erfahrungen mit zweckverwandten Anwendungen auf die Reaktion dieser Anwendung schließen?

Beispiel: Wenn eine Schaltfläche mit „ÿ Start“ beschriftet ist, erwartet der unerfahrene Anwender eventuell, dass das gerade zuvor angeklickte Desktopsymbol gestartet wird. User Interface Workbook

Seite 13 von 127

Usability (III) – Form und Funktion Für das User Interface ist die Art, wie es verwendet wird, und damit der Anwender maßgeblich. Form follows Function à Function follows Use Case / Misuse Case à Form follows User

Form: die Art und Weise, wie etwas ist oder sich verändert, z.B. die äußere Gestalt eines Objektes; die Art, wie etwas ausgeführt wird / wurde; Gestalt, Erscheinung, Morphologie; die Art und Weise, wie etwas strukturiert ist; die Art und Weise, wie eine Handlung vollzogen wird [Wikipedia] Funktion: Die Aufgabe oder der Zweck, dem ein Element in einem System nachkommt. Die Funktion von technischen Systemen besteht in der Überführung der Eingangsgrößen (Stoff, Energie, Information) unter Berücksichtigung von Parametern in die umgewandelten Ausgangsgrößen (Stoff, Energie, Information). Da technische Systeme künstliche Gebilde sind, werden sie von Menschen nur dann erschaffen, wenn diese eine gewünschte Funktion erfüllen. [Wikipedia] Als Zweck wird der Beweggrund einer zielgerichteten Tätigkeit oder eines Verhaltens verstanden. Das Ziel als Anlass für eine Handlung wird als Zweck- oder Finalursache bezeichnet. In der mit der Formulierung des Ziels einhergehenden Ziel- oder Zwecksetzung muss unterschieden werden zwischen

Verwendung

Form Funktion

Der bekannte Satz „Form follows Function“ kann zu dem Missverständnis führen, dass seine Funktion ein Werkzeug hinreichend beschreiben kann. Zum Beispiel soll ein Fotoapparat photographieren, aber diese Funktion wird unter Wasser anders verwendet als in einem Passbildautomat. User Interface Workbook

þ þ þ

1. einer Vorstellung der Wirkung der zielgerichteten Handlung, 2. dem Bestreben dieses Ziel über die reine Vorstellung oder Imagination hinaus wirklich werden zu lassen und 3. die Imagination eines Mittels, das formulierte Ziel zu erreichen. [Wikipedia]

Es gilt „Function follows Use Case“. Die Form orientiert sich an der Funktion, aber auch an der Verwendung des Werkzeugs, weil die Funktion davon abhängt, wie, von wem und unter welchen Umständen das Werkzeug verwendet wird. Ebenso gilt „Form follows misuse/misfunction“. Die Form berücksichtigt dabei den möglichen Fehlgebrauch oder Missbrauch des Werkzeugs, um diesen zu verhindern. þ þ þ þ

Die Verwendungsweise hat einen höheren Rang als die Funktionsweise. Die Funktionen ergeben sich aus Verwendungsfällen. Die technische Umsetzung der Funktionen ergibt sich aus der verfügbaren Technologie. Das User Interface ergibt sich aus den Verwendungsfällen, wird aber von der technischen Umsetzung beschränkt.

Seite 14 von 127

Usability (IV) – Mechanische und kulturelle Metaphern Kontrollelemente eines Software User Interface empfinden die dem menschlichen Anwender aus der physischen Welt bekannten Werkzeuge und Maschinen nach: Hebel, Knöpfe, Regler, Papierkorb, Aktenordner, etc.

Kognitive Wissenschaften und die Usability-Forscher beschäftigen sich unter anderem damit, wie die Informationen an der Oberfläche dargestellt werden und wie Eingabeelemente aufgebaut sein müssen, damit sie für den Anwender intuitiv und optimal verwendbar sind. Während die mechanischen Metaphern (z.B. Einrasten einer Schaltfläche beim Draufklicken) von allen Menschen ähnlich wahrgenommen werden, hängen andere Oberflächeneigenschaften (z.B. Farben, Piktogramme) vom kulturellen und sozialen Hintergrund der Anwendergruppe ab. þ

þ þ

þ

Farbgebung: Rot ist eine Signalfarbe, sollte nur verwendet werden, wenn man ein Signal geben will, nicht um z.B. Abbrechen-Buttons zu kennzeichnen Grün und Gelb sind ebenfalls Signalfarben Fettschrift: Diese Dinge liest man zuerst (Wenn man Beschriftungen von Dialogfeldern und Tabellenköpfe fett macht, lenkt man von den Inhalten ab) Feldgruppen: Feldgruppen mit gleichem Inhalt sollten gleich angeordnet sein (z.B. Adressangaben, Vorgangsinformationen) und Felder mit gleicher Bedeutung sollten gleich beschriftet sein und gleiche Breite haben.

Bei dem Versuch, das Verhalten von Software zu verstehen, greift der Nutzer auf seine Erfahrungen mit der realen Umwelt zurück. Er erwartet intuitiv, dass die Software gewissermaßen den Gesetzen der Mechanik folgt, was aber oft nicht der Fall ist.

Bei Brettspielen ist dieser Transfer von Hardwareeigenschaften nach Software besonders klar und nachvollziehbar zu beobachten.

User Interface Workbook

Eine konsequente Anlehnung der Bedienung und des Verhaltens von Oberflächenelementen an mechanische Gesetze und Kulturtechniken kann sich positiv auf die intuitive Anwendbarkeit von Softwareprogrammen auswirken. Hier können UI-Entwickler und Usability-Forscher von traditionellen Handwerkzeugen lernen. Bei abstrakten Kontrollelementen werden die Gesetze der Mechanik nachempfunden, damit der Benutzer auf seine vertraute Erfahrungswelt zurückgreifen kann.

Seite 15 von 127

Usability (V) – Intuition und Abstraktion Der Benutzer benötigt die Basis-Assoziation zur wirklichen Welt, um das User Interface intuitiv verwenden zu können.

Intuition Abstraktion

Werkzeuge können in mechanische und abstrakte Systeme gegliedert werden. Ein Buch ist mechanisch und unterliegt dadurch intuitiv erfassbaren Regeln. Software ist abstrakt: Sie unterliegt keinen mechanischen Gesetzmäßigkeiten. Dies ist eine ihrer Stärken und zugleich ein Risiko. Beispiel Spaten: 100% mechanisch. Der funktionelle Anteil des Spatens ist sein Blatt. Der Spatenstiel ist sein User Interface. Er macht die Funktion des Spatenblatts für Menschen verwendbar. Wie man einen Spaten richtig hält, ist Software. Diese Verwendungsregeln liegen im Kopf des Verwenders. Beispiel Brettspiel: Mechanische Repräsentation abstrakter Regeln. Der funktionelle Anteil des Go-Spiels ist das Legen von schwarzen und weißen Punkten auf ein Brett mit 19x19 Linien. Das Go-Brett mitsamt Steinen ist das Hardware-UI dazu. Der Softwareanteil des UI sind die Legeregeln (nicht die Spielregeln, die algorithmisch-funktioneller Natur sind), z.B. das Steine auf Schnittpunkte von Linien und abwechselnd gelegt werden. Beispiel PDA: Abstrakte Repräsentation abstrakter Regeln. Der funktionelle Anteil des PDA ist das Notieren und wieder Auffinden von Informationen (Adressbuch, Terminkalender, Aufgabenliste, Nachschlagewerk, etc.). Das UI besteht aus dem Bildschirm und den Knöpfen im Gehäuse sowie i.d.R. einem Zeigestift (Hardware), aus den Bildschirminhalten, die die abgefragten Informationen/Aktionen und Interaktionen zwischen Verwender und Gerät anzeigen sowie aus den Regeln, nach denen diese Interaktionen die Funktionen des Geräts steuern. Die Interaktion eines Papierbuches mit seinem Nutzer ist mechanisch und kulturell klar geregelt. Wenn beim Blättern in einem Buch plötzlich die eben umgeblätterte Seite Flammen fängt oder Buchstaben sich in Nichts auflösen, wenn das Buch zu Staub zerfällt oder andere okkulte Aktivitäten entwickelt, wissen wir intuitiv, dass dies nicht normal ist.

Je höher der Abstraktionsgrad, desto weniger kann ein Werkzeug intuitiv verwendet werden. User Interface Workbook

Wenn eine Software nicht die intuitiv erwarteten Aktivitäten unternimmt, z.B. wenn Dialogseiten plötzlich nicht an gewohnter Stelle erreichbar sind, oder wenn Dialogelemente plötzlich erscheinen oder verschwinden, sprechen wir von Features oder von Fehlern und schlagen ggf. das Sollverhalten im Handbuch nach.

Seite 16 von 127

Kenngrößen der Benutzbarkeit: Die Usability eines User Interface kann nach den folgenden Kriterien bewertet werden. • Offensichtlichkeit des Verwendungszwecks

Übung: Usability Analyse Bewerten sie die Usability Ihres Handys/PDAs oder Taschenkalenders mit Schulnoten nach den Kenngrößen der Benutzbarkeit. Begründen Sie kurz ihre jeweilige Bewertung und ziehen sie ein Fazit. Zeit: 15 Minuten

• Eindeutigkeit des Verwendungszwecks • Intuitivität des Verwendens • Klar erkennbare physische/logische Eigenschaften der Bedienelemente • Leichte Erlernbarkeit • Langfristige Erlernbarkeit • Tempo der Aufgabenerfüllung • Erfüllen der Funktionserwartung • Erfüllen der Reaktions- und Konvergenzerwartung • Subjektive Benutzerzufriedenheit

User Interface Workbook

Seite 17 von 127

#02

Bei mechanischen Geräten ist das User Interface integraler Bestandteil des Werkzeugs. Bei Anwendungen der virtuellen Realität soll das UI die physische Welt nachbilden bzw. ersetzen.

MMI Arten und Typen

Die Bandbreite von UIs reicht also von wirklichen Dingen bis zu virtuellen Dingen, die wirkliche Dinge ersetzen. Im Folgenden wird die Betrachtung von UIs auf Software fokussiert.

Definitionen: Anzeige- und Bedienkonzept: Ein Satz von Regeln, wie ein User Interface Informationen an den Anwender ausgibt (z.B. Ausgabekanäle, Bildschirmaufteilung, Design der Bildschirmseite), und wie der Anwender Steuerbefehle in das UI eingibt (z.B. Eingabekanäle, Betätigen von Kontrollelementen, Verwenden von Eingabegeräten). Anwendungsprogramme sind abstrakte Werkzeuge, die Computer für Menschen nutzbar machen. Durch sie kann der Computer dem Anwender bei seinen Aufgaben helfen, z.B. Buchhaltung machen, Termine organisieren, Kundenkontakte verwalten, Grafiken und Texte erstellen. Was wir als Anwender von einem Anwendungsprogramm wahrnehmen können, ist ausschließlich ihre Anwendungsoberfläche.

Lernziele für #02: þ

Die Bandbreite der User Interfaces reicht von mechanischen Geräten wie Spaten oder Rechenschieber bis hin zur virtuellen Realität (Wirklichkeitssimulation mit Software, Hardware, und haptischakustisch-visueller Rückkopplung). User Interface Workbook

þ þ

Verschiedene UI Typen und ihre Eigenschaften unterscheiden können Aufbau und Funktion eines UI erklären können Gemeinsamkeiten und Unterschiede der Anzeige- und Bedienkonzepte verschiedener UI Typen erklären können

Seite 18 von 127

Schema einer Mensch-Maschine Schnittstelle

Anwender

Bestandteile eines UI in einem softwaregestützten Werkzeug: þ þ þ

þ

Modalität (IO-Kanal, z.B. Bildschirmseite, Spracherkennung, angeschlossene Eingabegeräte) Kontrollelemente (z.B. in SW nachgebildete Knöpfe und Hebel) Interaktionen (z.B. das Auslösen einer Funktion in Abhängigkeit der betätigten Kontrollemente und des Kontextes) Ablaufstruktur (z.B. Arbeitsschritte, Workflowstationen)

Bedienteil

Funktionsteil Bei einem mechanischen Werkzeug finden die Interaktionen im Bedienteil nach den Gesetzen der Mechanik statt. Bei einem softwaregestützten Werkzeug finden die Interaktionen in der Oberfläche nach den vom System aufgestellten Regeln statt. User Interface Workbook

Seite 19 von 127

Hardware und Software im Zusammenhang mit UIs Ein User Interface betrifft immer Hardware und Software. • Ein UI hat immer Bedienelemente und Verwendungsregeln. • Ein UI benötigt IO-Medien (Zugang zu Kontrollelementen) und IO-Algorithmen (Interaktionsregeln und Zugang zu den Funktionen des Werkzeugs). Löcher in einer Lochkarte und Piktogramme im PDA sind beides Kontrollelemente, lediglich in verschiedener Hardwareausführung.

Software umfasst Computerprogramme sowie die zur Verwendung mit Computerprogrammen bestimmten Daten und auch die technischen Beschreibungen hierzu. Ein Computerprogramm ist eine Folge von Befehlen, welche auf einem Computer zur Ausführung gebracht werden können, um damit eine bestimmte Funktionalität (z. B. Textverarbeitung) zur Verfügung zu stellen. Software wird in der Regel in Gegensatz zu Hardware gesetzt, welche den physischen Träger bezeichnet, auf der Software existiert und funktioniert, und allein mit Hilfe dessen sie ihre Funktion erfüllen kann. In diesem Sinne wurde der Begriff erstmalig 1958 von John W. Tukey benutzt. Umgangssprachlich wird „Software“ oft auch ausschließlich für „aktive“ Daten, also ausführbare Computerprogramme gebraucht, „passive“ Daten fallen dabei weg. Die korrekte deutsche Übersetzung für „Hardware und Software“ lautet „Datenverarbeitungsgeräte und Datenverarbeitungsprogramme“. [Wikipedia] HW: Das was man physisch wahrnimmt. SW: Das was man logisch wahrnimmt. Kontrollelemente („Hardware“), das sind die Dinge mit denen das Werkzeug bedient wird, und die Dinge, an denen das Ergebnis der Werkzeugnutzung beobachtet werden kann. Sie sind physisch wahrnehmbar (haben Form) und anfassbar (haben Materialeigenschaften). Interaktionsregeln („Software“), das sind die Regeln, nach denen das Werkzeug gemäß seinem Zweck (interaktiv) eingesetzt wird. Sie sind nur mittelbar durch Beobachtung der Werkzeugverwendung und des jeweiligen Ergebnisses wahrnehmbar.

User Interface Workbook

Seite 20 von 127

Verschiedene UI-Arten: Überblick

Virtual Reality: Ein bekanntes Einsatzgebiet der VR ist die Pilotenausbildung in Flugsimulatoren. VR wird auch in der Industrie verstärkt eingesetzt, vor allem zur Erstellung von virtuellen Prototypen (z.B. virtuelle Fahrzeuge) und für Ergonomietests. Augmented Reality: Rechnergestützte Erweiterung der Realitätswahrnehmung in Echtzeit durch zusätzliche Information. Diese Information kann alle Sinne ansprechen, häufig wird aber nur das Einblenden von visuellen Informationen eingesetzt. Während VR eine gänzlich computergenerierte Welt bezeichnet, reichert Augmented Reality die reale Welt mit zusätzlichen Informationen an, die im Kontext der Realität direkt in das Sichtfeld des Betrachters eingeblendet werden. Da die Szene gewohnte reale Eindrücke enthält, kann ein virtuelles Modell dadurch an Akzeptanz gewinnen. Wearable Computing: Ein Tragbarer Rechner ist ein Computersystem, das während der Anwendung am Körper des Benutzers befestigt ist. Es unterscheidet sich vom Verwenden anderer mobiler Computer dadurch, dass die hauptsächliche Tätigkeit des Benutzers nicht die Benutzung des Computers, sondern die durch den Computer unterstützte Tätigkeit ist. Wearable Computing ist verwandt mit dem Mobile Computing (in Fahrzeuge integrierte, z.B. eingebettete Computer), und dem Portable Computing (Computer, die bei Gebrauch in der Hand gehalten werden, z.B. Mobiltelefone oder Palmtops). WC trägt zur Umsetzung des Pervasive Computing (Vernetzung von Gebrauchsgegenständen durch Computer) und des Ubiquitous Computing (Rechnerallgegenwärtigkeit) unter Verwendung der Context Awareness (Anwendungen kennen den Kontext, in welchem sie eingesetzt werden), bei. PC-Anwendungen: Anwendungsprogramme auf dem PC.

Software soll die vielfältigen Funktionen des Computers für Menschen erschließen und leichter verwendbar machen. Durch ihre Oberfläche wird Software anfassbar und begreifbar. User Interface Workbook

PDAs: Ein Personal Digital Assistant ist ein kleiner tragbarer Computer mit eigener Stromversorgung, der hauptsächlich für die persönliche Kalender-, Adress- und Aufgabenverwaltung benutzt wird. Ein Gadget (englisch für technische Spielerei) ist ein technisches Werkzeug oder Gerät mit cleverer oder bisher so nicht kombinierter Funktionalität, und einem in der Regel außergewöhnlichen Design. Seite 21 von 127

Eingebettete Systeme

Der Begriff Eingebettetes System (engl. embedded system) bezeichnet Rechnersysteme, die weitestgehend verborgen den Dienst in einer Vielzahl von Anwendungsbereichen und Geräten versehen, wie z. B. in Waschmaschinen, Flugzeugen, Autos, Kühlschränken, Fernsehern, DVD-Playern, SetTopBoxen, Handys oder allgemein Geräten der Unterhaltungselektronik. Im Fall von komplexen Gesamtsystemen handelt es sich dabei meist um eine Vernetzung einer Vielzahl von ansonsten autonomen, eingebetteten Systemen (zum Beispiel im Fahrzeug oder Flugzeug). Eingebettete Systeme vereinigen durch ihre oftmals hardwarenahe Konstruktion die große Flexibilität von Software mit der Leistungsfähigkeit der Hardware. Die Software dient dabei sowohl zur Steuerung des Systems selbst, als auch ggf. zur Interaktion des Systems mit der Außenwelt über definierte Schnittstellen oder Protokolle (zum Beispiel LIN-Bus, CAN-Bus oder TCP/IP über Ethernet). Kommunikation ist der Austausch von Information; Information und Kommunikation (IuK) ist ein zusammenfassender Begriff für die in einem modernen Fahrzeug eingebauten Medien der Informationsverarbeitung und Kommunikation. Zur IuK Ausstattung eines Fahrzeugs gehören z.B. Navigationssystem, Telefon, Bordcomputer, Audio- und Video-Unterhaltung.

Beispiel für ein eingebettetes System: Fahrzeugcockpit mit IuK Modul (Zentrale Displayeinheit, zentrale Bedieneinheit sowie weitere Anzeige- und Bedienelemente)

User Interface Workbook

Seite 22 von 127

Personal Computer User Interfaces - Geschichtsüberblick

Entwicklung der Benutzeroberflächen von Lochkarte bis zum PC und PDA im Überblick:

Verschiedenartige PC-Formen und PC User Interfaces haben seit dem Aufkommen der Heim-Microcomputer (1977) und der Personalcomputer (1981) weite Verbreitung gefunden.

þ

1983: Epson HX-20

1890 Lochkartenmaschine 1940 Relais 1950 Lochkarten 1956 Erster Computer mit Tastatur 1959 Erster Computer mit Bildschirm 1960 Kommandozeile, Bildschirmmasken 1962 Erfindung der Computermaus 1973 Xerox Alto (Erste GUI Workstation) 1974 Erste kommerzielle GUIs 1977 Apple II, Commodore PET 1981 IBM PC 1983 Epson HX-20 (erstes Notebook) 1989 Virtual Reality 1990 Windows 3.0 1993 Windows 3.1 seit 2000 Weite Verbreitung von PDAs, Handys mit Zusatzfunktionen und Notebooks 2009 (?) Erste PDAs mit zusammenrollbarem Display

Bis in die späten 50er Jahre kamen Anwendungsoberflächen mit interaktiven Dialogen gar nicht vor. Prozedurale Anwendungen erledigten die Verarbeitung von gestapelten Eingabedaten ohne Anwenderinteraktion und lieferten die Ergebnisse meist in Form von Listen oder neuen Datenkartenstapeln.

1977: Apple II 1981: IBM PC

2006: MacBook Pro

Betriebssystem (operating system): Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechensystems bilden und insbesondere die Abwicklung von Programmen steuern und überwachen. (Definition nach DIN 44300)

2009(?): Readius

User Interface Workbook

Seite 23 von 127

Aufkommen interaktiver Systeme Tastatur und Bildschirm wurden 1959 zum ersten Mal an einen Computer angeschlossen.

The launch of the PDP-1 (Programmed Data Processor-1) computer in 1959 marked a radical shift in the philosophy of computer design: it was the first commercial computer that focused on interaction with the user rather than the efficient use of computer cycles. As the world's first commercial interactive computer, the PDP-1 was also used for process control, scientific research and graphics applications as well as to pioneer timesharing systems. For the user, the PDP-1 represented an unprecedented freedom of human-machine interaction, spurring the creation of hacker culture at the Massachusetts Institute of Technology (MIT), Bolt Beranek and Newman (BB&N) and elsewhere. Inspired programmers would soon create early debugging, text editing, music and game programs, including the first computer video game, Spacewar! [www.computerhistory.org] Mit der Zunahme von Dialogtransaktionen wurden Maskenbeschreibungsformalismen entwickelt und in die Programmiersprachen und Entwicklungswerkzeuge integriert, z.B. SDD (Structured Dialog Design) in IBMs RPG (Report Program Generator,1959), Input- und Display-Befehle in COBOL (Common Business Oriented Language, 1959), BASIC (Beginners All Purpose Symbolic Instruction Code, 1964) oder IO-Makros in Assembler auf BS2000-Systemen.

DEC PDP-1: Erster kommerzieller interaktiver Computer (1959/60). User Interface Workbook

Seite 24 von 127

Computergenerationen Die 1. Generation (1946-1958): Elektronenröhren Die 2. Generation (1959-1964): Transistoren Die 3. Generation (1965-1970): Integrierte Schaltkreise Die 4. Generation (ab 1971): Mikroprozessor, PC John von Neumann hatte bereits 1945 die Idee der temporären Speicherung von Daten und Programmen (in demselben Speicher) beschrieben, die grundlegend für die Computerarchitektur der nächsten Jahrzehnte bis heute wurde. Jack Kilby entwickelte schon 1959 das Prinzip des integrierten Schaltkreises, der es später ermöglichte, unzählige Schaltelemente auf engstem Raum unterzubringen.

Die erste Computergeneration basierte auf Elektronenröhren als Schaltelemente - sie erreichten eine Leistung von maximal einigen tausend Additionen pro Sekunde. Die ENIAC gilt als Urvater dieser Generation. Die ENIAC wurde übrigens noch durch Neuverdrahtung programmiert - durch zwei talentierte Mathematikerinnen: Grace Hopper und Adele Goldstein. Mit der Erfindung des Transistors 1959 begann die 2. Generation, in der die Computer bedeutend an Größe abnahmen. Auch die Leistung stieg erheblich an, nun konnten schon mehrere zehntausend Additionen pro Sekunde durchgeführt werden. In der Programmierung ging man von der zuvor verwendeten Maschinensprache über Assembler zu höheren problemorientierten Programmiersprachen über - wie etwa FORTRAN und COBOL. In dieser Zeit liegen die Anfänge der Betriebssysteme - auch die ersten Ideen zu Mehrbenutzer Systemen entstanden, denn noch immer waren die Computer groß und teuer, so dass es günstig war, wenn sich mehrere Nutzer einen Rechner teilten. Die 3. Generation ist gekennzeichnet durch die Verringerung der Abmessungen der Rechner, da ihre Konstruktion und Funktionsweise zunehmend auf der Anwendung von integrierten Schaltkreisen basiert. Das Ende des Zeitraums ist nicht genau abgegrenzt, das Jahr 1971 bezieht sich auf die ersten Mikroprozessoren, und 1974 bezeichnet den Beginn der LSITechnik (Large Scale Integration), bei der bis zu 20000 Bauteile auf 25mm2 untergebracht wurden. In dieser Zeit wurden neue problemorientierte Sprachen wie BASIC entwickelt; auch echtes Multitasking und Time-Sharing wurden nun möglich und wurden Standard im Computerbetrieb. Die nun folgende 4. Generation dauert bis heute an. Neben der Entwicklung des Mikroprozessors war insbesondere die Idee des Personal Computers für diese Epoche entscheidend. [http://www.computer-history.de]

User Interface Workbook

Seite 25 von 127

Software UIs auf PCs

Dialogmittel/Dialogmodalitäten

Programmierte UIs (Anwendungsprogramme für PCs) sind weit verbreitet. Man kann UIs von PC Anwendungen zum Beispiel nach Dialogmitteln, Dialogform und nach Bedienungsparadigma ordnen.

Dialogmittel bezeichnet die Kontrollelemente (Input- und Output-Kanäle), die die Oberfläche (überwiegend) dem Anwender zur Dialogführung bereitstellt. Üblich sind: þ þ

þ

Beispiele für Dialogmittel: • Kommandozeilen UIs (CLI)

þ

• Zeichenorientierte Oberflächen (Textmasken)

þ

• Graphische Kontrollelemente (GUI)

þ þ

• Sprachverarbeitetende UIs Dialogformen: • Angeleiteter Dialog • Formularausfülldialog • Systeminitiierter Dialog • Offener Dialog Bedienungsparadigma: • Bearbeitungsgegenstandorientiert • Ablauf- bzw. vorgangsorientiert

User Interface Workbook

Mit grafischen Benutzeroberflächen lassen sich komplexe Oberflächen gestalten, die üblicherweise mit der Maus, optional aber auch mit anderen Eingabegeräten bedient werden können. KDE oder Aqua sind Beispiele für GUIs. Bei GUIs werden die Interaktionselemente oft als Icons dargestellt. GUI Icons sind symbolisch-bildliche Metaphern. Über sprachbasierte Benutzerschnittstellen kommuniziert der Benutzer per gesprochenes Wort mit einem System. Ausgaben bestehen entweder aus vorab aufgezeichnetem Ton, oder aus über eine synthetische Stimme ausgegebenem Text. Eingaben erfordern eine Spracherkennung oder eine Kombination mit anderen Eingabeparadigmen, wie Texteingabe, Mausklick oder DTMF Signale an Telefonen. Ein Beispiel für VUIs sind interaktive Telefon-Ansagedienste und -wählsysteme.

Befehlszeilen, die die gewünschten Funktionen und ihre Parameter festlegen: Command Line Interface (CLI) Textmasken, die unterstützende Beschreibungen um die Stellen zeigen, an denen die Anwendung Eingaben erwartet: Text User Interface (TUI) Grafische Kontrollelemente, die in Anwendungsfenstern frei kombiniert und angeordnet werden können: Graphical User Interface (GUI) Sprachsteuerung mit Hilfe von Sprachkommandos, auch mit Ausgabe von Sprachmenüs: Voice User Interface (VUI) Steuerung durch Körperbewegung: Haptische User Interfaces (HUI) 3D Oberflächen: Virtuelle Räume (z.B. bei 3D-Spielen) Berührungsorientierte Benutzerschnittstellen

Dialogformen þ þ

þ

þ

Directed Dialog (angeleiteter Dialog): Computerinitiierte Dialoge, z.B. grafische oder gesprochene Auswahlmenüs. Form Filling Dialog: Angeleiteter Dialog, bei dem die vom Computer angebotenen Formulare (z.B. eine Hotelbuchung) ausgefüllt werden sollen. Der Workflow der Anwendung besteht aus mehreren aneinander gereihten Formularen. Systeminitiierter Dialog: Ebenfalls ein angeleiteter Dialog. Der Computer informiert den Anwender über ein Ereignis und bietet in der Regel Reaktionsmöglichkeiten an, z.B. in Form eines Auswahlmenüs. Offener Dialog (unangeleitet): Der Mensch erklärt, was er möchte; der Computer grenzt die Antwortmöglichkeiten ein.

Die meisten Anwendungen, z.B. Geschäftsanwendungen, haben Form Filling Dialoge. In der Regel enthalten sie auch systeminitiierte Dialoge. Der offene Dialog zwischen Software und Anwender ist bis auf einzelne gesprochene Steuerbefehle in spezialisierten Anwendungen (z.B. Maschinensteuerung, Radionavigationssysteme) noch nicht weit verbreitet. Seite 26 von 127

Kommandozeilen-Interpreter

Ein Kommandozeilen-Interpreter (engl. command line interface CLI), oft auch Command-Shell genannt, ist ein Programm, welches eine eingegebene Textzeile als Kommando interpretiert und ein dazu passendes (Betriebssystem-)Programm ausführt. Technisch gesehen ist die Kommandozeile eine durch ein Programm angebotene Eingabezeile, die mit einfachen Editorfähigkeiten ausgestattet ist. Die Eingabe wird beendet mit dem Betätigen der Eingabetaste bzw. Datenfreigabetaste. Diese bewirkt das Senden des Zeilenbefehls an das Programm, das die Eingabezeile geöffnet hat. Als Reaktion wird der vom Benutzer eingegebene Kommandozeilentext interpretiert; der Kommandozeileninterpreter führt bei fehlerfreier Erkennung der Eingabe die entsprechenden Kommandos aus, die ihre eventuellen Ausgaben direkt anschließend auf den Bildschirm bringen. Danach erscheint erneut der Prompt, welcher signalisiert, dass die Eingabe einer weiteren Kommandozeile möglich ist. Die Funktionsweise beim interaktiven Arbeiten am Bildschirm entspricht damit der auf früheren Großrechnern, als Kommandos per Lochkarte ein- und etwaige Ergebnisse auf einem Drucker zeilenweise ausgegeben wurden. Auch in grafischen Benutzeroberflächen (Windows, MacOS) ist die Funktion einer Shell vorhanden, die die Eingaben des Benutzers interpretiert und umsetzt. Für erfahrene Benutzer haben Kommandozeilen-interpreter auch heute noch den Vorteil der schnellen, direkten Kontrolle und Erreichbarkeit aller Funktionen, vorausgesetzt, man kennt den Befehl und dessen Parameter exakt. Zudem lassen sich häufig wiederkehrende Kommandofolgen durch so genannte Makros, oder Skripte (auch Batchdateien genannt) automatisieren, was bei einer grafischen Oberfläche prinzipbedingt umständlich zu realisieren ist.

Kommandozeileninterpreter führen Befehle des Anwenders an das Betriebssystem, z.B. Starten von Programmen, aus. User Interface Workbook

Seite 27 von 127

Textmasken-Anwendungsoberflächen

Zeichenorientierte Oberflächen erweitern das Bedienungsparadigma der Befehlseingabezeile. Sie präsentieren sich meist in Form von Menüs, die mit der Tastatur und manchmal auch mit der Maus bedient werden. Ein Beispiel für ein Text User Interface ist der Dateiverwalter XTree. Textoberflächen werden auch als Masken bezeichnet, weil sie die direkte Verwendung von Befehlszeilen durch Eingabeschablonen maskieren. Benutzerschnittstellen können zwar, aber müssen nicht unbedingt, Elemente aus den niedrigeren Stufen enthalten; So hat der Midnight Commander beispielsweise eine Shell integriert, gehört aber dennoch zu den Text User Interfaces.

Screenshots: http://en.wikipedia.org/wiki/Text_user_interface

Text User Interfaces haben Menüs und Eingabemasken an Stelle von Befehlszeilen.

User Interface Workbook

Seite 28 von 127

Grafisches User Interface (GUI)

The first graphical user interface was designed by Xerox Corporation's Palo Alto Research Center in the 1970s, but it was not until the 1980s and the emergence of the Apple Macintosh that graphical user interfaces became popular. One reason for their slow acceptance was the fact that they require considerable CPU power and a high-quality monitor, which until recently were expensive. The Alto was the first system to pull together all of the elements of the modern Graphical User Interface. The Alto was designed and built by Xerox for research and, although Xerox donated a number of them to various organizations, they were never sold. The Xerox Alto was designed to be a relatively small, yet powerful, personal office computer with the ability to present information graphically, and to easily share information. They were also designed to utilize laser printers that were also under development at Xerox. The first Alto was completed in 1973. The hardware of the Alto machines consisted of: þ þ þ þ þ þ þ

A 606*808 tall monochrome bit-mapped video display. A 3-button mouse. Optional 5-key chord key set. Large 2.5 megabyte removable disks. 16-bit microcode programmable CPU custom-built from TTL chips. A total address space of 64 K 16-bit words (128k bytes), including the graphics bitmap. Using memory bank selection, a total of 256 K words (512K bytes) was possible.

Initially the Xerox Alto software was not "desktop" oriented and was more comparable to a system with various pieces of mouse enabled graphical DOS software than Macintosh or Windows. [http://toastytech.com/guis/alto.html]

Xerox Alto: Erster Computer mit einem GUI (1973)

User Interface Workbook

Seite 29 von 127

Verschiedene Grafische Oberflächen-Systeme Desktops aus einigen GUI-Systemen. 1983: Apple Lisa

1984: GEM

A program interface that takes advantage of the computer's graphics capabilities to make the program easier to use. Welldesigned graphical user interfaces can free the user from learning complex command languages. On the other hand, many users find that they work more effectively with a command-driven interface, especially if they already know the command language. Graphical user interfaces feature the following basic components: pointer: A symbol that appears on the display screen and that you move to select objects and commands. Usually, the pointer appears as a small angled arrow. Text -processing applications, however, use an I-beam pointer that is shaped like a capital I. pointing device: A device, such as a mouse or trackball, that enables you to select objects on the display screen. icons: Small pictures that represent commands, files, or windows. By moving the pointer to the icon and pressing a mouse button, you can execute a command or convert the icon into a window. You can also move the icons around the display screen as if they were real objects on your desk. desktop: The area on the display screen where icons are grouped is often referred to as the desktop because the icons are intended to represent real objects on a real desktop. windows: You can divide the screen into different areas. In each window, you can run a different program or display a different file. You can move windows around the display screen, and change their shape and size at will. menus: Most graphical user interfaces let you execute commands by selecting a choice from a menu.

1993: Windows 3.1

2007: Windows Vista

Aktuell verbreitete GUI Systeme: Windows XP, Windows Vista, Mac OS Leopard, KDE (Linux)

In addition to their visual components, graphical user interfaces also make it easier to move data from one application to another. A GUI includes standard formats for representing text and graphics. This makes it possible, for example, to copy a graph created by a spreadsheet program into a document created by a word processor.

[http://www.webopedia.com/TERM/G/Graphical_User_Interface _GUI.html] Screenshots: http://toastytech.com/guis/guitimeline.html

User Interface Workbook

Seite 30 von 127

GUI Anwendungen - Kontrollelemente

Ein GUI ist dazu da, Anwendungssoftware (Prozesse bzw. Tasks) auf einem Computer mittels grafischer methaperhafte Elemente (Arbeitsplatz, Symbole, Papierkorb, Menü) zu bedienen. Dies geschieht meistens mit einer Maus als Steuergerät, mit der die graphischen Elemente bedient oder ausgewählt werden. [Wikipedia] Diese Bedienelemente sind zum Beispiel: þ þ

þ

þ þ þ

þ þ

Button (Knopf zum Drücken) Checkbox (Auswahlkästchen die manchmal auch zu Gruppen zusammengefasst werden, mehrere Möglichkeiten können dabei ausgewählt werden) Radiobutton (Auswahlkästchen die IMMER zu Gruppen zusammengefasst werden, nur 1 Möglichkeit kann dabei ausgewählt werden) List (Liste zur Auswahl von Zahlen und/oder Wörtern) Textfield (Textfeld immer einzeilig zur Ein- oder Ausgabe von Zahlen und/oder Wörtern) Combobox (eine Kombination aus Button, List und Textfield bzw. Label zur Auswahl von Objekten, meist Zahlen und/oder Wörtern) Textarea (Textbereich immer mehrzeilig zur Eingabe, meist jedoch zur Ausgabe von Zahlen und/oder Wörtern) Scrollbar/Slider (Schieberegler)

Die wesentliche Neuerung der grafischen Oberflächen zu bisherigen Dialogbildschirmen ist die ereignisorientierte Arbeitsweise. Durch GUIs wurden Anwendungen zunehmend reaktiv.

User Interface Workbook

Seite 31 von 127

Kontrollelemente und Widgets • Als Kontrollelemente / Widgets (Fensterkontrollelemente) bezeichnet man Interaktionselemente bzw. Steuerelemente in grafischen Benutzeroberflächen. • Ein Widget entspricht der Zusammenfassung von Layout- und Verhaltensinformationen in einem Objekt. Widgets sind eine Weiterentwicklung von Kontrollelementen. • Logische Kontrollelement sind Konstrukte, die eine bestimmte Form der Interaktion ermöglichen (z.B. Auswahlliste, Schaltfläche). Es gibt eine endliche Menge von logischen Kontrollelementen. • Physische Bedienelemente sind Repräsentanten von logischen Kontrollelementen mit einem bestimmten Rendering. Bei physischen Kontrollelementen gibt es keine mengenmäßige Begrenzung.

User Interface Workbook

Zu den am häufigsten genutzten Steuerelementen gehören Schaltflächen und Bildlaufleisten. Das Wort Widget setzt sich zusammen aus window - Fenster und gadget - Ding, Gerät. [Wikipedia] Widgets sind physische Kontrollelemente. Sie können auf logische Kontrollelemente zurückgeführt werden. Beispiele: þ

þ

Menüs sind unabhängig davon, ob eine Benutzungsschnittstelle grafisch, textuell, auditiv oder anders gestaltet ist. Das logische Kontrollelement Auswahlliste kann durch eine Dropdown Liste, ein Popup-Menü, eine Listbox, eine Gruppe von Radiobuttons, ein Selection Wheel, usw. realisiert werden.

Das Aussehen eines Widgets wie eines Kontrollelements hängt oft von seinem Zustand ab. Der Zustand wird zur Laufzeit durch Auswertung von Funktionsergebnissen und Statusinformationen abgefragt. Zum Beispiel wird eine Schaltfläche oft grau dargestellt, wenn die durch die Schaltfläche aktivierbare Funktionalität zu diesem Zeitpunkt nicht zur Verfügung steht.

Seite 32 von 127

GUI Anwendungen - Bedienungsparadigma Man kann in einer Anwendungsoberfläche zwischen einer horizontalen (ablauf- bzw. vorgangsorientierten) und einer vertikalen (bearbeitungsgegenstandorientierten) Bedienungsform unterscheiden.

Ablauforientierte GUIs Horizontale User Interfaces treten vor allem in wirtschaftlich orientierten Anwendungen auf, wo der Fokus auf Workflows und auf intensiver Ein- und Ausgabe von Daten liegt. Diese Anwendungen haben eine horizontale UI-Ausdehnung, die durch die Aneinanderreihung von vielen elektronischen Formularen gekennzeichnet ist. Bearbeitungsgegenstandorientierte GUIs Vertikale User Interfaces sind solche, in denen Objekte direkt manipuliert werden. Über diese Manipulation löst der Anwender komplexe Funktionen wie z.B. Grafik- und Textverarbeitung oder 3D-Modellierung (CAD) aus. Diese Anwendungen haben eine vertikale UI-Ausdehnung, die dadurch gekennzeichnet ist, dass die bearbeiteten Objekte selbst als (relativ wenige) Kontrollelemente für vielfältige Umformungen dienen. Vertikale User Interfaces haben im Vergleich zu horizontalen User Interfaces weniger Dialogseiten und Kontrollelemente. Die zu manipulierenden Objekte selbst nehmen die Rolle von Kontrollelementen ein. Diese Kontrollelemente sind aber komplexer, weil sie mit der grafischen Repräsentation der Anwendungsdaten, z.B. einem CAD-Modell oder dem bearbeiteten Text, verzahnt sind.

Ablauforientiertes GUI: Formulare und Workflows Bearbeitungsgegenstandorientiertes GUI: Direkte Manipulation von Objekten

User Interface Workbook

Seite 33 von 127

Web Oberflächen

HTML, Browser oder Weboberflächen sind zunächst als statische Anzeigen entstanden. Später wurden sie zu Thin Clients weiterentwickelt. Heute sind Weboberflächen genauso leistungsfähig wie andere GUIs (Rich Web Clients). Bei herkömmlichen GUIs wurden immer vielseitigere Kontrollelemente entwickelt und ihre Interaktionen immer dichter an den Datenhaushalt der Anwendungen gekoppelt. Dabei umgingen die Entwickler gerne die hinderliche Transaktionsschicht. Die so entstandenen Anwendungen, deren Hauptmerkmal eine hochinteraktive Benutzeroberfläche mit sehr feinkörnigen Interaktionen ist, werden als Fat Clients bezeichnet. Der Unterschied zwischen einer auf HTML und Web Browser basierten und einer vom Fat Client gewohnten Anwendungsoberfläche ist, dass nach dem HTTP-Konzept die Grenze zwischen Transaktion und Präsentation hart, weil physisch, ist. Die im Fat Client üblichen Intensivkopplungen zwischen einzelnen Controls und den feinkörnigen Transaktionen sind bei einem Thin Client teuer, weil für jeden Kopplungszyklus eine Servertransaktion mit Datenübertragung notwendig ist. Die jeweiligen Vorteile und Wechselwirkungen der funktionsorientierten Transaktionen und der anwenderorientierten Interaktionen sind durch Web-Oberflächen in ein produktives Spannungsfeld getreten.

Heutige Weboberflächen sind weiterentwickelte GUIs.

User Interface Workbook

Seite 34 von 127

Vermittlungsfunktion eines User Interface Anwender Agieren

= Mensch = Softwareumwelt

Interpretieren

Die Oberfläche ist der dem Anwender (Mensch) zugewandte Teil der Software (Maschine) und zuständig für den Austausch von Informationen zwischen den Anwendungsfunktionen (funktionale Maschine) und der Anwendungsumwelt (im betrachteten Fall der Anwender). þ þ

Interpretieren

Agieren

Oberfläche Eingabe

= Vermittler

Verarbeiten

Die für den Anwender (Mensch) bestimmten Informationen müssen für diesen wahrnehmbar und interpretierbar sein. Die für die funktionale Anwendung (Maschine) bestimmten Informationen müssen für diese verarbeitbar und eindeutig sein.

Es handelt sich bei einer Anwendungsoberfläche also um eine Art Übersetzer und Vermittler, dessen Aufgabe es ist, die Eingaben des Menschen an den Rezeptoren / Steuerungseinrichtungen / Kontrollelementen der Software an die Anwendung weiterzureichen. In der umgekehrten Richtung wandelt die Oberfläche die Daten der Anwendung in mensch-wahrnehmbare Informationen d.h. in Ausgaben (i.d.R. in Form von visuellen und akustischen Äußerungen) um.

Ausgabe

Die Softwareoberfläche ist also ein Vermittler zwischen den Dialogpartnern Anwender und Softwarefunktionalität.

Anwendung = Maschine = Funktionen + Informationen

Software

Die Softwareoberfläche ist ein Vermittler zwischen den Dialogpartnern Anwender und Softwarefunktionalität. User Interface Workbook

Seite 35 von 127

Eingabe- und Ausgabemechanismen im UI

Eine Softwareoberfläche ist kein Monolith und auch keine Verpackung um die Softwarefunktionen, sondern eine Maschine mit verschiedenen Teilen, die gemeinsam eine komplexe Vermittlungsaufgabe erfüllen.

Interaktives System Ein User Interface kann aufgeteilt werden in die Module

Ausgabemechanismen [Manifestoren]

þ þ þ

Verarbeitungsalgorithmen [Prozessoren] Ab

n hä

gi g

ke

it

Eingabeempfänger, die Aktionen des Anwenders entgegennehmen Interpretationsalgorithmen, die die Eingaben interpretieren und Verarbeitungsalgorithmen auslösen Ausgabemechanismen, die die Ergebnisse von Verarbeitungsalgorithmen zum Anwender hin manifestieren

Interpretationsalgorithmen [Interpreter] Eingabeempfänger [Rezeptoren] In f

o rm

a

n ti o

s fl

us

s

Eine Softwareoberfläche umfasst diejenigen Teile der Software, die in Form von Ausgaben, Eingabeelementen oder Dialogführung zwischen dem Anwender und der Funktionalität der Anwendung vermitteln.

User Interface Workbook

Seite 36 von 127

HCI Erweiterung des EVA Prinzips für UIs

Wesentlich für das Verstehen des Mensch-Maschine-Dialogs ist es, zwischen dem kommunikationsorientierten Schema AktionReaktion und dem funktionsbezogenen Schema EingabeAusgabe zu unterscheiden. þ

Kommunikationspartnerperspektive Aktion

Reaktion

EVA-Perspektive Input

Processing

Output

þ

Auf der Ebene von Eingabe-Ausgabe hat das Interpretieren von Benutzeraktionen bereits vorher stattgefunden. In der Anwendung wird daraufhin eine definierte Funktion ausgelöst, die ein definiertes Ergebnis liefert. Auf der Ebene von Aktion-Reaktion findet hingegen ein gegenseitiges Interpretieren statt. Der Anwender trifft Annahmen über die von der Oberfläche bereitgestellten Informationen, Bedienungselemente und dahinter stehende Funktionen. Die Oberfläche trifft Annahmen über das Wahrnehmen und Agieren des Anwenders und über die verfügbaren Funktionen und Daten der funktionalen Anwendung.

HCI-Perspektive InMitteilung Mensch

Input

Processing Systemgrenzen

Output

OutMitteilung Mensch

Die HCI Perspektive erweitert das Input-Processing-Output Prinzip um die InMitteilung (Aufbereiten der Anwenderaktion zum Input) und OutMitteilung (Aufbereiten des Output der Software zu einer für den Anwender wahrnehmbaren Reaktion).

User Interface Workbook

Seite 37 von 127

Außensicht und Innensicht auf ein User Interface Anwender betrachten ein User Interface von außen.

Das Verstehen einer Maschine erfolgt anhand dessen, wie die Maschine vom Anwender beim Benutzen erlebt wird. Das gilt sowohl für reale Maschinen wie einen Korkenzieher oder einen Toaster, als auch und insbesondere für Softwareanwendungen und ihre Benutzeroberflächen, wie zum Beispiel ein Textverarbeitungsprogramm, eine Suchmaschine im Internet oder das Navigationssystem in einem Fahrzeug.

Anwender Aussensicht

Usability

Ergonomie Benutzermodelle

Design

User Interface

Allerdings hat ein User Interface bei Softwareprogrammen seinen eigenen inneren Aufbau, der für die Entwickler einer Software genauso eine Rolle spielt (oder spielen sollte), wie Daten und Funktionen. þ

Mechanismen

Beziehungen Abhängigkeiten

Informationsstrukturen Innensicht

Entwickler

Entwickler haben neben der Außensicht auch eine Innensicht auf das User Interface.

User Interface Workbook

Für die Anwender eines Computerprogramms - oder eines anderen vielseitigen Werkzeugs – ist dessen innerer Aufbau meist nur am Rande wichtig. Sie interessieren sich hauptsächlich dafür, ob das Ding gut in der Hand liegt und seinen Zweck gut erfüllt. Bei Software interessiert den Anwender die Oberfläche, bei Fahrzeugen das Fahrerlebnis, bei Maschinen das Bedienpult.

þ

þ

þ

Die UI-Außensicht umfasst UI Use Cases, die sich auf Design, Usability, Ergonomie und Erleben des Anwenders aus dessen Sicht richten. Die UI-Innensicht umfasst Use Cases, die sich auf Informationsstrukturen, Beziehungen, Abhängigkeiten, Verflechtungen und Erleben des Anwenders aus Sicht des Entwicklers richten. Die beiden UI-Sichten haben unterschiedliche Ausdrucksformen. Die UI-Außensicht wird mit kognitiven Modellen, durch Grafikdesign und Usability-Analysen behandelt. In der UI-orientierten Architektur geht es vorrangig um das Zusammenspiel der verschiedenen Perspektiven in der UI Innensicht.

Seite 38 von 127

Fragen zu #02

1. Ist das, was man auf dem Bildschirm (in einem GUI) sieht und macht von der Idee her Hardware oder Software? Was ist eine Bildschirmseite in einem GUI? Software oder in Software nachgebildete Hardware? þ þ

Antworten zu #02: 1: b) 2: b) 3: Modalitäten, Kontrollelemente, Interaktionen, Ablaufstruktur 4.: Virtual Reality, Eingebettete Systeme, PCAnwendungen 5: CLI: befehlsorientiert, Eingabe von Befehlen mit Parametern in Kommandozeilen, Ausgabe von Ergebnissen als Text; Text-Masken: Menüführung, Formulare mit Feldern, Bedienung mit Funktionstasten und Befehlscodes; GUI: ereignisorientiert, grafische Kontrollelemente, Mausbedienung 6: a), c) und d) 7: a)

a) Eine GUI Seite ist Software, weil sie programmiert ist und nur auf dem Bildschirm existiert. b) Eine GUI Seite ist eine Hardware-Nachbildung. Die hardwarenahen Eigenschaften (wahrnehmbar, manipulierbar) stehen im Vordergrund. Sie ist HardwareErsatz und das Ergebnis der SW-Aktivität, weil sie mit Hilfe von Software auf den Bildschirm kommt.

2. Welche Rolle spielt die Mechanik bei Software User Interfaces? þ þ þ

a) User Interfaces sind immer mechanisch. b) User Interfaces bildet mechanische Vorgänge nach. c) Mechanik spielt bei User Interfaces keine Rolle.

3. Zählen Sie die Bestandteile des UI einer Software 4. Nennen Sie drei verschiedene UI Arten 5. Nennen Sie drei verschiedene Typen von PC-UIs 6. Welche Gesichtspunkte beinhaltet die Innensicht auf ein UI þ þ þ þ þ

a) Informationsstrukturen b) Design c) Mechanismen d) Beziehungen e) Usability

7. Was ist das hauptsächliche Klassifikationskriterium für User Interface Arten? þ þ þ

User Interface Workbook

a). Input- und Output-Kanäle b). Verwendete Hardware c). Art der Programmierung

Seite 39 von 127

#03

Rahmenbedingungen: Um diese User Interfaces geht es þ

UI Spezifikationsbedarf und Spezifikationsformen

þ þ þ þ

Gründe für das Spezifizieren von User Interfaces: • Abnahmekriterium im Vertrag • Interne Schnittstellen / Teamarbeit • Mitarbeiterfluktuation • Nachvollziehbarkeit / Dokumentation • Erlebbarkeit vor Umsetzung (falls Prototypen oder Simulationen erstellt werden)

User Interface Workbook

Ziel des Projekts ist das Ausliefern einer Softwareanwendung Vertrag über Erstellung eines Werks Vertragsgegenstand ist nicht nur die Funktion sondern auch die Art und Weise der Bedienung. Auftragnehmer und/oder Auftraggeber hat eine Organisation mit arbeitsteiligen Prozessen. Industrielle Produkte, kommerzielle Anwendungen (z.B. Produktvarianten für verschiedene Märkte)

Lernziele þ þ þ þ

Kenntnis, wieso UI Spezifikationen notwendig sind Kenntnis verschiedener Spezifikationsformen Vor- und Nachteile der verschiedenen Beschreibungsformen kennen. Auswahlkriterien der Beschreibungsform kennen und anwenden können.

Seite 40 von 127

Die Bedeutung von User Interfaces nimmt zu

þ

marginal: UI-Interaktion Früher:

dominierend: Stapelverarbeitung von Transaktionen Funktionen und Prozeduren

Motivation für UI Spezifikationen: Die wachsende Bedeutung von UIs an Anwendungssoftware berücksichtigen

Heute: User Interface: 70% Funktionale Logik: 30%

dominierend: Interaktive User InterfaceOperationen Funktionen sind Services für das UI

User Interface entwickeln

User Interfacebezogene Eingabe-AusgabeOperationen Anwendungsebene

Funktionale Operationen

Keine standardisierten Methoden

View- und ControllerCode Codeebene

Geschäftslogik Systemlogik Code

þ

þ

þ

Oberflächen sind von den ursprünglich kargen Kommandokonsolen zu multimedialen Assistenten für die eigentliche Funktionalität einer Software gewachsen. In dialogintensiven Anwendungen machen Präsentation und Interaktion zwischen Anwender und Anwendungsoberfläche oft mehr als 2/3 der Software aus [Myers 1992]. Die eigentliche Transaktion kommt hingegen erst am Schluss der Verhandlung zwischen Anwender und User Interface zur Ausführung. Der Anteil der Geschäftslogik am Gesamtumfang einer dialogintensiven Anwendung ist kleiner, als bislang aus der Sicht von Objekt- und Ablaufmodellen angenommen wird. Der Fokus des Entwickelns von Softwareanwendungen verschiebt sich von der funktionalen Planung und Programmiertechnik zum Verstehen, Planen und Umsetzen der für das Verwenden der Software geforderten Eigenschaften.

User Interfaces stehen im Mittelpunkt des Interesses der Auftraggeber und der Anwender, doch von den Entwicklern werden sie nicht selten wie Schmuck am Nachthemd behandelt. Zugleich hängt der Erfolg einer Softwareanwendung maßgeblich von ihrer Verwendbarkeit ab.

Modellebene

UML

Funktionalität entwickeln

Die Größe und Bedeutung von UIs gegenüber dem Funktionsanteil von Anwendungen nimmt zu.

User Interface Workbook

Seite 41 von 127

Gründe für systematisches Entwickeln von Software Die Softwarekrise bezeichnet ein Mitte der 1960er-Jahre auftretendes Phänomen: Erstmalig überstiegen die Kosten für die Software die Kosten für die Hardware. In der Folge kam es zu den ersten großen gescheiterten Software-Projekten. Man erkannte, dass die bisher genutzten Techniken mit dem Umfang und der Komplexität der Software nicht Schritt gehalten hatten. Auf einer NATO-Tagung 1968 in Garmisch-Partenkirchen, Deutschland, wurde das Problem diskutiert und als Reaktion der Begriff des Software Engineering geprägt.

Die Softwarekrise war der Ursache für systematisches Entwickeln von Software. Die durch die Softwarekrise begonnene kontinuierliche Auseinandersetzung mit den Schwächen der Methoden und Werkzeuge der Softwareentwicklung hat zu einer Vielzahl nützlicher Hilfsmittel geführt, z.B. þ þ þ þ þ þ þ þ

SADT (Structured Analysis and Design Technique) IDEF (Integrated Computer Aided Manufacturing Definition Languages) ERM (Entity Relationship Model OOD (Object Oriented Design) UML (Unified Modelling Language) XML (Extensible Markup Language) QM/QS (Quality Management / Quality Assurance) RM/RE (Requirement Management / Requirement Engineering)

Die Verbreitung und die fortschreitende Standardisierung dieser Hilfsmittel und Methoden helfen, Kommunikationsbrüche in Prozessen der Softwareentwicklung zu vermeiden und zu schließen. Benutzeroberflächen sind bis heute nur nachrangig (XForms, XUL, UIML, Rapid Prototyping), in diese Methodenentwicklung eingeschlossen.

Die Softwarekrise hat die Entwicklung von ingenieurmäßigen Methoden und Vorgehensmodellen für den Softwarebau eingeleitet. Die Softwareindustrie begann, analog zur Bau- und Automobilindustrie, Software systematisch zu planen und zu entwickeln.

User Interface Workbook

Seite 42 von 127

Kritik am heutigen Methoden der UI Entwicklung Während im Häuser-, Maschinen- und Fahrzeugbau die Sicht des Nutzers meist im Mittelpunkt steht, konzentriert sich z.B. die UML beim Softwarebau auf Querschnittsmodelle über Funktionen, Datenhaushalt und innere Abläufe. Nicht selten wird die Oberfläche nur mit Hausmitteln wie Powerpoint, Excel, State Charts und Designprototypen umrissen und die Ausgestaltung der Details dem Entwickler überantwortet. Manchmal begegnet man noch extremeren Beispielen: Die Funktionalität wird ohne Oberfläche als Framework entwickelt und die Oberfläche in einem Einführungsprojekt beim Kunden drübergebaut.

Software UI orientiert entwickeln heißt, die Interaktion zwischen Anwender und Anwendung in den Mittelpunkt von Entwicklungstätigkeiten, Test und Architekturüberlegungen zu stellen. Lösungsansätze für UI orientierte Methoden: þ

þ

User Interface-Modelle und Dialogbaupläne im Zentrum der Aufmerksamkeit der Softwareauftraggeber und der Softwarehersteller. Klar festgelegte Formalismen, die in Bezug auf eine Anwendungsoberfläche so exakt und eindeutig wie technische Zeichnungen oder CAD-Modelle von Maschinen oder Gebäuden sind.

Die Bedienung der Software wird damit einhergehend nicht als Mittelpunkt des Projekts, sondern eher als Aufsatz auf die technische Umsetzung der Funktionalität wahrgenommen. In der Praxis hat der Frameworkansatz allerdings zur Folge, dass erst beim Entwickeln der Oberfläche die Lücken und Brüche in dem vermeintlich einsatzfähigen Framework zum Vorschein kommen.

User Interface Workbook

Seite 43 von 127

Problemstellungen der UI Entwicklungsmethoden State of the Art: Herkömmliches Software-Entwicklungsvorgehen

Inhalt: Zweck und Funktion

Anforderungsverwaltungswerkzeuge UML, Prozess- und OOModellierungswerkzeuge

Kommunikationslücke

Technik: Technische Umsetzung

Der Zielnutzen einer User Interface Spezifikation ist die Planungssicherheit auf Auftraggeber- und Herstellerseite eines Softwareprojekts. Das kann die User Interface Architektur mit folgenden Mitteln erreichen. þ þ þ

þ

Benutzung: Informationsbrüche

Gegenstand der User Interface Architektur ist der innere Aufbau des User Interface eines Computerprogramms.

???

Wie fasst sich die Anwendung an? Wie bewegt sich der Benutzer durch die Anwendung? Wie sind die Felder auf den Dialogseiten angeordnet? Was passiert bei Eingaben in einzelnen Feldern und bei Klicks auf Schaltflächen?

þ

Klarer und nachvollziehbarer User Interface-Entwurf. Erlebbarkeit der UI Spezifikation. Durchgängige Spezifikation der Anwendersicht auf das Computerprogramm von der Softwareoberfläche bis zu den Systemfunktionen. Abgestimmte Schnittstellen zwischen Bedienteil und Funktionsteil. Eindeutige Formulierung der Anforderungen an die Statik, Dynamik und Umwelt eines User Interface.

Die Sicherung der Projektziele wird erreicht, indem Risiken systematisch eliminiert werden.

Oberflächendesignwerkzeuge Objektorientierte Entwicklungswerkzeuge

Die User Interface Spezifikation definiert, wie die Anwendung aussieht, sich anfühlt und wie sie ihre Funktionen zur Verfügung stellt.

User Interface Workbook

Seite 44 von 127

UI Beschreibungsformen - Überblick Die Beschreibungsformen für Oberflächen können unterschiedlich abstrakt sein. Sie variieren von umgangssprachlich bis codierungsnah sowie von formlos bis algorithmisch.

Die Auswahl der Spezifikationsmethode kann zusammen mit der Wahl des UI-Entwicklungswerkzeugs oder unabhängig davon erfolgen. Je formaler die gewählte UI-Beschreibungsmethode ist, desto mehr tritt allerdings die Frage der Unterstützung durch Werkzeuge in den Vordergrund.

• Umgangssprachliche UI Beschreibung • Tabellarische UI Beschreibung • Strukturierte UI Beschreibung • Formale UI Modelle • State Charts (formale Logikmodelle) • UI Prototypen mit HTML • Programmierte UI Prototypen

User Interface Workbook

Seite 45 von 127

Spezifikationswerkzeuge - Überblick Gängige Werkzeuge zur UI Spezifikation: • Office-Werkzeuge (z.B. Powerpoint, Word und Excel) • Darstellungsorientierte Werkzeuge (z.B. Flash, Director) • GUI Toolkits (Betriebsystemnahe und Kontrollelementorientierte Designwerkzeuge und Bibliotheken) • Grafische Ablaufmodellierungswerkzeuge (oft auf Basis von State Charts) • Anforderungsmanagementsysteme (z.B. Doors, Rochade) • Werkzeuge für eingebettete Systeme (z.B. Tresos Guide) • Domänenspezifische Modellierungssprachen und Spezialeditoren

User Interface Workbook

Seite 46 von 127

Use Cases der Softwareoberfläche - Anwendersicht

Die Use Cases des User Interface dienen als Stoffsammlung und Gliederung für eine User Interface Spezifikation

interpretiert Kontext

Anwender

benutzt Oberfläche

beinhaltet

interpretiert Ausgaben betätigt Bedienelemente agiert gibt Werte ein wartet auf Ausgaben UI Reaktionen

UI Aktionen

Verwendungsfälle einer Oberfläche aus Sicht des Anwenders: • Die Oberfläche (Ausgaben der Anwendung im Kontext der Präsentation) interpretieren • Eingabe und Steuerungselemente betätigen • Rückmeldung über (laufende) Verarbeitung der Eingaben erhalten

User Interface Workbook

Seite 47 von 127

Use Cases der Softwareobefläche - Interaktionssicht

SoftwareOberfläche beinhaltet

dient dem Anwender

benutzt Funktionalität

Inhalte ausgeben

Benutzeraktionen interpretieren

Kontext ausgeben

þ þ þ þ þ

… Signale der Anwendung interpretieren Datenkontext der Anwendung abholen und auswerten Den Zustandsvektor der Oberfläche ermitteln (Bedingungen für Aktionen bzw. Situationen berechnen) Oberflächen-Transitionen (Übergänge in der Oberfläche) auslösen

Transitionen vollziehen

Funktionen auslösen

Anwendungssignale interpretieren

Situationen ermitteln

Daten auswerten

Verwendungsfälle aus Sicht der Oberflächeninteraktion: • Aus- und Eingabeelemente für den aktuellen Anwendungsschritt bereitstellen • Eingaben des Anwenders interpretieren • Ausführen von Anwendungsfunktionen auslösen • … User Interface Workbook

Seite 48 von 127

Use Cases der Softwareoberfläche – funktionale Sicht

Liste der Funktionsdienste Liste der Datendienste

Funktionen ausführen Requests umsetzen

funktionale Anwendung beinhaltet

dient der Oberfläche

Liste der Systemnachrichten

Daten bereitstellen

Signale an UI senden

Systemgtriggerte Funktionen ausführen

Die Verwendungsfälle aus Sicht der funktionalen Anwendung sind: • Requests der Oberfläche über Ausführung Funktionalitäten quittieren und umsetzen • Requests der Oberfläche über Bereitstellung des Datenkontexts quittieren und umsetzen • Signale an die Oberfläche senden, um der Oberfläche zu signalisieren, dass diese agieren soll

User Interface Workbook

Seite 49 von 127

Gliedern einer User Interface Spezifikation

Inhalte / Dialogelemente

nach Themen

nach UI Teilen

Inhalte

Dialogelemente

Struktur

Verhalten

Dialogschritte

þ þ þ þ þ þ

Was beinhaltet die Anwendung aus fachlicher Sicht? Standard-Dialogabfolgen (zuerst Normalfälle) Inhalte von Dialogmasken (zuerst Hauptelemente) Wie sind Abläufe und Inhalte organisiert? Varianz und Gemeinsamkeiten von Dialogabläufen Maskenaufbau, typische Anwender-Interaktionen

Struktur / Dialogschritte

Interaktionen

þ þ þ þ þ

Wie hängen die Aktivitäten und Inhalte zusammen? Gliederung der Ablaufschritte / Tätigkeiten Zuordnung von Dialogmasken zu Ablaufschritten Tätigkeitsauswahl Wiederholung und Unterbrechungen

Anzeige und Bedienung / Anforderungen / Use Cases

Anzeige & Bedienung

Umwelt

Anforderungen

Kontext

þ þ þ

Varianz

Restriktionen

Umfang der Anwendung, Funktionalität, Ablaufsequenzen

Wie wird eine konsistente Darstellung der Anwendungsinhalte erreicht? Wie wird der Anwender durch die Arbeitsschritte geführt? Verwenden von Navigationselementen, Widgets, Layouts

Verhalten / Interaktionen þ þ þ þ

Nach welchen Regeln erfolgt die Steuerung der Abläufe? Wie wird die Dynamik der Abläufe zwischen und innerhalb der Arbeitsschritte kontrolliert? Ereignisse, Auswerten von Situationen, Reaktionen Ermitteln und anzeigen des Dialogfortschritts

Umwelt / Kontext Wie werden verschiedene Sichten (rollen- und bearbeitungsstandbedingt) auf gleiche Inhalte abgebildet? Wie reagiert die Oberfläche auf sich ändernde Situationen? Verwenden von Anwendungsfunktionen und Daten, Ermitteln von Situationen und Parametern

Ablaufgliederung, Anwendungsaufbau, Ablaufzusammenhänge

þ

Bedienungssystematik, Darstellungs-, Bedien- und Navigationsregeln

þ þ

Präsentationslogik, Schnittstelle zur Geschäftslogik

Varianz / Restriktionen

Skalierung, Präsentations- und Funktionskontext

þ

Umgebung, Varianten, Mandanten, Konfigurationen

þ þ þ

User Interface Workbook

Wie werden versionsabhängige Varianten und Abweichungen der Abläufe und der Inhalte verwaltet? Länder- und Sprachabhängige Ressourcen Rollenspezifische Unterschiede im UI Mandantenspezifische Ressourcen in UI-Elementen Seite 50 von 127

Gliedern der UI Spezifikation nach UI Perspektiven

Anforderungen

Verschiedene Sichten auf das User Interface

Kontext

Struktur

Dialoge Interaktionen

• Anforderungsperspektive: Features, Use Cases, Abgrenzung • Strukturperspektive: Tätigkeiten, Ergebnisse, Sequenzen, Dienste • Dialogperspektive: Dialoginhalte, Kontrollelemente

Die Strukturperspektive definiert die inhaltliche Breite der Softwareoberfläche. Mit dieser Sicht beginnt üblicherweise die Arbeit an einer Spezifikation, indem eine inhaltliche Gliederung des User Interface aufgenommen wird. Die Anforderungsperspektive legt den Zielbezug der Softwareoberfläche fest. Sie stellt den Bezug zu Use Cases, zur Featureplanung, zu funktionalen und nichtfunktionalen Anforderungen und zur Abgrenzung des Anwendungsumfangs her. Mit dieser Sicht werden zuerst die Struktur und dann die weiteren Perspektiven qualifiziert (bewertet) und validiert (bestätigt). Die Dialogperspektive definiert die inhaltliche Tiefe der Softwareoberfläche. Es ist die Sicht auf eine abgegrenzte Dialogeinheit, z.B. eine Dialogseite oder ein Sprachmenü. Diese Sicht sollte man nach hinreichender Abgrenzung der Struktur ausformulieren. Die Kontextperspektive deklariert die von anderen Sichten verwendeten Kontextbausteine der Softwareoberfläche. Diese Sicht wird implizit und explizit jederzeit dann verwendet, wenn in einer anderen Sicht eine Bezugnahme definiert wird und hierzu ein entsprechendes Bezugsziel festgelegt werden soll. In dieser Perspektive werden Schnittstellen festgelegt. Die Interaktionsperspektive ist eine Vertiefung der Dialogund Strukturperspektive. Sie beschreibt, an welchen Strukturstellen und in welchen Dialogstellen auf das Auftreten welcher Ereignisse welche Reaktionen folgen. Diese Sicht sollte man nach Festigung der Struktur und nach Abgrenzung der Dialoginhalte ausformulieren.

• Kontextperspektive: Situationen, Ressourcen, Funktionen • Interaktionsperspektive: Ereignisse, Reaktionen

User Interface Workbook

Seite 51 von 127

Vorteile der Gliederung nach UI Perspektiven

Eine UI-Gliederung nach UI-Perspektiven kann zum Beispiel herangezogen werden zum þ

Oberflächenspezifikation Anforderungsperspektive [Geforderte Eigenschaften]

þ þ þ þ þ

Strukturperspektive [Ablaufstrukturen]

Darstellungsperspektive [IO-Elemente] Integrierte Sicht

Interaktionsperspektive [Ereignisse und Reaktionen]

þ þ

Vergleichen des Informationsgehalts von verschieden umgesetzten Oberflächen Bewerten der Vollständigkeit einer zur Prüfung vorgelegten Oberflächenbeschreibung Einordnen von oberflächenrelevanten Informationen in einen Gesamtzusammenhang Schrittweise Ergänzen der UI Beschreibung von der ersten Skizze bis zu einer umsetzungsreifen Detailspezifikation Vergleichen von UI-Beschreibungen, Strukturiertes Aufnehmen und Dokumentieren von User Interface Anforderungen, Aufstellen von funktionalen Anforderungen an Werkzeuge zur UI Spezifikation und UI Implementierung Bewerten von Verfahren zur UI Modellierung

Kontextsicht [Daten, Funktionen, Situationen]

Die Gliederung nach Perspektiven ermöglicht definierte Schnittstellen zwischen den Bestandteilen einer UI Spezifikation und damit eine integrierte Gesamtsicht auf das gesamte User Interface.

User Interface Workbook

Seite 52 von 127

Unterspezifikation ist in Ordnung • Eine totale Detaillierung der Spezifikation ist ein Grenzfall zur Implementierung und ökonomisch nicht sinnvoll.

Eine Sprachform ist in der Regel nicht mit nur einer exakten Bedeutung verbunden. Die dadurch entstehende Unbestimmtheit der Bedeutung (Unterspezifikation) kann als Basis für extreme Flexibilität und Leistungsfähigkeit einer natürlichen Sprache angesehen werden. Sie ist jedoch oft auch Gegenstand der Kritik, trägt aber entscheidend zu einer effektiven Kommunikation bei. Die Gründe für diese Unbestimmtheit der Bedeutung können sein: þ

• Wie tief spezifiziert werden muss, hängt vom Projektkontext und dem Interpretationsvertrauen in die Umsetzer ab. • Problem ist die mangelnde Standardisierung von Oberflächenbestandteilen, Werkzeugen und Ausbildung in Verfahren.

User Interface Workbook

þ þ

Kontextabhängigkeit (Abhängigkeit vom sprachlichen und außersprachlichen Kontext] Vagheit Mehrdeutigkeit

[http://lexikologie.perce.de/]

Die Formulierbarkeit von UI-Inhalten und Interaktionen erfordert Sprachkonstrukte, die einerseits exakt, andererseits skizzenhaft und änderungsrobust sind. Eine geeignete UI Spezifikationssprache ermöglicht eine knappe, eindeutige und gut lesbare UI-Beschreibung.

Seite 53 von 127

Umgangssprachliche UI-Beschreibung • Umgangssprache • Händische Maskenentwürfe

Benutzermodell: Beschreibung eines Anwenderstereotypen durch dessen Aufgaben, Arbeitsziele, Wissen, Fähigkeiten, Verhaltensweisen, Benutzungsgewohnheiten, etc. Ein Anwendungsfall (Use Case), beschreibt eine Verwendung eines Systems durch einen Anwender, um ein bestimmtes fachliches Ziel zu erreichen.

• Erlebnisbeschreibungen • Benutzermodelle • Use Cases Die natürliche Sprache ist die für Menschen verständlichste, aber auch missverständlichste Form der Beschreibung einer Anwendungsoberfläche. Oft haben umgangssprachliche Spezifikationen die Form von Erlebnisaufsätzen. Der Verfasser beschreibt dabei seine Erwartung an das Erleben der Anwendung beim Erledigen von Aufgaben.

User Interface Workbook

Seite 54 von 127

Tabellarische UI-Beschreibung • Umgangssprache, teilweise mit Formvorgabe

Eine Tabelle ist eine attributierte Stückliste, also ein Verzeichnis von Dingen, z.B. die Aufstellung der Kontrollelemente auf einer Dialogseite nebst deren Eigenschaften, z.B. Beschriftung, Typ, Aktion, etc.

• Tabellarische Beschreibung der Dialogseiten • Maskenentwürfe mit Präsentationsprogramm • Attributabfrage für z.B. Dialogelemente Die tabellenorientierte UI-Spezifikation, zum Beispiel mittels Excel und PowerPoint oder mit OpenOffice, wird in der Praxis oft angetroffen. Sie ist in der Regel weiterhin umgangssprachlich, definiert aber für einige Spezifikationsartefakte detailliert deren Attribute. Diese Spezifikationsform wird oft beim Entwurf von einzelnen Dialogseiten angetroffen.

User Interface Workbook

Seite 55 von 127

Strukturierte UI-Beschreibung • Detaillierte hierarchische Struktur • Festgelegte Semantik der Strukturen • Attributierung der Einzelteile • Datenhaltung innerhalb einer Repository-Struktur

Beispiele für RE-Repositories: Doors, Rochade Stücklistenprozessor: Programmsystem zur Speicherung und Pflege von Teilestammdaten und Erzeugnisstrukturdaten. Ein Repository ist der Oberbegriff für ein System zur Aufbewahrung von Daten. Alle Systeme, die Daten lagern, z.B. Datenbanken oder XML-Dateien, sind Repositories. In der Entwicklungstechnik bezeichnet Repository i.d.R. ein Ablagesystem, das gemeinsames Arbeiten auf einer vordefinierten Struktur sowie Synchronisierungs- und Versionierungsmechanismen zu Verfügung stellt.

Diese Spezifikationsform gibt die Dokumentationsform, eine detaillierte Gliederung und formal strukturierende Regelungen für die Spezifikationsinhalte vor. Die Gliederung der Spezifikation wird feinkörnig herunter gebrochen und i.d.R. als Strukturvorgabe in Form von Templates in einem Repository bereitgestellt.

User Interface Workbook

Seite 56 von 127

Formale UI-Modelle • Strengere Form der strukturierten Beschreibung • Formale/semiformale Spezifikationssprache • Legen Ausdrucksformen, Formalismen, und Interpretation für Eigenschaften des User Interface fest • Festlegungen zu syntaktischen Konstrukten und deren Semantik • Detaillierte Aufteilung der Oberfläche in Bestandteile • evtl. Abbildung der Sprache auf ein Informationsmodell

Eine formale Grammatik beschreibt eine formale Sprache, indem sie exakt festlegt, welche Wörter in welcher Reihenfolge einen Satz dieser Sprache bilden. Außerdem weist sie diesem Satz eine bestimmte grammatische (syntaktische) Struktur zu. Die Syntax einer Sprache legt den zur Verfügung stehenden Wortschatz und die Grammatikregeln für Wortkombinationen und für das Aufbauen von Sätzen in der Sprache fest. Die Semantik einer Sprache ist die Bedeutung von syntaktisch korrekten Worten, Wortkombinationen, Sätzen und Satzfolgen. Ein Informationsmodell ist eine Datenstruktur, in der die in der Sprache formulierten Informationen für eine weitere Verarbeitung (z.B. durch Auswertungsmechanismen und Transformatoren) abgelegt werden können.

Eine formale Spezifikationssprache liefert eine Notation zur formalisierten, präzisen Beschreibung einer Softwareoberfläche. Das UI wird in einem in sich geschlossenen Modell beschrieben. Mit Hilfe von Spezialeditoren und Validierungswerkzeugen kann die Einhaltung der Regeln der formalen Sprache und die Integrität des Modells geprüft werden.

User Interface Workbook

Seite 57 von 127

State Charts

Die State Charts können die Ablauf- und die Strukturaspekte einer Oberfläche beschreiben, bieten aber keine Hilfe zum Beschreiben, wie Dialoginhalte und Anwender-Notifikationen dargestellt werden. State Charts bieten auch keine explizite Schnittstellensicht zum funktionalen Teil der Anwendung.

Ein-Aus H

State Charts sind für die Modellierung von UIs nicht genug.

einschalten [Stromversorgung da]

þ

aus

ein ausschalten

þ

Stromversorgung

H*

Stecker raus

Netz

þ

Akku rein

Akku

Keine

þ þ

Stecker rein

Akku raus þ

Überspannung

Sicherung rausziehen

Neue Sicherung eingesetzt

Sicherung Sicherung durchgebrannt

Sicherung fehlt

þ

Trotz der Möglichkeit, Zustandshierarchien zu bilden, werden State Charts beim Spezifizieren von User Interfaces schnell groß und unübersichtlich. Über State Charts hinausgehende Möglichkeiten zur Komplexitätsreduktion werden zu wenig beachtet: Verbesserungen sind z.B. Sequenzbildungen, prototypische Vererbung, Vermeidung von Transitionen. State Charts sind allgemeine Ablaufbeschreibungen, in User Interfaces kommen aber spezialisierte Konstrukte vor: z.B. Ablaufschritte, Bildschirme, Bedienungselemente. In State Charts sind Übergänge und Zustände nicht gewichtet und daher alle gleich priorisiert. Ergonomie unterscheidet jedoch die wichtigeren Pfade und die weniger wichtigen Pfade, um z.B. die Zahl der Klicks zu wichtigen „Zielen“ minimieren zu können. In User Interfaces gibt es Haupt- und Nebenpfade. Dies sollte sich in der Spezifikation wieder finden. In User Interfaces von Verwaltungsanwendungen kommen of strukturierte Bedienungsabläufe und die daran hängenden Bedienungselemente vor, mit States sind aber nur unstrukturierte Abläufe möglich.

State Charts können (bedingt) zur Ablaufmodellierung von User Interfaces verwendet werden.

User Interface Workbook

Seite 58 von 127

Office Werkzeuge Office-Programme z.B. Word, Excel, Powerpoint werden vor allem von Anwendervertretern als Werkzeuge für den Entwurf von User Interfaces bevorzugt. Das liegt in den meisten Fällen daran, dass sie sofort verfügbar sind und dass man sich nicht erst einarbeiten muss, sondern sofort beginnen kann, eine Maske zu entwerfen oder einen Ablauf zu skizzieren. Man muss mit Office-Programmen keine bestimmte Methodik befolgen. Eine Überprüfung der formalen Korrektheit der auf Basis einer WordVorlage erstellten UI-Beschreibung findet nicht statt. Ebenso wenig wird der Spezifizierer programmseitig beim Schreiben der UISpezifikation unterstützt (z.B. auf formale Fehler hingewiesen oder zum Einhalten der vorgegebenen Struktur aufgefordert).

Der Spezifikationsart nach können diese Programme zu den Office-Werkzeugen gezählt werden, weil die Spezifikation aus Textbausteinen erstellt wird. Zusätzlich wird über die Textbausteine eine Struktur gelegt, deren Verwaltung und Einhaltung mit Hilfe des AnforderungsmanagementProgramms erfolgt.

Zur besseren Durchsetzung von vorgegebenen Spezifikationsschablonen werden Anforderungsmanagementsysteme wie Doors oder Rochade eingesetzt.

User Interface Workbook

Seite 59 von 127

Darstellungsorientierte Werkzeuge Dazu zählen Werkzeuge, bei denen die grafische Gestaltung und Animation, also die Form des User Interface im Vordergrund steht. Beispiele: Flash, SVG (Scalable Vector Graphics), XHTML Editoren, MS Expression. Darstellungsorientierte Werkzeuge werden von Grafikdesignern bevorzugt und meist dazu eingesetzt, die grafische Gestaltung von Dialogseiten festzulegen. Beim Arbeiten mit darstellungsorientierten Werkzeugen wird zunächst die grafische Erscheinung von Bedienelementen und das Layout der Dialogseite festgelegt, bevor eventuelle Interaktionen hinzugefügt werden.

User Interface Workbook

GUI-Toolkits und GUIBibliotheken Es gibt eine Reihe von GUIToolkits, mit denen Screendesign möglich ist. Viele Entwicklungswerkzeuge, etwa .Net VS oder Delphi beinhalten eigene Screen Editoren, mit denen Bildschirmmasken aus dem Vorrat von GUI Controls zusammengeklickt werden können.

Seite 60 von 127

UI Spezifikation - Übungen

Übung 1: Beschreiben Sie (mündlich im Dialog mit dem Kurskollegen, dann schriftlich), wie die beiden Schaufeln zu bauen sind. Annahme: Sie haben das Konzept der Schaufel eben erfunden und wollen die Prototypen der beiden Schaufeln bei einem Schlosser in Auftrag geben. þ þ þ þ

Wie wird das Werkzeug verwendet? Welche Eigenschaften werden gefordert? Woraus und wie soll es gebaut werden? Welche Form soll das Werkzeug haben?

Zeit: 20 Minuten Übung 2: Schreiben Sie eine kurze Spezifikation (max. halbe A4 Seite Text) einer Anwendung zur Kundenverwaltung. Gliedern Sie die Spezifikation nach UI Perspektiven (Anforderungen, Struktur, Dialoge, Interaktionen, Kontext).

Diese zwei Schaufeln haben die gleiche Funktion (Löcher buddeln), aber unterschiedliche User Interfaces.

User Interface Workbook

þ þ þ þ þ þ

Beschreiben Sie Use Cases und Benutzermodelle. Features, Abgrenzung Tätigkeiten, Ergebnisse, Sequenzen, Dienste Dialoginhalte, Kontrollelemente (Kerninhalte) Situationen, Ressourcen, Funktionen Ereignisse, Reaktionen (Kerninteraktionen)

Zeit: 20 Minuten

Seite 61 von 127

Fragen zu #03

1a). Was sind UI Perspektiven? 1b). Wozu kann man UI Perpektiven verwenden? 2. Zählen Sie die UI Perspektiven auf und erklären sie in Stichworten ihren Inhalt 3. Zählen Sie die verschiedenen Spezifikationsformen auf und erklären Sie in Stichworten ihre Kerneigenschaften

Antworten zu #03 1a: UI Perspektiven sind eine Gliederungsform für eine UI Beschreibung. Sie definieren verschiedene Sichten auf ein UI 1b: z.B. um UI Anforderungen strukturiert aufzunehmen, UI Beschreibungen miteinander zu vergleichen, Bewerten der Vollständigkeit einer UI Beschreibung 2: Anforderungsperspektive: Anforderungen, Features, Strukturperspektive: Tätigkeiten, Ergebnisse, Sequenzen, Dienste, Dialogperspektive: Dialoginhalte, Kontrollelemente, Kontextperspektive: Situationen, Ressourcen, Funktionen, Interaktionsperspektive: Ereignisse, Reaktionen 3: Umgangssprachliche UI-Beschreibung: formlos, Tabellarische UIBeschreibung: Formvorgabe mit Tabellen, Strukturierte UI-Beschreibung: detaillierte hierarchische Struktur/Templates, Formale UI-Modelle: semiformale Sprache, State Charts: Zustände und Transitionen, UIPrototypen mit HTML: formale Dialogseiten- und Layoutbeschreibung, Programmierte UI-Prototypen: erlebbares Modell 4: Früher wurden umfangreiche Funktionen durch wenige Kommandozeilen angestoßen und das Ergebnis z.B. als gedruckte Liste in Empfang genommen. Heute beträgt das Verhältnis von UI zu Funktionalität etwa 70 zu 30 Prozent.

User Interface Workbook

4. Wieso ist die Bedeutung von UIs bei Software gestiegen?

Seite 62 von 127

#04

Abstraktheit: Anforderungen liegen in der Regel in Form von verbalen Konzepten, Prozessmodellen und UML-Diagrammen vor und sind nur mit Spezialkenntnissen nachvollziehbar

Informationsmodell eines User Interface

Ausgangslage: Gängige Entwicklungsstrategien genügen nicht. 1

Konzepte

Code

2

Code

Anwendung

Code Entwürfe

Spezifikationen

Fehlende Erlebbarkeit: Die Stimmigkeit der spezifizierten Abläufe und Inhalte wäre im Vorfeld der Realisierung nur durch eine erlebbare Simulation der Anwendungsoberfläche prüfbar.

3

Problem 1:

è Hohe Konzeptionskosten

Abstrakte Konzepte.

Nicht transparente Konzeptionsleistung bei hohen Aufwänden für Analyse und Beratung.

Problem 2:

è Lange Entwicklungszyklen

Mehrdeutigkeit

Lücken in der Anforderungsdefinition werden erst bei der Implementierung entdeckt. Wechselnde Anforderungen führen zu langen und kostenintensiven Entwicklungszyklen.

Problem 3:

è Change Request Kosten

Keine Erlebbarkeit

Die Prüfung der Verwertung der Informationen aus Anforderungen in der Anwendung erfolgt spät und führt zu zusätzlichen Aufwänden für nachträgliche Änderungen.

User Interface Workbook

Mehrdeutigkeit: Die Konzepte sind nicht eindeutig; sie erfordern umfangreiche Rückfragen und Konzeptergänzungen während der Implementierung.

Seite 63 von 127

In der UI Beschreibung fließen Informationen über alle Teile der Anwendung zusammen

Anforderungen

Die Anforderungen an das User Interface, und die Informationen darüber, wie diese Anforderungen umgesetzt werden, sind Kerninformationen für das Wissensmanagement des Projekts. Sie können verwendet werden, um nutzbringend das gemeinsame Vorgehen im Projekt zu koordinieren. Die Anforderungen an das User Interface liefern Informationen, die alle Teile der Software betreffen. Diese Informationen müssen an alle Projektbeteiligten verteilt werden. Umgekehrt werden für das Entwickeln der Oberfläche Informationen über alle Teile der Software herangezogen und verwendet.

Prozesse

þ

Plattform

User Interface Modell

Funktionen

Ein Informationsmodell ist in der Informationstechnik eine abstrakte Abbildung von Objekten mit ihren Eigenschaften und Beziehungen sowie den Aktionen, die sie ausführen können, und den Operationen, die mit ihnen durchgeführt werden können.

Lernziel: þ

Design

Kenntnis der Informationsstruktur eines UI

Daten

Die Informationen über ein User Interface können in einem gemeinsamen Informationsmodell zusammengefasst und dem Wissensmanagement des Projekts zur Verfügung gestellt werden.

User Interface Workbook

Seite 64 von 127

Informationsgehalt des UI in einer Softwareanwendung

Kontrollelemente (bzw. Bedienelemente) sind Dinge, die

Softwareoberfläche

Kontrollelemente

þ þ

User Interface Logik Ablaufnetz

verwendet

verwendet

Dialogseiten

Eingaben des Anwenders entgegen nehmen, und / oder Ausgaben der Software präsentieren.

In Software-UIs gibt eine Reihe spezialisierter Bedienelemente, z.B. Druckknöpfe, Eingabefelder, Ausgabefelder, Regler, Auswahlfelder, Fortschrittanzeiger und so weiter. Ablaufnetz: Logik, die den Ablauf der Anwendung oberhalb der Kontrollelemente und einzelner Dialogseiten steuert: þ þ þ þ þ

Hierarchie der Ablaufschritte der Anwendung Klassifizierung der Ablaufschritte in Sequenzen (Workflow) und Services (Popups, Notifikationen) Interaktionen beim Betreten und Verlassen der Schritte Sequentielle und nichtsequentielle Übergänge zwischen Schritten Ablaufkontrolle und Navigationsinstrumente

Dialogseiten: Dialogwidget und Logik, die auf der Ebene einer Dialogeinheit stattfindet:

verwendet

Kontext

Ein User Interface hat zwei verschiedene Sorten von Bestandteilen: • Ein- und Ausgabeelemente: Das sind die vom Anwender wahrnehmbaren Informationsträger (siehe Kontrollelemente). • User Interface-Logik: Das sind die logischen Konstrukte, die das Zusammenspiel der Ein- und Ausgabeelemente organisieren. User Interface Workbook

Die UI Bestandteile fließen zusammen mit Anforderungen in das Informationsmodell des UI ein.

þ þ þ

Dialogschnittstelle für einen logischen Schritt Anordnung der Kontrollelemente auf dem Bildschirm Interaktionen für die Kontrollelemente

Kontext: Logik, die zwischen dem Zustand der Oberfläche und den Anwendungsfunktionen vermittelt: þ þ þ þ þ þ þ þ

Verwendung von Daten Verwendung von Funktionen Prozesslogik Statusermittlung durch Situationsindikatoren Verwendung von Widgets Verwendung von Layouts Verwendung von Datenmustern Bezugnahme auf Anforderungen Seite 65 von 127

Informationsmodell: Hierarchie der Ablaufschritte

Die in der Spezifikation enthaltene Information kann in logische Ablaufschritte unterteilt werden. Logische Schritte legen eine hierarchische Ablaufstruktur fest, wobei jeder logische Schritt in weitere logische Schritte unterteilt sein kann. So werden die Aufgaben des User Interface in eine Reihenfolge gebracht und in kleinere Teilaufgaben gegliedert.

Breite

Prozess Ablauf beschreibung

Phase Tätigkeit, Job Arbeitsschritt, Workstep

Varianz

Dialogfluss Grenze Dialogseite

Teilschritt Element

Arbeitsschrittmodelle

Tiefe

Die Ablauflogik der Anwendung lässt sich in immer feinere logische Schritte unterteilen. Die oberen Stufen der Hierarchie steuern den Fortschritt von Vorgängen. Die unteren Stufen der Hierarchie bilden die Schnittstelle zu Kontrollelementen (Dialogseiten, Dialogabschnitte, einzelne Buttons, Ein- und Ausgabefelder, etc.). User Interface Workbook

Ablaufnetz: Hierarchie aus Arbeitsschritten, Tätigkeiten und Phasen mit Verankerung der Ablaufsteuerung auf der Ebene eines Dialog-Arbeitsschritts (also einer Dialogseite). Das Verankern der Dialogebene auf Arbeitsschrittebene bedeutet, dass man beim Spezifizieren nach Ablaufschritten sucht, die eine in sich so weit abgeschlossene Einheit bilden, dass sie auf einer Dialogseite abgehandelt wird. Die Dialogseite ist für den Arbeitsschritt ein Kommunikationsmedium, mit dem die zum Arbeitsschritt gehörenden Daten dem Anwender angezeigt werden, Eingabedaten erfasst und die Befehle zum Fortsetzen des Workflows empfangen werden. Ein Arbeitsschritt sollte ein definiertes Ergebnis haben, so dass man z.B. den Workflow nach einer Unterbrechung des Arbeitens mit der Anwendung auf dem gleichen Arbeitsschritt wieder aufsetzen kann. Ein Teilschritt ist ein Teil eines Arbeitsschritts, das aber im Workflow kein in sich eigenständiges Ergebnis hat. Auf einer Dialogseite, die einen Arbeitsschritt abbildet, kann der Teilschritt durch einen Dialogabschnitt abgebildet werden. Ein Dialogabschnitt wird auf der Dialogseite z.B. durch eine GroupBox, eine Abschnitttrennlinie oder durch einen Karteireiter (bei einem Wizard-Dialog) repräsentiert. Ablaufelemente, wie z.B. die Ausgabe eines einzelnen Wertes, Auswahl eines Werts aus einer Liste, das Auslösen eines Dialogübergangs) werden durch Kontrollelemente repräsentiert, z.B. durch Text- und Grafikwidgets, Auswahllisten oder Buttons.

Seite 66 von 127

Informationsmodell eines UI: Klassen und Beziehungen

Logical Steps sind die Struktur-Perspektive der Spezifikation. Jeder logische Schritt kann [muss aber nicht] als Kommunikationsmedium zum Anwender einen Dialog verwenden. Ein Dialog besteht aus Widget-Gruppen und aus einzelnen Widgets, die Bedienungselemente (z.B. Grafische Einund Ausgabe-Controls, Hardbuttons, Voicebuttons) repräsentieren.



Specified User Interface declares the existence of consist of

Dialoge (z.B. GUI Seiten), Widget Groups und Widgets sind die Dialog-Perspektive der Spezifikation. 0..*

1..* Requirement Description

Logical Step use

0..1

Dialog

0..*

0..* requires

Kontext item

0..*

1..*

Widget Group

0..* 0..*

e. g. Configuration, V ariants , S ituations , Repres entation, Data Referenc es , Func tion Referenc es .

requires

1..*

Widget

requires

0..* 0..*

Die Kontextelemente, auf die die Oberfläche Bezug nimmt, sind die Kontext-Perspektive der Spezifikation. Die Anforderungen an die Anwendung und ihre Bedienung sind Grundlage der Struktur, der Dialoge und der Kontextbezüge. Die Verknüpfung der Oberflächeneigenschaften mit den zugrunde liegenden Anforderungen erzeugt ein Geflecht, das die gegenseitige Abhängigkeit abbildet. Die Anforderungen und ihre Verknüpfungen untereinander sowie die Verknüpfungen mit den Oberflächenbestandteilen sind die Anforderungsperspektive der Spezifikation.

0..* Interaction

Die Oberfläche interagiert mit dem Anwender im Kontext der Funktionen und Daten der zugrunde liegenden Anwendung. Das Verhalten und die Anzeigen der Oberfläche hängen von den verfügbaren Funktionen, von Daten der Anwendung, und von den Aktivitäten des Anwenders in der Oberfläche ab.

requires

Die Spezifikation eines UI lässt sich als ein Geflecht von typisierten Informationen mit definierten Beziehungen strukturieren.

User Interface Workbook

Seite 67 von 127

Use Cases des Informationsmodells für UIs (I)

Verhalten ist die Art und Weise, wie die Anwendung agiert und reagiert. Das Verhalten einer Softwareoberfläche ist durch die Summe ihrer Aktionen und Reaktionen mitsamt deren Auslösern und Konditionierung festgelegt.

z.B. Dialogseiten, Dialogabschnitte, logische Kontrollemente

Interaktionen (als Oberbegriff für Kombinationen von Aktionen und Reaktionen) verknüpfen die für den Anwender wahrnehmbaren Teile der Oberfläche (also in der Regel Kontrollelemente) mit den Funktionen der Anwendung und die Kontrollelemente untereinander.

Dialogelemente modellieren

Interaktionen werden durch Ereignisse ausgelöst.

beinhaltet

UI Struktur modellieren z.B. Logische Schritte, Standardsequenzen, Vererbung

beinhaltet

beinhaltet

UI modellieren

z.B. Ergebnisse, Features, Varianten, Erläuterungen

z.B. Ereignisse, Reaktionen, Bedingungen

beinhaltet

Restriktionen modellieren z.B. Prozessanforderungen, Werkzeugeinsatz, Infrastruktur

Ereignisse können durch Aktionen des Anwenders oder durch Initiative der Anwendung (z.B. in Folge eines Systemereignisses) ausgelöst werden. Die Auswertung der Bedingungen, wie die Oberfläche fallabhängig auf Ereignisse reagiert, gehört ebenfalls zu den Interaktionen. Das Verhalten der Oberfläche setzt sich also aus Ereignissen, Aktions-/Reaktionsbedingungen und Aktionen/Reaktionen zusammen.

beinhaltet

beinhaltet

Anforderungen modellieren

Verhalten modellieren

Kontext modellieren z.B. Schablonen, Daten- und Funktionsbezug, Listenmuster, Formatschablonen, Situationen

Grundbestandteile einer UI Beschreibung: þ þ þ þ

þ

Ablaufschritte – repräsentieren Zustände des UI Bedienelemente – repräsentieren manipulierbare Dinge Interaktionen – repräsentieren Verhaltensregeln Kontextelemente/Varianzregeln – repräsentieren die Umwelt, auf die Bezug genommen wird und die Fallabhängigkeiten der Interaktionen Anforderungen und Restriktionen – repräsentieren die Zweckbestimmung der UI-Bestandteile und die Annahmen über Rahmenbedingungen

Das Befüllen des Informationsmodells erfolgt durch abwechselndes, iteratives Ausführen der obigen Modellierungsaufgaben. User Interface Workbook

Seite 68 von 127

Use Cases des Informationsmodells für UIs (II) Das macht der Entwickler mit einem UI-Modell: • Inkrementieren: Hinzufügen von User Interface-Bestandteilen (z.B. Steps, Dialoge, Listen, List Items). • Transkribieren: Ausdetaillieren und Ausformulieren von Dialoginhalten, Verhalten und Kontext; verknüpfen mit Anforderungen.

Bei einer Anwendung der nichttrivialen Größe (so ab 50 Dialogseiten) häufen sich die Fragen nach Formulierbarkeit und Beherrschbarkeit der User Interface Definition (ob als Code oder als Spezifikation). Die Komplexität einer User Interface Definition wächst schnell, weil die Anzahl der möglichen Beziehungen (und damit die Anzahl der gegebenenfalls zu beschreibenden Beziehungsregeln) zwischen n UI-Elementen mit dem Faktor n * (n - 1) / 2 quadratisch wächst. Die Formel gibt Anzahl der möglichen direkten Kommunikationswege zwischen n Partnern bzw. interaktiven Elementen an.

• Modifizieren: Ändern von User Interface-Bestandteilen zur Anpassung an veränderte Anforderungen. • Exploratives Design: Skizzieren; iteratives, entdeckendes Vervollständigen von User Interface-Bestandteilen. • Exploratives Lesen: Erforschen der Struktur, der Klassifikation, der spezifizierten User Interface-Bestandteile. • Suchen: Nachforschen nach bekannten Fragestellungen, z.B. welche User Interface-Bestandteile haben Interaktionen. • Kommunizieren: Präsentation und Kommunikation der UI Entwürfe im Entwicklungsteam und vor dem Kunden.

User Interface Workbook

Seite 69 von 127

UI Informationsmodell und Softwarearchitektur (I) Informationsmodelle für Spezifikation und Programmierung sind verschieden • Eine User Interface Spezifikation hat Planungscharakter und soll daher plakativ und schnell zu ändern sein, um auf wechselnde Anforderungen und Kundenwünsche einzugehen, vergleichbar den Architektur-Skizzen und Innenarchitekturplänen von Gebäuden. • Der Quellcode der Implementierung codiert detaillierte Verfahrensanweisungen mit IO Anweisungen für eine spezielle Ablaufmaschine. • Einigkeit der Stakeholder und detaillierte Umsetzung der Anforderungen sind zwei verschiedene Ziele

Das Wort Architektur ist zusammengesetzt aus den griechischen Wörtern „das Erste tectum aus dem Lateinischen - „Gebäude“. Es ließe sich daher wörtlich mit „Erstes Handwerk“ oder „Erste Kunst“ übersetzen. [Wikipedia] þ

þ

þ

Eine Systemarchitektur ist ein Gebilde aus inter agierenden Systemkomponenten, auf / in dem Applikationssoftware betrieben wird, die eine Funktionalität implementiert bzw. einen Prozess abbildet. Zu einer Systemarchitektur zählen applikationsexterne Softwarekomponenten (z.B. Datenbanken, Application Server, Verzeichnisdienste), Hardwarekomponenten (z.B. Computer, Drucker) und Systemdienste (z.B. Logging, Authentifizierung). [Dormanns] Eine Softwarearchitektur beschreibt die grundlegenden Elemente und die Struktur eines Softwaresystems. Eine Softwarearchitektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie die Beschreibung ihrer Beziehungen. [Balzert, S. 716] Die Softwarearchitektur teilt eine Software in Komponenten auf. Sie bestimmt den Zuschnitt, die Aufgabenteilung und die Zusammenwirkung der Softwarekomponenten in der Laufzeitumgebung. Zur Softwarearchitektur gehört auch die Organisation und Verwaltung der Quellartefakte in der Entwicklungsumgebung.

• Das Informationsmodell der Spezifikation sollte dennoch in der Implementierung weiterverwendet werden können.

User Interface Workbook

Seite 70 von 127

UI Informationsmodell und Softwarearchitektur (II)

UI orientierte SW-Architektur

Informationsarchitektur

UI Bestandteile (Controls) Interaktionen

Informationsarchitektur bezeichnet die Konzeption und Definition der Struktur eines Informationssystems, meist einer Software, sowie der für den Nutzer des Systems möglichen Interaktionen und schließlich der Benennung der in dem System enthaltenen Informationseinheiten und Funktionen. [Wikipedia] Die Informationsarchitektur ist eine Kombination aus Strukturierung von Wissen, Organisation von Daten und Benutzerinteraktionen zum Zugriff auf diese Informationen. Zu den Aufgaben eines Informationsarchitekten gehört der Aufbau von Informationsmodellen sowie von Repräsentationsformen für das Auffinden und Verwenden (z.B. gruppieren, navigieren, verknüpfen, indizieren) von den im Informationsmodell gespeicherten Informationen. Eine Prozessarchitektur beschreibt die einzelnen Schritte eines (Geschäfts-)vorganges, die Abhängigkeiten der einzelnen Prozessschritte und die Anhängigkeiten und Verknüpfungspunkte verschiedener Prozesse. [Dormanns]

Prozessarchitektur

UI Abläufe

Eine UI orientierte Softwarearchitektur ist eine Softwarearchitektur, die Komponenten zur Verwaltung von UI Bestandteilen und Interaktionen (Informationsarchitektur) und zur Handhabung der UI Abläufe (Prozessarchitektur des UI) berücksichtigt.

Das UI Informationsmodell kann für die Informations- und Prozessarchitektur der Software verwendet werden.

User Interface Workbook

Seite 71 von 127

UI Informationsmodell und Softwarearchitektur (III)

Das MVC-Entwurfsmuster wurde mit der Verbreitung von SmallTalk bekannt. Es unterscheidet zwischen

Modell

nderungsnachricht

Zustandsabfrage

þ þ

View selektieren

View

þ

Zustandsänderung

View: Präsentation (Ausgabe, Layout) Controller: Programmsteuerung (Interpretieren von Benutzeraktionen), Vermittlungsschicht zwischen View und Modell Modell: Objektmodell (Anwendungsfunktionalität, Datenhaushalt).

View

Controller

Eingabeereignisse

þ þ þ þ

Modell

Ausführen von Methoden Nachricht über Ereignisse

Funktionen

Daten

Controller

Interne Abläufe

Präsentiert Modellinhalte Fordert vom Modell Aktualisierungen an Sendet Eingabeereignisse zum Controller Ermöglicht das Selektieren eines Views

Modell þ þ þ þ

View

Kapselt anwendungsinterne Zustände Beantwortet Zustandsanfragen Stellt die Funktionalität der Anwendung bereit Benachrichtigt den View über Änderungen

Controller

Schritte

Kontext

Interaktionen

Elemente

Die gängigen Methoden der Systemmodellierung (z.B. UML) detaillieren den Modell-Anteil der Anwendung. Ein UI Informationsmodell detailliert den View- und den Controller-Anteil der Anwendung. User Interface Workbook

þ þ þ þ þ þ þ

Definiert das Verhalten der Anwendung Ordnet Anwenderaktionen zu Modellaktualisierungen zu Wählt den View zur Beantwortung der Ereignisse aus Ziele des Einsatzes von MVC sind: Trennung von Anzeige, Präsentations- und Geschäftslogik sowie Datenzugriff Mandantenfähige Anwendung Wieder verwendbare Aktionen

Seite 72 von 127

Fragen zu #04

1. Welche der folgenden Begriffe bezeichnen Kontrollelemente? þ þ þ þ þ þ þ

a). Anforderung b). Logischer Schritt c). Dialogseite d). Widgetgruppe e). Widget f). Interaktion g). Kontextelement

2: Welche der folgenden Aussagen treffen zu? þ þ þ þ þ

a). Logical Steps repräsentieren das Ablaufnetz b). Logical Steps bilden die Dialogperspektive der Spezifikation c). Logical Steps bilden die Strukturperspektive der Spezifikation d). Die Dialogseite ist das Kommunikationsmedium eines Ablaufschritts e). Ablaufschritte bestehen aus Widgets

Antworten zu #04 1: c), d), e) 2: a), c) und d)

User Interface Workbook

Seite 73 von 127

#05

Informationsdichte: Verhältnis der vermittelten Informationen zur Anzahl der verwendeten Sprachelemente einer Notation

UIs modellieren mit UML und DSLs

Typische UML Diagramme, die für eine UI Beschreibung herangezogen werden können:

Idef0 Regeln: þ þ þ þ þ

Im Kasten: Tätigkeit (Wort-Phrasen verwenden), Input von links, Output nach rechts, Rolle/Ausführendes System von unten, Regeln von oben anzeichnen Maximal 5 Tätigkeiten pro Diagramm

• Use Case Diagramme: Bestimmen des Anwendungsumfangs, der Kernfeatures und der Kausalketten • Aktivitätsdiagramme (an IDEF0 angelehnt): Bestimmen der Ablaufstruktur und der Systemgrenzen • Sequenzdiagramme: Darstellen von Parallelisierung und Synchronisation von Vorgängen (Aus User Sicht) • Klassendiagramme: Bestimmen von UI Objekten, deren Kardinalitäten und Beziehungen untereinander

User Interface Workbook

Seite 74 von 127

Domänenspezifische Sprachen Eine domänenspezifische Sprache (engl. domain specific language, DSL) ist eine Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen wurde. Domänenspezifische Sprachen drücken bei hoher Informationsdichte fachliche Sachverhalte kurz und effizient aus. Die in einer semiformalen oder formalen domänenspezifischen Sprache formulierten Informationen können (in der Informatik) mit Hilfe von Programmen (Parser, Interpreter, Transformer) ausgewertet, und als Daten für andere Programme zur Verfügung gestellt werden.

User Interface Workbook

anzeigen) ist das Teilgebiet der Sprachwissenschaft, das sich mit der Bedeutung sprachlicher Zeichen befasst. Als sprachliche Zeichen gelten alle Ausdrücke, die eine lautliche, schriftliche oder andere Form mit einer Bedeutung verbinden. Die kleinsten Zeichen sind in diesem Sinne die Morpheme, die nächstgrößeren die Wörter bzw. Lexeme; es folgen die Satzglieder, Teilsätze, Sätze und Texte. Alle diese Einheiten erfüllen die Bedingungen für "Zeichen". Traditionell sind aber Morpheme und Wörter die Hauptgegenstände der linguistischen Semantik.st eine Sprache eine Menge von Zeichenfolgen über einem Alphabet. Formale Semantik beschäftigt sich mit der exakten Bedeutung von (künstlichen) Sprachen. Dabei kann sowohl die Bedeutung bestehender Sprachen untersucht als auch die Bedeutung neu geschaffener Sprachen festgelegt werden. In Abgrenzung zur Semantik im allgemeinen Sinn, wie sie vor allem in Philosophie und Linguistik betrieben wird, arbeitet die formale Semantik mit formalen, logisch-mathematischen Methoden. Formale Semantik hat zum Ziel, die Bedeutung von Computerprogrammen in einer formalen Sprache auszudrücken — sie soll also die Semantik eines Computerprogramms syntaktisch ausdrücken, so dass sich über das Anwenden von Ableitungsregeln (Kalkülen) Aussagen über das Programm beweisen lassen. In der Softwaretechnik bezeichnet Validierung (auch Plausibilisierung, als Test auf Plausibilität, oder engl. Sanity Check genannt) die Kontrolle eines konkreten Wertes darauf, ob er zu einem bestimmten Datentyp gehört oder in einem vorgegebenen Wertebereich oder einer vorgegebenen Wertemenge liegt. Sie ist ein wichtiger Aspekt der Qualitätssicherung, der sicherstellen soll, dass ein implementiertes Programm den vorher aufgestellten Anforderungen genügt. Programmfehler und Sicherheitsprobleme sind oft auf fehlende Plausibilisierung von Eingabewerten zurückzuführen.

Seite 75 von 127

Oberfläche und Funktion einer Software bedingen sich gegenseitig.

Funktionalitäten Funktionale Anforderungen

Informationsmengen Fachliche Attribute

Oberfläche und funktionale Anwendung bzw. das Modellieren der Softwareoberfläche und der Funktionalität haben eine Reihe von Berührungspunkten. An der Oberfläche werden Funktionen und Daten des Softwaresystems verwendet. Beim Beschreiben einer Oberfläche setzen die Spezifizierer die Existenz der verwendeten Daten und Funktionen voraus und treffen Annahmen über Datenstrukturen und Funktionsweisen der Anwendung. Beim Modellieren der Oberfläche schließt man also von der Bedienung auf Funktionen und Daten bzw. auf Objekte.

Fachliche und technische Restriktionen

Workflows, Varianten OberflächeAnforderungen

Worksteps, Dialoge Bausteine, Templates Schlüssel, Auswahllisten

UI Entwickler treffen Annahmen über Daten und Funktionen der Anwendung. Objektentwickler treffen Annahmen über Verwendung der Objektinstanzen an der Oberfläche.

User Interface Workbook

Beim objektorientierten Modellieren ist es umgekehrt: Man schließt von den Funktionen und Datenstrukturen auf ihre Verwendung. Daher ergänzen sich beide Ansätze. Es liegt nahe, die Annahmen aus der User InterfaceModellierung mit Klassenmodellen, Use Case-Diagrammen, Aktivitäts- und Sequenzdiagrammen abzusichern. Die Modelle der Oberfläche und die Modelle der Funktionen und der Daten ergänzen und überprüfen sich gegenseitig. Oft kann das Was und das Wie einer Software nur im Zusammenhang verstanden werden, daher empfiehlt es sich, UI und Funktionalität in gegenseitiger Abstimmung zu entwerfen. Oberflächenanforderungen haben Einfluss auf funktionale Anforderungen. Umgekehrt wirken sich Funktionen auf die Art der Bedienung aus. Fachliche und technische Restriktionen wirken sowohl auf die Bedienung als auch auf die Funktionen. Inhaltliche Anforderungen stehen in Wechselwirkung mit Nutzungsanforderungen, d.h. sie bedingen sich gegenseitig.Das in der herkömmlichen Vorgehensweise postulierte, voneinander getrennte Betrachten dieser beiden Bereiche ist nicht praktikabel. Mit der UI Orientierung wird den o.g. Wechselwirkungen Rechnung getragen und Behandlungsmöglichkeiten für die sich daraus ergebenden Aufgaben aufgezeigt.

Seite 76 von 127

Oberfläche ist nicht funktional bestimmbar Benutzeroberflächen können nicht aus der Funktionalität abgeleitet werden.

Für die Bedienung interaktiver Systeme genügt das EingabeVerarbeitung-Ausgabe Prinzip nicht. Techniker entwickent ein Produkt von innen nach außen, Anwendervertreter und Spezifizierer hingegen definieren das Produkt von außen und treffen Annahmen über seinen inneren Aufbau. þ

• Die Bedienung der Anwendung wird durch Informationen beschrieben, die nicht im Daten- und Funktionsmodell zu finden sind: z.B. Layout, Design, Bedienungsreihenfolge, Hervorhebung von wichtigen Bedienungselementen.

þ

þ

Anwendervertreter interessieren sich für die Oberflächeninhalte und für das Verhalten der Oberfläche. Das Augenmerk der Spezifizierer liegt auf den Interaktionen und den Regeln, die das Verhalten der Oberfläche bestimmen. Im Fokus der Aufmerksamkeit der Programmierer liegt das Zusammenspiel der Interaktionen mit den Systemfunktionen und mit dem Datenhaushalt der Anwendung.

• Die Schnittstellen zwischen Nutzer und Anwendung bestehen nicht auf funktionaler Ebene, sondern erfolgen durch interpretierende Wechselwirkung von Ein- und Ausgaben.

User Interface Workbook

Seite 77 von 127

UI und Funktion werden im gemeinsamen Kontext entwickelt Vorgehenskarte für das Verbinden der UI Modellierung mit der Funktionsmodellierung: UI Inception Modell

Anforderungen an Verwendung

UI Perspektiven modellieren (Ablaufstruktur, Dialoge, Interaktionen, Kontext) UML Modellgerüste

Nächster UI Fertigstellungsgrad

UML modellieren (Klassen, Use Cases, Kontroll- und Datenflüsse)

UI Modellierung fördert die Kommunikation im Projekt und unterstützt die Erstellung der funktionalen Modelle (z.B. durch die Verwendungssicht der geforderten Daten und Funktionen). Durch paralleles Entwerfen von Verwendungsaspekten und der technischen Umsetzung erhalten Sie zwei Teilmodelle, die sich gegenseitig ergänzen und bestätigen. Modell der Anwendungsoberfläche

Data Dictionary

Anforderungen an Funktionen

Anforderungen an Daten

UI Modellierung verträgt sich gut mit den allgemein verwendeten Methoden (UML, RUP, V-Modell) und ergänzt diese um UI-orientierte Methoden und Vorgehensweisen.

UML Modelle

Anforderungen an Abläufe

þ þ þ þ

Ablauflogik Präsentationslogik Dialogseiten, Kontrollelemente Oberflächenabläufe

Modell des Innenlebens der Anwendung þ þ þ þ

Datenmodell Funktionsvorrat Algorithmen systeminterne Abläufe

Durch Verbinden von Objekt- und Funktionsmodellen (z.B. in UML) mit UI Modellen (in UML oder mit DSLs) erhält man ein in sich geschlossenes, abgesichertes und rundes Gesamtbild der Anwendung.

User Interface Workbook

Seite 78 von 127

Beispiel: Eine DSL zum Spezifizieren von UIs (I)

Das Blockdiagramm zeigt eine Übersicht der Sprachelemente einer UI Spezifikationssprache

head

flow structure

cross references

contains

step

step ...

Eine eindeutige Spezifikationssprache für UIs ist notwendig und möglich þ

requirements

step ...

reuse

Eine formale Struktur zur UI-Beschreibung:

þ

use

Eine eindeutige Spezifikationssprache für Benutzeroberflächen ist notwendig, um UI Entwicklung mißverständnisarm abstimmen und koordinieren zu können. Sie ist möglich, weil das UI programmiert werden kann. Eine Spezifikationssprache entsteht, wenn man die Details technischen UI-Umsetzung wegläßt (=Abstraktion von der Technik).

interactions presentation dialog

reuse

context & restrictions

element ...

application objects

group

data values

element ...

use

element ... dialog ... widget

reuse

functions

situations

widget ... layout

patterns

layout ...

User Interface Workbook

Seite 79 von 127

Beispiel: Eine formale DSL zum Spezifizieren von UIs (II) Workflow Step with Screen named [ Hallo_Welt ] using Layout ~[ Hallo_Anordnung ] contains Text [ Hallo, Welt! ] placed at ~[titelzeile] using Widget ~[hallo_text_widget] Button [ Ende ] placed at ~[fusszeile] using default Widget on any command unconditionally leave current Step

Hallo Welt Spezifikation eines UIs in einer UI DSL Workflow Step: Ablaufstruktur Screen: Dialogsicht mit logischen Kontrollementen Layout: Anordnungsvorschrift Widget: Physisches Kontrollelement On … Command: Interaktion

Layout named [ Hallo_Anordnung ] !! ( Html ist nur ein Beispiel fuer die Formulierung eines Layouts. Hier koennte eine beliebige andere Layoutvorschrift stehen. Zum Umfang der DSL gehoeren lediglich die Platzhalter. ) {::

placeholder named [titelzeile]

placeholder named [koerper]

placeholder named [fusszeile]

::} Widget named [hallo_text_widget] !! ( Schnittstelle zu Darstellungselementen. Man kann hier, umgangssprachlich oder formalisiert, z.B. in SVG / HTML festlegen, wie das Widget aussehen soll. ) {::

~[value]

::} User Interface Workbook

Seite 80 von 127

Beispiel: Systemgrenzen einer Anwendung

Das IDEF0-Aktivitätsdiagramm zeigt die Systemgrenzen einer Anwendung zur Kundenverwaltung

Formlose Beschreibung: Die Kundenverwaltung dient dazu, Kundeninformationen in einer Kundenkartei zu organisieren. Es können neue Kundenkarten angelegt sowie vorhandene Kundekarten abgerufen und gepflegt werden. Die Kundenverwaltung hat eine Suchfunktion und eine Schnittstelle zum Bestell- sowie zum Mailingsystem. Systemgrenzen-Diagramm: Kundeninformationen

Kunden suchen

Kundenkartei

Treffer

Kundenliste Selektierte Kundenkarte ansehen Kundenkarte pflegen

Kundenkarte geändert

Kundenkarte löschen

Kundenkarte gelöscht

Kundenkarte verwenden Kundenkarte anlegen

User Interface Workbook

Kontaktdaten Kontaktliste Kundenkarte angelegt

Bestellungen abwickeln Mailings organisieren

Seite 81 von 127

Beispiel: Use Case Diagramm Überblick der Anwendungsfälle der Kundenverwaltung (oberste Ebene) Kundenverwaltung

Suchkriterien erfassen

beinhaltet

beinhaltet

Kundenliste einschränken

beinhaltet

erweitert

Kundenkarte anlegen

Kundenkarte löschen Kundenkarte pflegen

beinhaltet

Einige Do‘s and Don‘ts für das erstellen von Use Case Diagrammen Do

Kundenkartei verwalten

beinhaltet

Use Case Diagramm für die Anwendungsfälle der Kundenverwaltung

þ þ þ þ þ

Do not do þ þ þ þ

Kundenliste ansehen beinhaltet

þ

Kundeninformationen erfassen

User Interface Workbook

Einträge aus Kundenliste wählen

Systematisch vorgehen (Zielebenen festlegen) Anwendungsdomäne/Systemgrenzen festlegen oder zumindest kennen Auf der fachlichen Ebene bleiben Detail-Level einhalten Einheitliche, semi-formale Beschreibungsformen, Wortphrasen verwenden

Algorithmen beschreiben Business Rules beschreiben Gesetzliche/behördliche Vorgaben beschreiben Zu niedriges Level wählen (z.B. „login“, „Gerade zeichnen“) Prüfen, ob der Use Case alle definierten Eigenschaften erfüllt

beinhaltet

Daten an Bestell- o. Mailingsystem übergeben

Seite 82 von 127

Beispiel: DSL Beschreibung

Grobe Beschreibung der Ablaufstruktur der Kundeverwaltung in einer UI DSL

Workflow named [Kundenverwaltung] contains Workflow Step [Kundenliste ansehen] using Screen contains Service Step ~[Kunden suchen] Service Step ~[Kundenkarte anlegen] Service Step ~[Kundenkarte ändern] Service Step ~[Kundenkarte(n) löschen] Service Step ~[Kundendaten an Auftragsverwaltung übergeben] Service Step ~[Kundendaten an Mailing übergeben] on start Do ~[Kunden suchen] Service Step named [Kunden suchen] using screen on start Do ~[Recall last user search criteria] screen using Layout ~[suchkriterien] contains TextEdit named [Nachname] TextEdit named [Vorname] Button named [Suchen] on push command do function ~[Trefferliste aktualisieren] Service Step named [Kundenkarte anlegen] using Screen contains … on leave do function ~[Kundenkarte speichern] Service Step named [Kundenkarte ändern] based on ~[Kundenkarte anlegen] on start do function ~[Kundenkarte füllen] … User Interface Workbook

Seite 83 von 127

DSL Grenzfälle der Semantik: Workflow und Service Steps

Sequence Step Sequence Step

Enter Leave

Die in einer DSL verwendeten Konstrukte müssen syntaktisch und semantisch klar festgelegt werden, um missinterpretationen zu vermeiden. Beim Abarbeiten der logischen Schritte im MMI treten verschiedene Kombinationen der Aufrufhierarchie auf. In Abhängigkeit von der semantischen Konvention hat das verschiede Auswirkungen auf den Zustand der MMI Maschine. Zielsetzung: Anlehnung der semantischen und syntaktischen Regeln an etablierten Standards (UML, OCL, Automaten)

Enter Leave Screen Sequence Step Enter Leave

Service Step Enter Leave

Aufeinanderfolgende Sequence Steps bilden den Workflow der Anwendung. Service Steps bilden Dienste, die keine bestimmte Stelle im Workflow haben, ab. User Interface Workbook

Seite 84 von 127

DSL Grenzfälle der Semantik: Schrittzustand

Solche Abfolgen werden bei der Beschreibung eines UI festgelegt und liegen bei entsprechender Formalisierung in einer maschinell verarbeitbaren Form vor. Sie können verwendet werden, um den Dialogfluss in der Software zu steuern.

Logischer Schritt Enter

Status

Oft werden in einer Software Arbeitsabläufe, sog. Workflows abgebildet. Hierbei handelt es sich um Abfolgen von Dialogen mit genau festgelegtem Arbeitsziel und Zwischenergebnissen.

Exit Restriktion: Semantischer Raum für Domänenspezifika muss durch das Metamodell offen gelassen werden. Beim Bestimmen des Abarbeitungsfortschritts von logischen Schritten ist die Bedeutung von Zuständen und deren Kombinationen domänenspezifisch. Für die Ausführbarkeit einer Spezifikation muss die domänenspezifische Semantik in eine domänenunabhängige Logik überführbar sein.

Step Progress State Ampel mit k Lichtern Es ist immer nur ein Licht an Es ist immer exakt ein Licht an

Der Bearbeitungsfortschritt des Workflows setzt sich aus Bearbeitungsfortschritt einzelner Schritte modelliert zusammen.

User Interface Workbook

Seite 85 von 127

Übungsblatt: Anwendung zur Kundenverwaltung Übung 1: Schreiben Sie einen UI orientierten Entwurf für eine Anwendung zur Kundenverwaltung Anforderungen: Kundendatensätze anlegen, ändern, löschen, suchen und übernehmen in die Auftragsverwaltung. Treffen Sie ggf. Annahmen über weitere funktionale Anforderungen, Rahmenbedingungen und Restriktionen und dokumentieren Sie diese. Ergebnisse:

Übung 2: Fügen Sie Ihrem Entwurf eine semiformale Beschreibung in einer DSL zu. Verwenden Sie die Schlüsselworte • Sequence-Step, Service-Step • Screen, Section, List, Button • Action, Situation Legen Sie bei Bedarf Syntax und Semantik weiterer Keywords fest.

• Ablaufstruktur • Anwendungsfälle und Funktionen • Dialoge (Kernfelder ohne Layout) • Interaktionen (Kernbedienelemente und Aktionen) • Kontextbehandlung (Welche Fallabhängigkeiten gibt es?) • Verknüpfung zu Anforderungen Form: freie Wahl der Beschreibungsmittel, z.B. formlose Textbeschreibung, Stichwortlisten, Diagramme, DSLs

User Interface Workbook

Übung 3: Ergänzen Sie Ihren Entwurf um • Ein Use Case Diagramm (aus Benutzersicht) • Ein Aktivitätsdiagramm (aus Benutzersicht) • Ein Klassendiagramm (aus UI Sicht)

Seite 86 von 127

Fragen zu #05

1. Welche Aussagen treffen auf eine DSL (domain specific language) zu? þ þ

Antworten zu #05 1: d), e) 2. b) 3: a), b), c) und d) 4: a) und b)

þ þ þ

a). Eine DSL beschreibt die Ablaufperspektive eines UI. b). Die Informationsdichte einer UI Beschreibung wird mit einer DSL verkleinert. c). Jede DSL ist formal d). Jeder formale DSL hat eine exakt definierte formale Syntax und Semantik e). Semiformale DSLs haben syntaxtisch und semantisch unbestimmte Anteile

2. Welche Aussagen treffen zu? þ þ

a). Layout und Design lassen sich aus funktionalen Anforderungen ableitenb). Eingaben des Benutzers werden interpretiert, bevor sie an verarbeitende Funktionen weitergereicht werden.

3. Welche UML Diagramme können wie für die UI Spezifikation verwendet werden? þ þ þ þ

a). Use Case Diagramme: helfen beim Bestimmen des Anwendungsumfangs und der Kausalketten b). IDEF0-Aktivitätsdiagramme helfen beim Bestimmen der Systemgrenzen c). Sequenzdiagramme helfen beim Darstellen von parallelen Vorgängen beim Verwenden einer Software. d). Klassendiagramme helfen beim Bestimmen von UI Objekten und deren Kardinalitäten.

4. Was ist der semantische Unterschied zwischen Service Step und Workflow Step in einer Ablaufstruktur? þ þ

User Interface Workbook

a). Workflow Steps bilden den Arbeitsablauf ab b). Service Steps werden an verschiedenen Stellen des Arbeitsablaufs abgerufen, haben aber keine feste Reihenfolge im Workflow

Seite 87 von 127

#06

Anwenden von formalen UI Beschreibungen: Aus einer semiformalen oder formalen UI Spezifikation können Daten für verschiedene Entwicklungstätigkeiten abgeleitet werden.

UI Modelle erlebbar machen

Anwendungsmöglichkeiten der gesammelten UI Informationen • Rollenübergreifendes Wissenmanagement • Auswertungen • Umformungen • Simulation • Generieren von Steuerungsdaten • Generieren von Programmcode • Generieren von Testfällen • Generieren von Testskripten

User Interface Workbook

Seite 88 von 127

Rollenspezifische Verwendung eines gemeinsamen UI Modells

Zielgruppen und Nutzen einer MMI Evaluationsumgebung 19.04.2007

Konzeptentwickler

BedienkonzeptABK-Entwickler Entwickler

Erlebbare Spezifikation: Referenz für Implementierung,Test, Konzeptvalidierung und Entscheidungen

MMI Evaluationsumgebung

MMI formal prüfen

Ablauflogik UI Spezifikateure Entwickler

Textanzeige prüfen

Textentwickler

Layoutentwürfe prüfen

Layout-Entwickler (Grafik-LH)

Bedienelemente prüfen

z.B . Listen v on C ontrols, T exte, G rafik en, Lay outinform ationen, A blaufregeln

Validierungsteil RessourcenListen verwenden Tester

Auswertungsteil

Delta-Analysen verwenden

Metriken verwenden Implementierer

FunktionsCoCs Entwickler

Visualisierungsteil

MMI Abläufe prüfen

MMI erleben Manager

Featureentwürfe prüfen

Simulationsteil

Eine formale UI Spezifikation kann zu einer MMI Evaluationsumgebung ausgebaut werden. Dabei hat die formale UI Spezifikation unterschiedliche Nutzaspekte für einzelne Entwicklerrollen. User Interface Workbook

Seite 89 von 127

Komponenten für eine MMI Evaluationsumgebung

Präsentationsschicht Präsentationsobjekte

Laufzeitmodell für die Simulation einer formalen UI Beschreibung. þ þ þ þ þ

Screenmaschine – Darstellung Ablaufmanager – Dialogübergänge Eventmanager – Interaktionen Kontextmanager – Mapping zu Daten und Funktionen Modellmanager – Verwalten der Modelldaten und ihrer Laufzeitattribute

þ

Funktionsmapper: Bildet Requests zum Ausführen von Funktionen auf parametrisierte Methoden ab Valuemapper: Bildet Requests zum lesenden oder schreibenden Zugriff auf Daten auf das Objektmodell ab Listenmapper: Bildet den Zugriff auf Listen und Listeneinträge auf Listenobjekte ab Situationsmapper: Bildet Requests zum Abfragen von Zuständen auf Wahrheitswerte und logische Ausdrücke ab)

Dialoghandler UI-Laufzeitobjekte wertet aus

Formale UI-Spezifikation

verwendet

wird erzeugt von



Parser

UI-Laufzeitmodell Daten verwendet

þ þ þ



Kontexthandler



Funktionsmapper

Listenmapper





Valuemapper

Situationsmapper

Die o.g. Komponenten können in einem so genannten Kontexthandler zusammengefasst werden. þ

þ

Der Kontexthandler bewältigt die Aufgabe, die Oberfläche mit Informationen über den Zustand der anwendungsinternen Geschäfts- und Systemobjekten zu beliefern. In umgekehrter Richtung löst der Kontexthandler die Anforderungen von Funktionen seitens der Oberfläche in das Ausführen und das Parametrisieren einzelnen Methoden auf.



Funktionale Anwendung Geschäftsobjekte

Systemobjekte

Der Input der Simulation kann z.B. der in einer UI DSL formulierte Teil einer UI Spezifikation (Ablaufnetz, Dialoge, Kontextregeln) sein.

Eine Laufzeitumgebung kann die formale UI Spezifikation als Simulation erlebbar machen. User Interface Workbook

Seite 90 von 127

Verwendungsmöglichkeiten von Spezifikationsauswertern Die Architektur einer Software kann Komponenten vorsehen, die die Informationen aus dem UI-Modell verwalten und die Anzahl von Software-Änderungen bei Änderungen der UI-Eigenschaften minimieren. Zum Beispiel können die Reaktionen auf das Betätigen von Kontrollelementen als Regeln hinterlegt statt kodiert zu werden. Die Ablaufinformationen aus dem UI Modell können zur Steuerung der Abläufe im User Interface verwendet werden.

Eine Interpreterumgebung für formale UI Spezifikationen kann vielfältig genutzt werden. Mit modellgetriebener Software-Entwicklung erreichen wir die Durchgängigkeit zwischen dem Informationsmodell der Spezifikation und dem der Implementierung. Transformatoren ermöglichen die Übersetzung, um die Spezifikation in weiteren Entwicklungs-Phasen zu nutzen. Im Zusammenhang mit der User Interface-Architektur ist das Verknüpfen des MVC-Entwurfsmusters mit User InterfaceModellen von Interesse für die automatisierte Code-Erzeugung. Wenn möglich, soll aus einem UI-Modell der Code für View und Controller sowie die Mapping-Schicht zwischen Controller und Model (funktionale Schicht mit Datenhaushalt und BusinessLogik) generiert werden können.

Die Abfolge von Dialogbildschirmen kann als Steuerdaten hinterlegt und von einer Steuerungskomponenten verwendet werden. Die aus der UI Beschreibung ableitbaren Abfolgen von Aktionen und Reaktionen können als Anwendungstestfälle verwendet werden. Damit kann sowohl das manuelle als auch das automatisierte Testen der Software unterstützt werden.

User Interface Workbook

Seite 91 von 127

Beispiel: Werkzeuge für eingebettete Systeme

Eigenschaften integrierter Werkzeuge für eingebettete Systeme: þ þ þ þ þ

Modellbasierte Spezifikation und Simulation grafischer Oberflächen. On-the-fly-Simulation während der Spezifikationsphase. Erstellen eines „lebenden Lastenhefts“ in der frühen Phase des Entwicklungsprozesses. Integrierte Entwicklung von GUI und Sprachdialog in einem Werkzeug; Verzahnung von Modalitäten (multimodaler Dialog, z.B. Sprache und GUI).

Integrierte UI Entwicklungswerkzeuge ermöglichen das so genannte Lebende Lastenheft, bei dem die Oberfläche als Simulationsmodell spezifiziert wird. User Interface Workbook

Seite 92 von 127

Fragen zu #06

1. Was bedeutet Wiederverwendbarkeit in Bezug auf formale UI Modelle? þ

Anworten zu #06

þ þ

1: b) und c) 2: Generieren von Entwicklungsdokumenten – Erzeugen von Auswertungen, Listen und Berichten über den Stand des UI Modells; Generieren von Anwenderdokumentation – Erzeugen von Benutzeranleitungen und Hilfetexten; Testautomatisierung – Erzeugen von Skripten zur Validierung von Wertebereichen von Eingabefeldern; Generieren von Bildschirmbeschreibungen – Erzeugen von Screens und Listen von Kontrollelementen; Simulation – Visualisierungsumgebung für statische und dynamische Eigenschaften des UIs 4: a) und b) 5: a) und c)

User Interface Workbook

a). Man kann das gleiche Modell in einer anderen Anwendung wieder verwenden. b). Man kann das gleiche Modell in einer anderen Technologie wieder verwenden. c). Man kann die Informationen aus dem Modell umformen und für andere Verwendungszwecke zur Verfügung stellen.

2. Zählen Sie verschiedene Verwendungsszenarien von UI Modellen auf und erklären Sie kurz ihre Bedeutung. 3. Was beinhaltet eine UI-Beschreibung? þ þ þ

a). Beschreibung der Masken b). Beschreibung der Dialogübergänge c). Beschreibung der Parameter von Systemfunktionen

4. Identifizieren Sie Kernanforderungen an eine UI Beschreibung. þ þ þ þ

a). Verständlichkeit b). Widerspruchsfreiheit c). Erweiterbarkeit d). Bezug zur technischen Plattform

Seite 93 von 127

#07

Von der Skizze zur Implementierung

Beim Detaillieren der Anwendungskonzepte wird das UI zusammen mit dem funktional-technischen System darunter schrittweise von einer groben Skizze zu einer genauen Spezifikation detailliert. Wüsste man am Anfang des Entwicklungsprozesses alles über die zu implementierende Software, dann könnte man sie ohne weitere Entwürfe und Spezifikationen programmieren. In der Regel wird das Wissen und die Vorstellung über das Entwicklungsergebnis aber im Zuge der Konzeption verfeinert und vertieft. Dabei durchlaufen die Konzepte und die davon Abhängigen Entwicklungsartefakte verschiedene Fertigstellungsgrade. Anforderungen sind die Definition geforderter Eigenschaften. Anforderungen an Produkte werden durch ein Lastenheft beschrieben. Dieses soll alle gewünschten Eigenschaften eines Produktes beschreiben, sei es direkt oder durch Verweis auf eine entsprechende Norm. Ein Lastenheft beschreibt nicht die Art der Umsetzung, dies ist Aufgabe des Pflichtenheftes. [Wikipedia] Lernziele: þ þ þ þ

Erklären können, wie man mit einer UI Beschreibung beginnt. Erklären können, wie man eine UI Beschreibung stufenweise vervollständigt. UI Beschreibungsmethoden kennen und anwenden können. Vorgehen beim Skizzieren und Detaillieren des UI.

Die UI Spezifikation wird nicht in einem Aufwasch erstellt, sondern in mehreren Iterationen von den allgemeinen Anforderungen und Zielen bis zur Implementierungsreife verfeinert.

User Interface Workbook

Seite 94 von 127

Skizzieren und Detaillieren Die Skizze (ital.: schizzo) ist ein Entwurf, ein Konzept, ein erster Überblick. Die Skizze dient z.B. dem Architekten als einfache Ausdrucksmöglichkeit, bei der es nicht auf Genauigkeit, sondern auf die markante Darstellung einer Idee ankommt.

Im allgemeinen Fall stellt die Implementierung in der Informatik einen Wechsel der Abstraktionsebene, von der abstrakteren Ebene zur konkreteren Ebene, dar und ist somit das Gegenteil der Abstraktion. In der Softwareentwicklung ist die Implementierung das Umsetzen eines Algorithmus oder Softwaredesigns in ein Computerprogramm nach Auswahl einer geeigneten Programmiersprache. Beim Entwickeln einer Softwareoberfläche sind zeitlich parallel folgende Fragestellungen zu klären. þ

Die Konzeption (aus dem Lateinischen concipere: auffassen, erfassen, begreifen, empfangen, sich vorstellen) ist eine umfassende Zusammenstellung von Informationen, Zusammenhängen und Begründungen für ein größeres Vorhaben.

þ

Wie erreicht man in der UI-Beschreibung schrittweise den Informationsgehalt für eine vollständige Implementierung der Oberfläche? Wie klärt man in der UI-Beschreibung schrittweise die fachspezifische Bedeutung der einzelnen UI-Bestandteile?

Der Entwurf, als das Ergebnis eines Entwurfsprozesses, kann eine rein gedankliche Idee bleiben. In der Regel wird unter dem Begriff Entwurf jedoch eine Darstellung und Präsentation in Form von Texten, Zeichnungen, Grafiken und Modellen verstanden. Diese Darstellungen dienen zur Veranschaulichung und Kommunikation mit anderen Menschen. Anhand davon können Funktionsweise, Qualität, und Funktionstüchtigkeit aber auch eventuelle Fehler eines Entwurfs überprüft, diskutiert und verbessert werden. User Interface Workbook

Seite 95 von 127

Phasen in der Entwicklung eines User Interface

Die Entwicklung eines User Interface umfasst die Definition bzw. Beschaffung folgender Informationen, die in ein Gesamtmodell einfließen.

Inhaltlich abgrenzen

Sammeln & ordnen

Formen & verknüpfen

Inception

Elaboration

Construction

Transition

Systemgrenzen

Sequenzen

Funktionen

Interaktionen

Anforderungen

Dialoge

Situationen

Kontext

log. Schritte

Hauptelemente

Anzeige & Bedienung

Layout

bergänge Notifikationen

In Kontext einbetten

Varianz Restriktionen

Ergebnis der inhaltlichen Abgrenzung: Wissen, was zum die Anwendung leisten soll, aber auch, was nicht zu ihren Aufgaben gehört. Ergebnis des Sammelns und Ordnens: Umfassende Kenntnis von Abläufen, Inhalten und Zusammenhängen.

þ þ þ þ þ

þ þ þ þ þ

Dialogseitenstruktur und Inhalte der Dialoge Logische Dialogelemente (Listen, Schaltflächen, etc.) Ablaufhierarchie (Menübaum, Logische Schritte, Schrittübergänge) Ablauflogik (Ereignisse, Bedingungen, Reaktionen) Schnittstelle zur Anwendungslogik (Situationen, Verwendung von Funktionen, Zustände von angeschlossenen Geräten) Wertebereiche, Datenmuster, Auswahllisten Text- und Grafikressourcen (Anzeigetexte, Grafiken, Töne, Animationen, Streams) Anforderungsbeschreibung (Geforderte Eigenschaften, Begründung des Zwecks und der Verwendung) Variantendefinition und Variantenbezug Anzeige- und Bedienelemente, Stilelemente, Skins

Beim Skizzieren und Detaillieren von UI-Modellen sind verschiedene Entwicklungsschritte durchzuführen. Diese werden in einen Arbeitsablauf mit definierten Phasen und Fertigstellungsgraden eingereiht. þ þ þ þ

Inception = Anfang, Beginn Elaboration = Detaillierte Ausführung Construction = Bauen, Erstellen Transition = Überleiten, Übergang

Ergebnis des Formens und Verknüpfens: Nachvollziehbarkeit der geforderten Verwendungsszenarien. Ergebnis der Kontexteinbettung: Bestätigung des Einklangs der Lösung mit dem konkreten technischen und organisatorischen Umfeld. User Interface Workbook

Seite 96 von 127

UI Inception (Konzeptualisieren) In der UI Inception liegt der Schwerpunkt auf der inhaltlichen Abgrenzung des User Interface.

Eine solide UI Inception ermöglicht die Zuordnung von Features zu Anforderungen. Damit lässt sich z.B. bewerten, ob ein im Verlauf des Entwurfsprozesses gefordertes Feature den Zweck der Anwendung erfüllt, erweitert oder abändert.

• Anwendung inhaltlich abgrenzen • Umfang skizzieren • Gliederung skizzieren • Bedienungskonzept skizzieren • Kernanforderungen sammeln • Kerninhalte sammeln Ziel ist, die Breite der Softwareoberfläche zuverlässig abzustecken. Mit der in der UI Inception aufgestellten UI Landkarte kann man sicherstellen, dass man im späteren Entwicklungsverlauf nicht durch das Entdecken neuer Länder überrascht wird.

User Interface Workbook

Seite 97 von 127

UI Elaboration (Ausarbeiten)

Anhand der UI Elaboration sind detaillierte quantitative Planungen und Messungen der Arbeitsumfänge beim Entwickeln der Anwendung möglich.

In der UI Elaboration liegt der Schwerpunkt auf dem Sammeln und dem Ordnen von Bestandteilen, aus denen sich das User Interface zusammensetzt (Ablaufstruktur, Kontrollelemente, Verhaltensregeln). • Sammeln und Ordnen • Gliedern und Strukturieren • Detaillieren der Struktur • Detaillieren der Dialogsicht Ziel ist, dass das Gefüge aus Dialogen mitsamt ihrer Anzeige- und Bedienelemente sowie die Arbeitsabläufe möglichst vollständig bekannt sind. Mit den aufgestellten Stücklisten kann man sicherstellen, dass in den Abläufen und Inhalten der Anwendung keine größeren Lücken offen bleiben.

User Interface Workbook

Seite 98 von 127

UI Construction (Zusammenbauen)

Anhand der UI Construction ist eine Absicherung und Bestätigung durch die Anwendervertreter / Fachabteilung möglich.

In der UI Construction liegt der Schwerpunkt auf dem Formen und Verknüpfen der User Interface-Bestandteile. Dazu gehört das Formulieren von Übergängen zwischen Dialogeinheiten und das Benennen der Bedingungen für diese Übergänge. • Formen und Verknüpfen • Detaillieren des Verhaltens • Detaillieren des Bedienungskonzepts Ziel ist, dass das UI für den Anwender anfassbar und erlebbar wird und anhand einer Simulation bestätigt werden kann. Mit den Dialogen und Dialogabfolgen kann man sicherstellen, dass die geforderten Verwendungsszenarien abgebildet werden.

User Interface Workbook

Seite 99 von 127

UI Transition (Einbauen)

Anhand der UI Transition ist eine Absicherung und Bestätigung durch die Programmierungsverantwortlichen / IT Abteilung möglich.

In der UI-Transition liegt der Schwerpunkt auf dem Verknüpfen des User Interface mit der Funktionalität und mit dem Datenkontext. Dazu gehört das Ausdetaillieren von Verhaltensbedingungen, Nebenpfaden, Ausnahmenbehandlung, Besonderheiten der Bedienung und der technischen Plattform. • Verwenden von Funktionen und Daten ausformulieren • Restriktionen ausformulieren • Varianz ausformulieren • Ausnahmen behandeln • Berücksichtigen technischer Besonderheiten Ziel ist das Erreichen der Umsetzungsreife in der Zielplattform. Mit den Schnittstellenbeschreibungen kann man sicherstellen, das die Features spezifikationsgemäß implementiert werden.

User Interface Workbook

Seite 100 von 127

Vorgehenskarte

UI Inception Modell

Wichtige Kriterien für einen Iterationsabschluss sind:

UI elaborieren *

þ þ þ

UI Elaboration Modell

UI konstruieren *

þ þ þ

UI Construction Modell

Definierte Umfänge sind erreicht Definierte Ausgangskriterien wurden erfüllt Definierte Eingangsbedingungen für die nächste Iteration liegen vor und können erfüllt werden Vorliegen von geforderten Modellteilen Vorliegen von Verknüpfungen zwischen Modellelementen Gleichmäßige Modellierungstiefe

Typische Tätigkeiten am Ende einer Iteration sind: UI transferieren *

Fertigstellungsgrad messen

UI Transition Modell

þ þ þ þ

Korrekturbedarf

Angeben aller geforderten Attribute pro Kontrollelement Angeben aller geforderten Attribute für jeden logischen Schritt Eintragen des Fertigstellungsgrads in die Modellelemente Absichern der Ergebnisse durch Begutachtung und Bestätigung seitens der Vertreter des Auftraggebers (einschließlich Anwendervertreter)

Die Phasen des UI Entwurfs haben definierte Voraussetzungen und messbare Fertigstellungsgrade. Durch den Abschluss einer UI Entwicklungsiteration wird der Meilenstein erreicht, an dem das UI Modell den für diese Iteration aufgestellten Kriterien genügen soll.

User Interface Workbook

Seite 101 von 127

Querbezug zu RUP (Rational Unified Process)

Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software, die seit 2002 Teil des IBM Konzerns ist. In der Terminologie von RUP entspricht die UI Entwicklung einer eigenen Disziplin. Die Intensitätskurve der Diszipli UI Entwicklung entspricht dabei in etwa der Summe der Workflows „Requirements“, „Analysis& Design“ und „Depyloyment“.

Das Bild zeigt, wie der gesamte Entwicklungsprozess in Phasen (Inception, Elaboration, Construction, Transition) unterteilt werden kann. In jeder Phase können pro Entwicklungsgebiet (Disziplines) mehrere Iterationen stattfinden. Der Kurvenverlauf zeigt die Intensität der Disziplinen im Projektverlauf.

User Interface Workbook

Seite 102 von 127

Verwenden von UI Entwicklungswerkzeugen Die Wahl der Methoden und Werkzeuge zur UI Entwicklung hängt ab von: • der Fachdomäne der zu entwickelnden Anwendung • dem Typ und Bedienungsparadigma des zu entwickelnden UI • von den Methoden, mit denen man das UI entwickelt • von den Menschen, die das UI entwickeln Allgemeine Anforderungen aus Entwicklersicht: • UI Bestandteile beschreiben • UI Bestandteile kennzeichnen • Entwicklungsstände vergleichen • Änderungen verwalten • Kollaborativ arbeiten • Entwicklungsstand veröffentlichen

Ein Werkzeug ist ein Hilfsmittel, um Gegenstände (Werkstücke im weitesten Sinne) zu manipulieren, im Gegensatz zur werkzeuglosen, rein manuellen Bearbeitung. Schon natürliche Gegenstände wie Steine oder Äste werden von Menschen und auch vielen Tieren als Werkzeuge verwendet. Die gezielte Werkzeugherstellung (z. B. Anspitzen eines Astes zur Verwendung als Spieß) beherrschen neben dem Menschen nur wenige Primaten. [Wikipedia] Klar definierte Anforderungen an Werkzeuge zur UI Entwicklung sind unabdingbar, um zu bewerten, was Spezifikations-, Implementierungs- und Testwerkzeuge können müssen, damit man mit ihnen User Interfaces entwickeln kann, z.B.: þ

þ þ

Vokabular zur Spezifikation von Ablaufstruktur, Bedienungselementen, Layout, Interaktionen sowie Kontextund Anforderungsbezügen der Benutzerschnittstelle. Dialogseiteneditor Möglichkeit, die UI Spezifikation stufenweise von der ersten Skizze zu einer Umsetzungsvorschrift zu detaillieren.

Kernanforderungen: • Flexible Handhabung des UI Modells, • Änderungsrobusheit, • Iteratives Vervollständigen des Modells

• Informationen auswerten

User Interface Workbook

Seite 103 von 127

Anforderungen an UI Methoden und Werkzeuge Unterstützen von Vergleichen zwischen Spezifikationsständen, z.B. Delta-Analyse, Wiederherstellen eines Spezifikationsstandes.

Unterstützen des gemeinsamen Arbeitens an der Entwicklung einer Benutzeroberfläche. þ þ þ

Möglichkeit, Bestandteile der UI Spezifikation auf jeder Gliederungsebene bezüglich Fertigstellungsgrad in der jeweiligen Phase und Review-Status im jeweiligen Fertigstellungsgrad zu kennzeichnen. Unterstützen der Änderungsverwaltung, z.B. Änderungen auf Grund von Änderungsanforderungen. • Nachvollziehen des Wegfalls von Spezifikationsteilen (deprecated-removed-reviewed-Kennzeichnung). • Nachvollziehen des Hinzufügens von Spezifikationsteilen (added-to-Bezug). • Nachvollziehen des Ersetzens von Spezifikationsteilen durch andere (replaced-by-Bezug).

Aufteilbarkeit nach UI-Teilen (z.B. Modul, Screens, Variantenzuschnitt). Aufteilbarkeit nach Informationssegmenten (z.B. Kontext, Screens, Ablaufstruktur, Interaktionen). Aufteilbarkeit nach Fertigstellungsphase und Rolle (z.B. Rahmenspezifikateur, Detailspezifikateur, Realisierer, Tester).

Werkzeugunabhängige Zugreifbarkeit auf die spezifizierten Informationen als menschen- und als maschinenlesbare Datenstruktur (in Textform). þ þ

þ

Definiertes Informationsmodell Bereitstellung als Klartextdatei, die zum Informationsmodell konform ist (z.B. im projektspezifischen DSL-Format). Kapselung von werkzeugabhängigen [fachlichen] Informationen der Spezifikation und von technischen Implementierungsrestriktionen.

Unterstützen von verschiedenen Sichten auf die spezifizierten Inhalte (auf Basis der werkzeugunabhängigen Zugreifbarkeit) þ þ þ þ þ

Auswertungen Umformungen Simulation Generieren von Steuerungsdaten Generieren von Programmcode

mit wahlfreien Analyse- und Bearbeitungswerkzeugen.

Lösungsmuster für Standardphänomene der UI Entwicklung

User Interface Workbook

Seite 104 von 127

Standardphänomene beim Spezifizieren von User Interfaces Fragestellung: Wie werden bestimmte, in der Praxis oft auftretende Sachverhalte mit dem verwendeten UI Werkzeug spezifiziert.

Bei der Entwicklung von UIs treten verschiedene Standardprobleme auf (z.B. Modellieren von Variantenabhängigkeit). UI Beschreibungsformen sollten in der Lage sein, diese Standardprobleme zu lösen.

Typische Stolpersteine beim Spezifizieren eines UI betreffen in erster Linie: • das Formulieren der Ablauflogik • das Wiederverwenden von Festlegungen • das Bezugnehmen auf Steuerungsdaten • das Formulieren der Varianz (länder-, einstellungs- und situationsspezifische Anpassung des Verhaltens und des Erscheinungsbilds der Oberfläche) • Transaktionsverarbeitung • Rückkopplung der Kontrollelemente • Benutzerkollaboration Bei der Bewertung von UI Spezifikationsmethoden und Werkzeugen sollten diese Kriterien eine wichtige Rolle spielen, da sie im Verlauf des Projekt entscheidend für den Einsatzerfolg sein können.

User Interface Workbook

Seite 105 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (I) Formulieren der Ablauflogik • Wie gliedert man die Abläufe? Wie grenzt man die Ablaufschritte voneinander ab? • Wie identifiziert und kennzeichnet man kanonische Sequenzen, Ablaufalternativen und parallele Abläufe? • Wie identifiziert und kennzeichnet man im Ablauf Haupt- und Nebenpfade? • Wie integriert man die Fehler- und die Ausnahmenbehandlung in die Ablaufdefinition? Wieder verwenden und vererben • Wie kann man Dialogelemente, Dialogseiten und Ablaufmechanismen als wieder verwendbare Bausteine verwenden? • Wie parametrisiert man Positions- und Breite/Höhe-Angaben? • Wie formuliert man Gemeinsamkeiten und Unterschiede zwischen dem Muster und seiner spezialisierten Wiederverwendung („same-butdifferent-problem“)? • Wie vererbt man Festlegungen quer durch das UI Modell (z.B. Hintergrundfarbe, Systemmeldungen, Positionsangaben)?

User Interface Workbook

Kontextabhängige Präsentationslogik • Modellieren von Anzeige- und Navigation für Massendaten (z.B. umfangreiche Listen, Kataloge und Verzeichnisse) • Auswerten von komplexen Systemsituationen am UI Transitionen definieren • Formulieren von situationsabhängigen impliziten (z.B. Weiter-Button) und expliziten Übergängen (z.B. Gehe-zuButton) zwischen Dialogseiten (Workflowkontrolle) und Controls (Fokuskontrolle). • Entscheidungstabellen- und Verzweigungsknotenabhängige Bedienungselemente (z.B.: Wie wird eine mehrstufige Auswahl spezifiziert?).

Seite 106 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (II) Transaktionsverarbeitung • Transaktionseingabedaten erstrecken sich über mehrere Dialogseiten. Die Eingabedaten müssen über eine Sequenz von Dialogseiten hinweg überprüft werden. Es müssen Berichtigungsanweisungen für die Eingaben ausgegeben werden. Ggf. soll der Anwender im UI zu den zu berichtigenden Stellen automatisch hinnavigiert werden. Einzelaktionsverarbeitung/Rückkopplung • Einzelne Aktionen in der Benutzeroberfläche sollen sofort verarbeitet werden, und an der Oberfläche soll eine Reaktion sichtbar sein. Das direkt manipulierte oder über eine Eigenschaftenliste (Properties) oder über Kontrollelemente indirekt manipulierte Objekt soll sofort Veränderungen anzeigen.

Lokalisieren • Parametrisierbares Anpassen von Texten, Grafiken, Tönen, Formaten an lokale Begebenheiten (z.B. Länderund Spracheinstellungen, Skinning). • Anpassen der Menüs, Dialogseiten und Abläufe an Konfigurationen (z.B. keine Funktionen anzeigen, die in dieser Konfiguration oder von dieser Benutzerrolle nicht ausgeführt werden können).

Benutzerkollaboration • Mehrere Anwender bearbeiten z.B. einen gemeinsamen Text oder an einem gemeinsamen Verwaltungsvorgang. Situationsabhängige Notifikationen sollen sicherstellen, dass die Anwender wissen, was jeweils der Andere tut. Einige Dialoge können nur lesend abgerufen werden, solange sie von einem anderen Anwender bearbeitet werden (Temporäres Locking).

User Interface Workbook

Seite 107 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (III)

Bewertungskriterien für eine UI Entwicklungsumgebung sind: þ þ þ þ þ þ

Vollständigkeit: Abdeckungsgrad der UI-Domäne Fachlichkeit: Nähe der Repräsentation zur UI-Domäne Sichtbarkeit: Kapselungsgrad von Informationen Geringe Vorabverpflichtung: Grad der Provisionalität (Vorläufigkeit) der Definitionen Klarheit: Umfang, Erkennbarkeit und Lesbarkeit der Konstrukte Geringe Zähigkeit: Leichtigkeit einer Änderung der UI Beschreibung

Eine UI Entwicklungsumgebung besteht aus Spezifikationsform, Methodik, Erfassungssystem und Unterstützungswerkzeugen. In die Bewertung fließt ein, wie diese Instrumente zusammenarbeiten.

User Interface Workbook

Seite 108 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (IV) Vollständigkeit: Abdeckungsgrad des UI Infomodells • Ein Informationsmodell für das Entwickeln von User Interfaces stellt den Rahmen für das Wissensmanagement von Informationen und Beziehungen, die zum Bau eines UI dienen. • Die Notation zur UI Modellierung ermöglicht es, dieses Modell mit Inhalten zu befüllen. Je höher der Abdeckungsgrad des Infomodells, desto vollständiger lässt sich mit der Notation ein UI (einschließlich der Verwaltung der Beschreibung selbst, z.B. Varianten, Spezifikationsstände, Änderungen) beschreiben. • Siehe auch: Standardphänomene beim Spezifizieren eines UI Fachlichkeit: Nähe zur Fachsprache der Anwender • Ist die Notation nahe an der Sprache, die zu Fachgesprächen zwischen Anwendern, Spezifizierern und Entwicklern verwendet wird, dann lässt sich das UI in ihr leicht formulieren und das Formulierte leicht lesen. • Fachlichkeit bedeutet, dass UI Elemente und ihr Verhalten durch ein Vokabular beschrieben werden, das nahe an dem aus Sicht der UI Bedienung durch den Anwender verwendeten Vokabular liegt.

User Interface Workbook

Sichtbarkeit: Möglichst einfache Struktur • Ein UI Entwicklungswerkzeug, das Informationen kapselt und vielfach verpackt, reduziert die Sichtbarkeit von UI Definitionen. • Beim Pflegen von UI Details, z.B. bei Anzeigetexten, ist eine hohe Sichtbarkeit erforderlich. • Eine geringe Sichtbarkeit ist, wenn die Eigenschaften z.B. in einem geschachtelten Propertybaum stecken, in dem man durch Aufklappen nach der Stelle suchen muss, in der eine bestimmte Eigenschaft definiert ist.

Seite 109 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (V) Freiheit von Vorabverpflichtung: Toleranz von Spezifikationsauslassungen • Vorabverpflichtung passiert, wenn man frühzeitig gezwungen wird, Dinge festzulegen, die eigentlich erst später entschieden werden sollen oder können. • Beispiele: Id‘s für Elemente festlegen müssen, die vielleicht gar nicht referenziert werden. Für eine Auswahlliste sofort festlegen, ob sie über eine Drop-Down-Liste oder über eine Menütafel realisiert wird. • Provisionalität erlaubt unvollständiges Spezifizieren, StandardAnnahmen zu unspezifizierten Inhalten und spätere Konkretisierung, wenn nötig. Klarheit: Möglichst knappe, leicht voneinander zu unterscheidende Formen • Neigt eine Notation zu verschiedenen Beschreibungskonstrukten für eine und die gleiche Sache, nimmt sie auf dem Bildschirm unverhältnismäßig viel Platz für einfache Informationen in Anspruch oder benutzt sie lange, umständliche und leicht zu verwechselnde Konstrukte, dann hat sie eine hohe Diffusität. Es heißt nichts anderes, als dass die eigentliche Information in der Beschreibung verstreut ist.

Geringe Zähigkeit: Die Spezifikation soll schnell und einfach zu ändern sein. • Eine viskoses UI Werkzeug bzw. Notation bedarf vieler Anwenderaktionen, um ein Ziel zu erreichen. • Zum Beispiel kann das Ändern aller Step-Namen einer Ablaufstruktur von Groß- in Kleinschreibung das Anfassen eines jeden Steps bedeuten. • Editierumgebungen, die passende Abstraktionen (zum Beispiel Suchen und Ersetzen in allen Step-Namen) bereitstellen, können Viskosität senken.

• Hohe Diffusität führt zu schlechter Formulier- und Lesbarkeit der Notation und erhöht damit den Kommunikationsaufwand der am UIEntwurf und Design beteiligten Rollen. User Interface Workbook

Seite 110 von 127

Checkliste zum Bewerten von UI Entwicklungswerkzeugen (VI)

Pro Bewertungskriterium sind 0 Punkte (schlechteste Bewertung) bis max. 10 Punkte (beste Bewertung) möglich. Note 1: 51-60 Punkte

Beispiel: Bewertungsvergleich von Entwicklungsumgebungen

Note 2: 41-50 Punkte

Beispiel für die Anwendung des Bewertungsschemas

Note 4: 26-30 Punkte

Note 3: 31-40 Punkte Note 5: 21-25 Punkte Note 6: 0-20 Punkte Im Beispiel: Flash MX ist für das Entwickeln von UIs als befriedigend einzustufen, C++ mit MFC hingegen nur als ausreichend mit Tendenz zu mangelhaft.

Übung: Wenden Sie das Bewertungsschema auf eine Ihnen wohlbekannte Entwicklungsumgebung, z.B. wxPython, Expression Blend oder Java AWT. Begründen Sie Ihre jeweilige Bewertung. Zeit 15 Minuten.

User Interface Workbook

Seite 111 von 127

Fragen zu #07

1. Woraus besteht eine UI orientierte Softwarearchitektur? þ þ þ

Antworten zu #07 1: c) 2: a), b) und c) 3: Modellmanager – hält die UI Beschreibung und die Laufzeitinformationen über den Zustand der UI-Bestandteile bereit, Kontexthandler – ruft die vom UI benötigten Daten und Operationen aus der funktionalen Schicht ab; legt veränderte Daten ab; Screenmaschine – erzeugt Dialogseiten aus den im Modellmanager bereitgehaltenen Dialogseitendefinitionen; Eventmaschine – ordnet Input-Ereignissen der UI Controls die im Modellmanager bereitgehaltenen Interaktionen zu; Ablaufmaschine – führt Interaktionen durch und vollzieht Statusübergänge im Laufzeitmodell

User Interface Workbook

a). Systemarchitektur + Softwarearchitektur b). Prozessarchitektur + Systemarchitektur c) Softwarearchitektur + Informationsarchitektur + Prozessarchitektur

2. Identifizieren Sie drei Ziele der UI orientierten Softwarearchitektur þ þ þ þ

a). Flexibler Dialogfluss, b). Implementierungsunabhängige Dialogseitenbeschreibung, c). Änderungsrobuste Applikation d). Optimale Ausnutzung der grafischen Möglichkeiten der Zielplatform

3. Zählen Sie die typischen Softwarekomponenten einer UI orientierten Architektur auf und erklären Sie kurz ihre Funktion.

Seite 112 von 127

#08

Neue Vorgehensweisen etablieren Lenrziele: Kenntns des Rollen und Aufgaben Vorgehen beim Einführen der UI orientierten Entwicklung

Softwareprojekte entstehen in Teamarbeit von Spezialisten, die unterschiedliche Rollen, Ausbildungen und Ziele haben. Beim Einführen neuer Vorgehensweisen muss das Gleichgewicht zwischen den beteiligten Personen erhalten bleiben.

User Interface Workbook

Seite 113 von 127

Verschiedene Rollen beim Entwickeln einer Anwendung User Interfaces von Anwendungsprogrammen entstehen in SoftwareProjekten. Daran sind verschiedene Stakeholder beteiligt.

Stakeholderrollen, die am entstehen einer dialogintensiven Anwendungssoftware beteiligt sind: Softwareentwickler þ þ þ

Konzept-Entwickler / Spezifikateure Anwendungs-Programmierer System-Programmierer

Architekten þ þ þ

Informationsarchitekten Softwarearchitekten Systemarchitekten

Requirement Engineers þ

Analytiker / Spezifikateure

Weitere beteiligte Personengruppen sind: þ þ þ þ þ

User Interface Workbook

Projektleiter Anforderungssteller (z.B. Anwendervertreter und Fachexperten) Qualitätssicherer und -prüfer Grafik-Designer Usability-Engineers

Seite 114 von 127

Rollenspezifische Aufgaben an der UI Spezifikation

Das Entwicklerteam (Programmierer, Spezifizierer, Architekt) folgt bei der Entwicklung der Oberfläche den von den Anwendervertretern festgelegten Rahmenbedingungen. Der Architekt legt die technischen Rahmenbedingungen der Entwicklung fest.

legt fachliche AnwenderRahmenbedingungen vertreter fest, prüft, bestätigt

kommuniziert

User Interface Spezifikation interpretiert, detailliert Programmierer

Der Spezifikateur analysiert die Anforderungen und modelliert die daraus abgeleiteten Features. Der Programmierer intepretiert die Konzepte und ergänzt sie ggf. um technische Details. Der Projektleiter legt die organisatorischen Rahmenbedingungen der Entwicklung fest und kommuniziert die Arbeitsergebnisse an die Projektgremien. Der Fortschritt der Arbeit an der UI Spezifikation kann am Erfüllungsgrad der Anwenderforderungen gemessen werden.

Projektleiter analysiert, modelliert legt technische Rahmenbedingungen fest

Spezifizierer

Architekt

Entwickler

User Interface Workbook

Seite 115 von 127

Use Cases des Bedienkonzept-Entwicklers

Bedienkonzeptentwickler entwickeln Grundregeln für die Handhabung der Software (Bedienungsmetaphern). Hierzu gehören z.B. die Usability, das UI-Styleguide und Regeln für die Anpassbarkeit der Benutzeroberfläche zur Konfigurationszeit und zur Laufzeit.

Bedienkonzeptentwickler

Design Styleguide

Layoutregeln

beinhaltet

Anzeige- und Bedienkonzept entwickeln

Interaktionsmuster Usability Funktionale Adaptivität

Erscheinungsbildadaptivität

Adaptivität Personalisierung

Benutzereinstellungen

User Interface Workbook

Benutzergewohnheiten

Seite 116 von 127

Use Cases des Erscheinungsbild-Entwicklers

unterstützt

Grafiker

unterstützt

Erscheinungsbildentwickler

Erscheinungsbild entwickeln

Erscheinungsbildentwickler entwickeln, wie die Software aussieht und/oder sich anhör / anfühlt.

Die Ein- und Ausgabe kann gleichzeitig über GUI und Sprachkanal erfolgen

Hierzu gehört z.B. das Grafikdesign oder allgemein gesagt das „Look and Feel“ der Software.

Sprachdialogenwickler

Kontrollemente gestalten

Beispiellayouts entwickeln

Kontrollemente parametrisieren

Parametrisierte Kontrollemente einsetzen Layoutalgorithmen entwickeln

User Interface Workbook

Seite 117 von 127

Use Cases des Anwendungs-Programmierers

Anwendungsentwickler

Anwendungsentwickler setzen das UI um. Hierzu gehört z.B. die Anbindung der UI-Logik an die interne Anwendungslogik und an den Datenhaushalt der Anwendung.

vertikaler Durchstich Prototypen

UI umsetzen Kontrollemente anbinden Widgetlibrary pflegen

User Interface Workbook

z.B. systemgetriggerte Controls

Daten- und Funktionszugriff anbinden

Seite 118 von 127

Use Cases des Testers

Tester prüfen die Übereinstimmung von UI Implementierung und UI Spezifikation. Hierzu gehört z.B. das Nachvollziehen einzelner Interaktionen, aber auch das Vergleichen von Bildschirmen mit Entwürfen.

Tester Screenshots vergleichen UI testen

Texte vergleichen

beinhaltet

formale Tests

Konsistenz

Verhalten prüfen Widerspruchsfreiheit Funktionen prüfen

User Interface Workbook

Abläufe prüfen

Seite 119 von 127

Use Cases der Methodenentwickler

Methodenentwickler pflegen die Systematik der UI Beschreibung. Hierzu gehören z.B. Erfassungsschablonen (Templates) und Validierungsautomaten (Checker) für Ablauf-, Konditionierungsund Dialogseitenbeschreibungen sowie strukturelle Vergleiche zwischen aufeinander folgenden Spezifikationsständen.

Methodenentwickler

Spezifikationsstrukturen bereitstellen Varianten

Strukturierung Kontext Dialog

Situationen Interaktionen

Inhalte Logische Elemente

Anordnung

User Interface Workbook

Seite 120 von 127

Vergleich von UI orientiertem und funktionsorientiertem Vorgehen Vorgehen ist an der technischen Funktion der Software orientiert

Vorgehen ist an der fachlichen Verwendung orientiert

1: Zielsetzung und Randbedingungen ermitteln

1: Anwendungsszenarien und Systemgrenzen abstecken

2: Use Cases im technischen Kontext ermitteln

2: Dialogabfolge im Kontext der Verwendung ermitteln

3: Hauptabläufe bestimmen

3: Schlüsselfelder der Dialoge bestimmen

4: Iterative Detaillierung der Use Cases und der Abläufe; Ausnahmen

4: Iterative Detaillierung des User Interface; Nebenpfade

5a: Fertigstellen und Abnahme des Fachkonzepts

5a: Fertigstellen und Test der UIBedienung; Bestätigung des UI

5b: Entwürfe für Bildschirmmasken fertig stellen

5b: Funktionsmodelle fertig stellen

6: Implementierung und Test der Software

6: Implementierung und Test der Funktionen

7: Nachbesserungen und Change Requests

7: Komfortverbesserungen und Erweiterungen

User Interface Workbook

Beispiel: Unterschiede zwischen UI Orientierung und dem herkömmlichen Entwicklungsvorgehen. Die Unterschiede der User Interface-orientierten Vorgehensweise zur herkömmlichen Softwareentwicklung sind: þ þ þ

þ

Im UI orientierten Ansatz entwickeln die Entwickler das User Interface als eigenes Artefakt. Im technisch-funktional orientierten Ansatz wird das UI nicht als eigenes Artefakt verstanden. Im technisch-funktional orientierten Ansatz werden UI Anforderungen nachrangig zu den funktionalen Anforderungen erhoben. Im UI orientierten Ansatz werden die funktionalen Anforderungen aus den UI Anforderungen heraus entwickelt.

Seite 121 von 127

Checkliste für UI orientiertes Vorgehen (I) UI orientiertes Vorgehen heißt: • UI Entwurf als eigenständiges Artefakt im Entwicklungsprozess aufstellen. • Informationsschnittstelle zwischen UI Entwurf und funktionalen Entwürfen festlegen. • Regelmäßigen Abgleich zwischen UI Entwurf und Funktionsmodellen etablieren.

Die Entwicklung der Oberfläche sollte im Entwicklungsprozess als ein eigener, zur Funktionsentwicklung paralleler Entwicklungsbereich angesiedelt und etabliert werden. Es ist die Aufgabe des Projektleiters, die für das UI Verantwortung tragenden Personen zu stärken und die Mitwirkung anderer Rollen am UI-Entwurf einzufordern. In einem Projekthandbuch sollte klar festgelegt sein, wer was zum UI beitragen muss und woran die Qualität dieser Beiträge gemessen wird. UI-Modelle zeigen Zielkonflikte aufUI-Modellierung ist ein Querschnittsthema. Sie vernetzt und verbindet Verantwortungsbereiche und kann deshalb Zielkonflikte offen legen, z.B. zwischen Datenmodellierern und den Befürwortern einer detaillierten Historie aller Eingaben im UI. Der Projektleiter muss deshalb Kommunikationsprozesse fördern und eine Instanz für die laufende Beilegung der aufgedeckten Widersprüche und Zielkonflikte stellen.

• Rollenkompetenz definieren und einhalten. • Zielkonflikte identifizieren und auflösen. • Checklisten für Erreichen von Fertigstellungsgraden des UI Entwurfs verwenden.

User Interface Workbook

Seite 122 von 127

Checkliste für UI orientiertes Vorgehen (II) Gründe fürs ÄM þ

UI orientiert entwickeln heißt:

þ þ

Nachvollziehen der Unterschiede zwischen ursprünglicher Planung und Umsetzung Abstimmung zwischen den Entwicklern an den Schnittstellen zwischen den Produktkomponenten ÄM ist Bestandteil des SE-Prozesses

• Die Verwendung der Software durch den Anwender steht im Vordergrund der Entwicklerüberlegungen • Anwendungsfälle und Abläufe aus Sicht des Anwenders sind Planungs- und Testgrundlage (nicht die Komponenten aber für die Abnahmetests) • Die Architektur ist möglichst so beschaffen, dass Änderungen an Dialogseiten und Dialogabläufen schnell und mit wenig Aufwand (single point of definition) machbar sind.

User Interface Workbook

Seite 123 von 127

Strategie der UI orientierten Anforderungsanalyse • Das UI gehört dem User, nicht dem Entwickler • Nehmen Sie es nicht „in Besitz“ • Zuhören ohne zu bewerten

Verhindern Sie als Analytiker Beschreibungen und Diskussionen über das Verwenden von Oberflächeneigenschaften und über technische Umsetzungswünsche nicht, sondern verknüpfen Sie Verwendungsinformationen mit funktionalen Anforderungen. Im Beispiel des Tisches wäre z.B. die Anzahl der Beine, die Form, die Oberflächenbeschichtung, die Höhen- und Neigungsverstellbarkeit aus der Art der Nutzung des Möbels ableitbar.

• Verstehen ohne zu belehren • Bausteine hinzufügen, ohne das Gebäude zu beeinträchtigen • Vorschlagen ohne zu erwarten • Vorstellungen der Fachexperten wachsen lassen ohne zu beschneiden Gemeinsam mit Anwendervertretern lassen sich die gewünschten UI Eigenschaften leichter mit den technischen und projektpolitischen Restriktionen in Einklang bringen, als gegen sie.

User Interface Workbook

Seite 124 von 127

Best Practices auf Nutzen und Wirksamkeit evaluieren

Der Begriff „Best Practice“ (wörtlich „bestes Verfahren“, freier „Erfolgsrezept“), auch Erfolgsmethode genannt, stammt aus der amerikanischen Betriebswirtschaft. Wenn ein Unternehmen nach best practice vorgeht, setzt es bewährte und kostengünstige Verfahren, technische Systeme und Geschäftsprozesse ein, die es zumindest auf wesentlichen Arbeitsfeldern zum Musterbetrieb für andere machen. Diese Aussage ist erst nach einem Benchmarking möglich, wenn sich mehrere vergleichbare Unternehmen ausgetauscht haben, um den oder die Besten dieser Gruppe herauszufinden.

Übung: Best Practice oder nicht? Zeit: 5 Minuten þ þ

Bei Anforderungen soll nur das „was“ aber nicht das „wie“ analysiert werden. Die Anwendungsoberfläche wird einmal spezifiziert und dann so umgesetzt.

Nehmen Sie Stellung zu den obigen Thesen. Begründen Sie Ihre Antworten.

Kritik an Best Practices: Nur weil es so heißt und schon mal so gemacht wurde, ist es nicht automatisch die beste Vorgehensweise. Um als bestes Verfahren zu gelten, müssen Entwicklungsmethoden im Team erprobt, bewertet, abgestimmt und institutionalisiert werden.

User Interface Workbook

Seite 125 von 127

Fragen zu #08

1. Welche Entwicklungstätigkeiten fallen beim UI an?

Antworten zu #08 1: a), b) und c) 2. a), b) und c) 3: b)

þ þ þ

a). Dialogseiten erstellen b). Logische Operationen definieren c). Datenstrukturen entwerfen und verwenden

2. Identifizieren Sie Kernanforderungen an ein UI Werkzeug þ Flexible Handhabung des UI Modells, þ Änderungsrobusheit þ Iteratives Vervollständigen þ Große Auswahl an vordefinierten Controls þ State Chart Editor

3. Wann ist eine UI Beschreibung fertig? þ þ þ

User Interface Workbook

a). Wenn alle statischen und dynamischen Eigenschaften vollständig beschrieben sind. b). Wenn die Anwendervertreter, Spezifikateure und Entwickler dies einvernehmlich feststellen c). Am Ende der Implementierung: UI Beschreibung kann erst erstellt werden, wenn alle Funktionen feststehen.

Seite 126 von 127

Links und Literaturhinweise Mario Auer: Aus der Lehre … Psychologische Begriffsbestimmungen 2006 – Interaktion http://www.stangl.eu/psychologie/definition/Interaktion.shtml Helmut Balzert: Lehrbuch der Software-Technik. Spektrum Akademischer Verlag, 2001, ISBN 3-8274-0301-4 Paul Chlebek, User Interface-orientierte Softwarearchitektur, ISBN 978-3-8348-0162-3 Vieweg Verlag 2006 http://www.vieweg.de/freebook/978-3-8348-0162-3_i.pdf http://www.vieweg.de/freebook/978-3-8348-0162-3_v.pdf http://www.vieweg.de/freebook/978-3-8348-0162-3_l.pdf Marcus Dormanns, Vorlesung E-Business Systemarchitekturen, TU Berlin, WS 2001/2 http://kbs.cs.tu-berlin.de/ teaching/ ws2001/ebusiness/folien4fach/012_Vorgehensmodelle.pdf Mensch-Computer-Interaktion: http://www.eickel.in.tum.de/ lehre/ Seminare/ UeberFachGrund/ WS99/ vortrag01/ Zusammenfassung.html http://beat.doebe.li/ bibliothek/ w00273.html Joachim Schuhmacher, Usability, http://controlling21.de/ ergonomie/ theorie/ grundlagen/ usability.htm Skripte im Web: http://www.benutzeroberflaeche.de/Papers/2007uiarchitektur-seminar.pdf, http://www.benutzeroberflaeche.de/ Papers/ BAT2008-workbook-user-interfaces.pdf

** Ende des Dokuments **

User Interface Workbook

Seite 127 von 127