Praktikum (3) – Erste Schlussfolgerungen

Last updated on 11. November 2014

Nachdem ich mich nun in die Thematik eingelesen habe, möchte ich aus meinem erworbenen Wissen einige Schlussfolgerungen in Bezug auf mein Thema ziehen. Dabei will ich nochmals meine Motivation ins Gedächtnis rücken und meine ersten Ideen dazu niederschreiben.

Motivations-Erinnerung

Die zentrale Frage, die mich im verganenen und in den kommenden Monaten beschäftigt ist:

„Wie komme ich von einer Aufgabe zur GUI?“

Dabei soll quasi ein Zwischenstück zwischen der Aufgabenanalyse und dem Optimierungsprozess von GUIs gefunden werden. Dieses soll Entwicklern einen Plan liefern, wie er vorgehen muss, um eine entsprechende Oberfläche aus einer Aufgabe heraus zu entwickeln. Die GUI soll also nicht modellgetrieben entwickelt werden.

Überlegungen, Schlussfolgerungen und Ideen

Überlegungen

Wenn Entwickler ohne einen Plan an die Entwicklung einer Oberfläche heran gehen, so betrachten sie das meist recht einseitig aus Datensicht. Das heißt, welche Daten will ich von meinem Nutzer bekommen, damit ich diese persistieren und verarbeiten kann? Dabei bleibt aber die Betrachtung des Ablaufs der Aktivitäten außen vor. Es wäre dementsprechend wichtig, sowohl eine Sicht auf die Daten als auch auf die Prozesse zu haben, die bei einer Aufgabe eine Rolle spielen.

Schlussfolgerungen

Ausgehend von einer Aufgabe müssten also folgende Dinge betrachtet werden:

• WER will die Oberfläche benutzen? –> Nutzerprofilerstellung
• WAS will der Nutzer auf der Oberfläche erreichen? –> Zieldefinition
• WOMIT will er seine Ziele erreichen? –> Datenhandling
• WIE will er diese Ziele erreichen? –> Ablaufkoordination

Weiterhin ergeben sich noch ein paar weitere Fragen an die Gestaltung der Oberfläche:

• Wie gestalte ich die Oberfläche ergonomisch und gebrauchstauglich?
• Wie verhalten sich die Daten vor und nach einer Aktivität?
• Welche Auswirkungen haben diese Veränderungen der Daten auf die Nutzeroberfläche?
• Wie erleichtere ich dem Nutzer die Arbeit mit der Oberfläche?
• Gibt es Adaptionen oder Metaphern aus der analogen Welt, die dafür zum Einsatz kommen können?

Eine weitere Frage, die den Prozess der Oberflächenentwicklung in dieser Form zudem unterstütz, ist mir noch in den Sinn gekommen:

Was sind charakteristische Merkmale einer Aufgabe/Aufgabenbeschreibung, die zur Identifizierung von Elementen für Benutzeroberflächen dienen?

Ideen

Eine grobe Idee, wie man die Fragen beantworten könnte, habe ich inzwischen auch bekommen. Inwiefern sie sich als brauchbar erweist, muss an einem kleinen Beispiel getestet werden. Zunächst möchte ich meine Ideen aber erst ein Mal berichten:

„WER“ das System später nutzt muss klar sein: Ist es der Kunde selbst und/oder eine andere Nutzergruppe? Dazu dient die Erstellung eines Nutzerprofils inklusive Foto, Interessen, Arbeitsweise, etc. Außerdem sollte man klar stellen, ob die Nutzer Anfänger, Fortgeschrittene oder Experten sind und ob der Übergang in die höheren Stufen möglich ist. Das „WAS“, also die Zieldefinition, wäre denkbar, mit einem Aktivitätsdiagramm darzustellen. Darin enthalten ist, was der Nutzer in der betrachteten Aufgabe eigentlich machen und erreichen möchte. Alternativ könnte man auch auch ein Workflow-Diagramm aufstellen. Ausgehend von diesem Aktivitätsdiagramm könnte man nun die Frage des „WOMIT“ klären, indem man die entsprechenden Stellen mit den Daten verknüpft, die über den Nutzer manipuliert werden sollen. Hierfür würde sich der Einsatz von unterschiedlich detaillierten Screendiagrammen eigenen. Anschließend daran kann man, am Diagramm orientiert, diese verknüpften Daten in eine sinnvolle Reihenfolge bringen und somit den Ablauf koordinieren („WIE“). Dafür kann man eine Navigationsübersicht erstellen.

Während des Entwickelns sollte man sich immer wieder vor Augen führen, welches Ziel der Nutzer erreichen möchte. Dafür kann das erstellte Nutzerprofil zum Einsatz kommen. Man sollte hinterfragen, ob das was auf dem entworfenen Screen sichtbar ist, auch wirklich zielführend ist.

Für die daraus resultierende Erstellung der Wireframes und Prototypen sollte man sich an meherern alternativen Varianten versuchen, damit der Kunde bei einem zeitigen Vorführen des Entwurfes feststellen kann, welches der Designs näher an seine Ansprüche heran kommt.

Bezüglich der charakteristischen Merkmale einer Aufgabe/Aufgabenbeschreibung bin ich auch zu ersten Ideen gekommen, die ich wieder in Fragestellungen formulieren möchte, die man an die Aufgabe stellen kann:

• Welche Daten sollen ein- und ausgegeben werden?
• In welcher Reihenfolge sollen die Datein verarbeitet werden?
• Aus wie vielen Schritten besteht eine Aufgabe?
• Welche Dinge können gruppiert werden?