# Usability Evaluation


# Cognitive Walkthrough 
Task Scenario: Einrichten eines Wasser-Widgets, umbenennen auf Tagesbedarf Pepsi, Trinken von 1.5 von 3 Litern
Optimal Steps:
- App Öffnen (Schon getan)
- Widget-Add-Button oben links drücken
- "Wasser-Widget Hinzufügen"-Button drücken
- Per druck auf Pfeil Nach unten beim Neu erstellten Widget aufklappen
- Per Druck auf Zahnrad in die Widget-Einstellungen gehen
- Ins Textfeld "Name des Widgets" "Tagesbedarf Pepsi" eintragen
- Tagesziel per Schieberegler auf 3L setzen
- Einstellungen Speichern
- 6 mal 250ml-Button drücken ODER "+ beliebig" Button drücken und 1500 eingeben und Speichern


# Heuristic Evaluation

### Visibility of System Status
Im eingeklappten Modus kann man schnell auf einen Blick für alle angelegten Widgets erkennen, wie weit diese Abgeschlossen sind. Auch im Dashboard ist das auf einen Blick im Graphen gut erkennbar dank Linie mit Zielwert und Jetzigem Wert in unterschiedlichen Farben.

### Match Between System & Real World
Neue Task Defaulten immer zum derzeitigen Datum. Timer laufen auch im Hintergrund weiter.

### User Control & Freedom
Es ist Möglich, beliebig viele Widgets anzulegen. Bei allen diesen Widgets lässt sich der Name und verschiedene Einstellungen individualisieren. Damit kann der Nutzer diese App für alle Möglichen Zwecke nutzen. Beispiel: Die Task-Liste kann eine Einkaufsliste, eine Plan-To-Watch-Liste oder an sonstige Dinge erinnern. Timer-Widgets können verschieden benannt werden und so beim Klavier üben, beim Arbeiten oder beim Meditieren Verwendet werden und hier Fortschritt tracken. Zudem lassen sich die Statistiken Wochen- oder Tagesweise darstellen und man kann sich vergangene Wochen ansehen.

### Consistency and Standards
Die App speichert alle Daten persistent ab. Sogar Aufgeklappte Widgets werden Gespeichert, was ein direktes Benutzen beim App-Start erlaubt.

### Error Prevention
An einigen Stellen werden User Errors vorgebeugt. Zum Beispiel kann man die Dauer eines Timers nur einstellen, wenn dieser Gestoppt ist. Numerische Eingabefelder haben zudem keine Angezeigten Buchstaben.

### Recognition rather than Recall
An keiner Stelle muss der Nutzer sich Werte merken, die er dann an einem anderen Screen braucht. Die Einstellungen der Widgets sind bei allen Widgets am selben Ort und passen auf eine Seite.

### Flexibility and Efficiency of Use
Die Widgets sind gut Customisable und damit flexibel zu benutzen.

### Aestetic and Minimalist Design
Das Design ist schlicht gehalten, mit einer Gediegenen Color-Palette und freundlichen Formen. Durch einheitliches Theming lullt einen die App in einen Charmanten Farbmantel. Die App kommt ohne Schnick-Schnack aus und konzentriert sich auf die MVPs, die Core Features.

### Help Users With Errors
Die App ist im Grunde nicht schwer zu bedienen, nimmt die Nutzer aber auch nicht an die Hand. Es gibt keine Tutorials und Tooltips. Damit muss der Nutzer ein wenig rum-probieren, um die App gescheit zu benutzen.



# Thinking-Aloud-Tests

Die Thinking-Aloud-Tests sind ohne festes Skript erfolgt, da wir es für besser hielten, individuell und spontan auf die Partizipenten zu reagieren. Wir haben uns als Entwickler eine App für HCI vorgestellt und gefragt, ob die Partizipenten eine halbe Stunde Zeit für einen Usability-Test hatten. Die Interviews sind, wie die User-Research-Interviews, im Infotreff in D14 abgehalten worden.

Wir haben kurz das Grund-Konzept unserer App vorgestellt und dann die App mit Aufgaben an die Teilnehmer gegeben. Die Aufgaben waren die Folgenden:

### 1: Füge ein Task-Widget hinzu, und dann darin eine Tasks. Passe das Datum auf heute in 3 Wochen an und schließe die Task anschließend ab. Lösche die Task.

### 2: Füge ein Wasser-Widget hinzu. Ändere das Ziel auf 3 Liter, und trinke dann 1.5 Liter davon. 

### 3: Füge ein Timer-Widget hinzu. Stelle den Timer auf 30 Minuten und lasse ihn durchlaufen. 
(Zeit war dafür um den Faktor 60 beschleunigt.)

### 4: Lösche alle vorher angelegten Widgets.



## Teilnehmer 1:
### 1:
Der Hinzufügen-Button wurde nicht direkt gefunden, und es wurde im Dashboard geschaut. Dabei wurde bemäkelt, dass diese nicht klar voneinander getrennt seien. Denn Button sollte man klarer als Button erkennbar machen (Zu dieser Zeit hatte der Button noch keine Outline.)

Beim Auswählen des Datums sollte der Button zum auswählen des Datums auch klarer als Button erkennbar gemacht werden.

### 2:
Wieder wurde sich Outlines um die Add-Buttons gewünscht. Die Buttons wurden erst als Skala interpretiert.  Es wurde sich eine Skala für das Wasserglas gewünscht.

Zudem war die Overfill-Mechanik für den Teilnehmer eher verwirrend. Es wurde sich gewünscht, dass der Custom-Amount-Button den letzten Eingabewert speichert.  Zudem war die Teilnehmerin kein Fan davon, dass man im Aussuchen des Tagesziels durch den Slider beschränkt ist, wenngleich das feature an sich für den Sommer praktisch sei.

### 3:
Das Bedienen des Timers verlief ohne Probleme. Es wurde sich eine Abfrage am Ende gewünscht, ob man das auch tatsächlich für die Zeit produktiv war.

### 4:
Das Deleten wurde nicht direkt gefunden, und ein Hinweis auf die Widget-Einstellungen war vonnöten. Es wurde zunächst versucht, das Widget mit Tippen und Halten in einen Delete-baren Zustand zu versetzen.



## Teilnehmer 2:
Glücklicherweise ist es uns gelungen, in Interview 2 die Person zu interviewen, die wir auch schon in Interview 1 für die User Research interviewt hatten. Damit konnte die Person sagen, inwieweit sich ihre Anforderungen erfüllt haben.

### 1:
Wieder wurde bemängelt, dass der Add-Widget-Button schwer zu finden sei. Ansonsten "tut das Task-Widget, was es soll". Bedienungsprobleme gab es keine.

### 2:
Die Glas-Optik der Wasser-Anzeige wurde gelobt. Der Slider in den Einstellungen war okay, obwohl die Person normalerweise kein Fan von Schiebereglern sei, da der Rahmen (0-4L) eh selten überschritten werden sollte.
Zudem wurde die Anordnung der Buttons bemängelt (100ml über 250ml), der Punkt wurde aber Fallen gelassen, nachdem klar wurde, dass man die Menge, die die einzelnen Buttons hinzufügen, in den Einstellungen verändern kann. Bedienungsprobleme gab es keine.
"Ich kann mich nicht beschweren" (Größtes Lob, was eine deutsche Person sagen kann)

### 3: 
Der Stop-Button sollte aufgrund besserer Verständnis zu "Reset" umbenannt werden. Die Duration Dial hat keine Probleme in der Bediehnung verursacht.

Das Widget "Sieht eigentlich ziemlich gut aus" und "sei ähnlich wie Gewünscht".

### 4: 
Wieder wurde zunächst versucht, das Widget mit Tippen und Halten in einen Delete-baren Zustand zu versetzen. Danach wurde aber schnell der Weg in die Einstellungen gefunden.


## Interpretation
Alles in allem wurden ein paar Schwachstellen bei den Usability Reviews klar, die wir aufgrund von Betriebsblindheit übersehen hatten. Beispiele dafür waren nicht deutlich genug gekennzeichnete Buttons. Diese haben wir im Anschluss behoben. Ansonsten gab es noch ein paar optische Kritiken und Feature Requests, denen wir nicht nachgegangen sind. Die Bedienung der App lief aber größtenteils Fehlerfrei. Dies ist ohne Frage nicht zuletzt dem zu verdanken, dass wir die Interviews mit Technik-Affinen Informatik-Studierenden durchgeführt haben.




# Accessibilty Scanner
Bei dem benutzen des Accessibility Scanners sind 146 Vorschläge über 37 Screens angefallen. Einige davon waren Duplikate. Die Vorschläge ließen sich in Drei Kategorien einteilen:

### 1: Objektlabel
Ein Icon-Button hatte kein Bedienungshilfen-Label, was das Korrekte anzeigen mit Sprachausgabe unmöglich macht.

### 2: Text nicht Enthalten
Ein Text, der Auf dem Bildschirm erkannt wurde, ist so nicht im Bedienungshilfen-Label vorhanden.

### 3: Berührungszielbereich
Ein antippbarer Bereich ist kleiner als 45dp x 41 dp. Damit ist er schwer anzutippen.

### Fazit
Alle diese Drei Probleme sind recht leicht zu beheben, indem Bedienungshilfen-Labels hinzugefügt werden oder Objekter höher Skaliert werden. Leider hat das Hinzufügen von Bedienungshilfenlabels den Rahmen unseres Projektes gesprengt, ansonsten wäre das eine gute Idee gewesen.


# Development Process
Unser Process ist am ehesten dem Agile-UX-Prinzip gefolgt. Allerdings haben wir viel zu lange am Code gesessen, und damit wenig Zeit für die Dokumentation gehabt. Damit war offensichtlich, dass wir wenig Erfahrung mit diesen Arbeitsweisen haben und diese nur bedingt anwenden konnten.

# Was gut und weniger gut lief
Die Interviews liefen ziemlich gut - dass wir einen der initialen Interview-Partner wieder interviewen konnten war ein Glücksfall. Allerdings haben wir zu lange am Code gesessen und Code Freeze war für uns eher eine Legende... Dass sollte beim nächsten mal definitiv besser gemacht werden.



