Freitag, 13. Februar 2015

Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post dieser Reihe sind wir in die Designphase eingetreten. Diese beginnt bei [GARRATT12] mit der Strukturebene, welche sich mit dem Interaktionsdesign und der Informationsarchitektur beschäftigt. Zu Beginn haben wir im letzten Teil ein konzeptionelles Modell in Form eines UND-ODER-Baumes erstellt. Es ist Bestandteil des Interaktionsdesigns und dient der Betrachtung von Erwartungshaltungen der Benutzer an die Interaktionskomponenten unserer Benutzeroberfläche bis hin zum Umgang mit Fehlern. Eine wichtige Rolle spielt wie immer der Benutzer, der später mit der Software arbeiten soll. Diese herausragende Rolle hat er auch bei der Entwicklung der Informationsarchitektur. In dieser Architektur erstellen wir ein Ordnungsprinzip für Informationen, so dass diese verständlich, einfach zu finden und gut zu nutzen sind.

Sind die Informationen, die wir anbieten einfach zu erfassen oder hat der Benutzer schon nach einigen Minuten einen Knoten in seinem Kopf und sucht fragend nach Hilfequellen? Öffnet er dann die Hilfe und dasselbe Informationschaos stürzt auf ihn herein, ist die Software für ihn gestorben. Wieder ein Produkt, dass nur mit vermeintlich hoher Intelligenz zu bedienen ist. Leider hat dieses Kuddelmuddel nichts mit Intelligenz zu tun, sondern eher mit schnell zusammen gestrickter Software. Einfach zu bedienende Software mit klaren Strukturen braucht Zeit, Zeit für Abstraktionen, Zeit für Konzepte und Zeit für und mit dem Kunden.

Die Inhalte unserer Software benötigen Struktur. Folgende Aufgabenverteilung in einigen Softwarefirmen ist Realität: Also mach mal das und das. Du wirst schon sehen in welches Menü das rein passt und wie das am besten umzusetzen ist. Der betreffende Entwickler bekommt nie einen Kunden zu Gesicht. Manchmal aber auch erst, wenn es zu spät ist und der Kunde sich über den Unsinn beschwert, der nie abgesprochen war. Ein anderer Weg ist, über die neuen Inhalt im Team und mit dem Kunden nachzudenken. Beide Seiten benötigen die Einsicht in diesen wichtigen Prozess. Ist man gemeinsam in der Lage zu erkennen, wie wichtig Kommunikation, Abstraktion und Nachdenken ist, verwendet man die Hälfte der Zeit, die sonst später für aufwendige Korrekturen und Fehlerbehebungen benötigt werden.

Inhalt können wir von oben nach unten (top-down) und von unten nach oben (bottom-up) strukturieren. In der Methode von oben verfeinern wir unseren Inhalt. In der Methode von unten fügen wir Inhalte zu Generalisierungen zusammen. Dabei finden wir Funktionskategorien, die wir zu fachlichen Modulen zusammenfassen können. Im Artikel Ordnung für Use Cases und User Stories durch Funktionsgruppen. beschreibe ich, wie wir anhand unserer Use Cases Funktionsgruppen bilden und mit diesen fachliche Komponenten bilden. Das ist ein Weg Inhalt von unten zu strukturieren. Dabei können wir auf den Ergebnissen des Requirements Engineering aufbauen. Verwenden Sie beide Ansätze. Stoßen Sie mit einem Ansatz an eine Denkgrenze, nehmen Sie den anderen Ansatz. Vor allem aber, machen Sie es nicht allein, nutzen Sie das Team und die Fachkompetenz des Kunden. Allein stößt man oft an unüberwindliche Grenzen, die es in gemeinsamer Arbeit gar nicht gibt.

Schon am Anfang eines Projekts muss man bedenken, dass das Produkt einmal wachsen könnte. Geben wir eine Struktur vor, die ein solches Wachstum verhindert? Im Kleinen lässt sich Unstrukturiertes noch beherrschen, mit der Zeit wird es ein Problem für vermeintliche Genies und am Ende wirft man es an die Wand. Es gibt eben Arbeitsschritte, deren Sinn erst sehr viel später sichtbar wird. Im Augenblick kann man durch das Weglassen solcher Schritte Zeit gewinnen, manchmal sogar viel Zeit, doch der Verlust in der Zukunft ist immens und übertrifft den Zeitgewinn um ein Vielfaches. Planungsprozesse haben oft mit der Vorstellungskraft zu tun, welche Aufwände müssen wir jetzt akzeptieren, damit wir Zeit über lange Zeiträume gewinnen. Jede Form der Architektur muss zukunftstauglich entwickelt werden. Eine solche Zukunftstauglichkeit kann nur entstehen, wenn die Erwartungen, Ansprüche, Ziele und Bedürfnisse der Stakeholder bekannt sind.

Bei der Anordnung der Struktur stehen uns mehrere Ordnungsansätze zur Verfügung. Wir haben z.B. Use Cases in Funktionsgruppen zusammengefasst. Im Folgenden Modell werden diese Funktionsgruppen als Knoten dargestellt. Oft werden die Knoten in einer hierarchischen Baumstruktur angeordnet.



Es gibt jedoch durchaus andere Anordnungsmethoden. [GARRETT12] erwähnt die Matrixstruktur. Die Knoten werden beispielsweise in einem dreidimensionalen Würfel angeordnet. Für die Anordnung von Funktionalität mag das erst einmal sehr ungewöhnlich erscheinen. Organische Strukturen gibt es da wahrscheinlich schon eher. Unsere Knoten sind in einem Graphen angeordnet. Die Knoten werden nach Bedarf miteinander verknüpft. Ein große Rolle spielen sequentielle Strukturen. Ein Knoten wird nach dem anderen angeordnet. Solche Strukturen treffen wir beispielsweise in Wizards an. Allgemein kann man sagen, dass innerhalb eines Programms mehrerer dieser Strukturen Anwendung finden können. In der Menüstruktur finden wir hierarchische Baumstrukturen, in den Seiten können wir uns über Links und Button durch einen Graphen klicken und in Wizards verwenden wir die sequentielle Struktur. Alle diese Strukturen müssen auf die Bedürfnisse des Kunden abgestimmt werden.


[Matrixstruktur]


[Organische Struktur]


[Sequentielle Struktur]

"Die Knoten in einer Informationsstruktur sind gemäß eines Organisationsprinzips angeordnet. Grundsätzlich bestimmt das Organisationsprinzip, welche Knoten gruppiert werden und welche nicht." [S. 96, GARRETT12] Was ist ein solches Organisationsprinzip? Wir können eine Anwendung z.B. in Bezug auf verschiedene Nutzer aufteilen (Administrator, Sachbearbeiter, Manager, …) oder in Bezug auf verschiedene Arbeitsschritte (Dateibehandlung, Bearbeitung, Formatieren, …). Oft werden innerhalb einer Anwendung mehrere Organisationsprinzipien zur Anwendung gebracht. Der Nutzer muss jedoch wissen, welches Organisationsprinzip gerade benutzt wird. Am Ende muss eine Struktur gelingen, in der sich Benutzer vom Allgemeinen zum Speziellen navigieren können, ohne den Überblick zu verlieren. Ein Zuviel an Information ist auf jeden Fall ein No-Go. Welches Organisationsprinzip verwendet der Benutzer? Welche Information sucht der Benutzer? Welche Arbeitsschritte will er ausführen? Was ist belastende Information? Welche Schritte sind zu viel? Womit kämpft der Benutzer?

Im ersten Wurf ein gutes User Interface zu entwickeln ist ein fast nie eintretender Zufallstreffer. Doch mit der Zeit kann man die Fragen beantworten, die Anwendung verbessern und sich einem guten Design und einer guten Usability mehr und mehr nähern. Eine weitere wichtige Angelegenheit in Bezug auf das User Interface ist die Verwendung einer verständlichen Sprache im Fachkontext. Erstellen Sie Glossars. Definieren Sie einheitliche Begriffe, die im Fachkontext üblich sind. In der Anwendung sollte der Benutzer auf keine Schwemme von Synonymen treffen. Zehn Begriffe, die alle dasselbe bedeuten, führen zu Verwirrung und stiften Unwohlsein. Allein deshalb ist eine Abstimmung Gold wert. In einem mehrsprachigen Kontext wird diese Thema um einiges schwieriger.

Am Schluss kommen wir wieder zur Dokumentation des erarbeiteten Wissens. Zeichnen Sie UML-Aktivitätsdiagramme für die Navigation durch Ihre Anwendung. Malen Sie mehrere Diagramme für verschiedene Organisationsprinzipien. So halten Sie die Ideen überschaubar. Informationen, die Sie nicht in diesen Diagrammen ablegen können, erläutern Sie in erklärenden Tabellen, so auch das Glossar.



In solche Diagrammen sieht man sehr schnell, ob eine Struktur unübersichtlich wird. Mit den entsprechenden Tools oder am Whiteboard kann man ebenfalls schnell zu besseren Anordnungen kommen. Die Navigationspfade sollten begründet werden. Auch solche Entscheidungen kann man dokumentieren.

  • [GARRETT12] : Jesse James Garrett: "Die Elemente der User Experience", Addison-Wesley Verlag, 2012


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen