What framework or tools are you going to use? Why?
Wir benutzen HTML, CSS und JavaScript, da wir unseren Prototypen einfach ändern wollen. Da wir zur geleiteten Erstellung von Schemata vielfach den “selben” Bildschirm nutzen und sich lediglich die Fragen ändern, wäre es ein sehr großer Aufwand gewesen, dies mit gängigen Prototyping-Tools umzusetzen. HTML, CSS und JavaScript geben uns die Möglichkeit, die Inhalte dynamisch zu ändern.
List your functional and non-functional requirements (features) you are planning to include in your High-Fidelity Prototype.
Funktional:
Geleitete Erstellung von Schemata
Manuelle Suche nach bestimmten “Subschemata”
Speichern eines erstellten Schemas
Navigation zwischen den einzelnen Funktionen
Übersicht der Abgespeicherten Schemata
Nicht-Funktional:
Intuitive Bedienung (Keine “Anleitung” oder “Tutorial” o.Ä. notwendig)
Einfache Handhabung: DIe geleitete Erstellung von Schemata soll die kognitive Last der Lernenden verringern und nicht zu weiterer Verwirrung beitragen.
Timeline
Was?
Bis wann?
High-Fidelity Prototype Grundgerüst
11.06.2021
Farbkonzept – Erster Entwurf
14.06.2021
Schema-Übersicht entwickeln
18.06.2021
Einbingung aller Fragen zu einem Schema
21.06.2021
Icons Überprüfen/Raussuchen/Ersetzen
24.06.2021
Suchfunktion darstellen
28.06.2021
Schriftarten Überprüfen/Ersetzen
28.06.2021
Fragen an Schema-Übersicht koppeln
05.07.2021
Farbkonzept – Finalisieren
05.07.2021
Hintergrundgestaltung
05.07.2021
Namensgebung von Schemata einbinden
12.07.2021
Progress-Übersicht während Fragen entwickeln und einbinden
Wir haben uns für ein Grid-Menü entschieden, da wir ein “aufgeräumtes” und “übersichtliches” Interface schaffen wollten, welches sowohl als Desktop-Anwendung, als auch auf größeren Tablets noch ausreichend gut funktioniert. Durch große Symbole möchten wir schaffen, dass die Nutzer*innen nach kurzer “Lernphase” die Anwendung benutzen können ohne die Schrift auf den Buttons lesen zu müssen. Darüber hinaus sind vielen Nutzern die “Kacheln” als Menüstruktur z.B. von Windows-Betriebssystemen bekannt.
Which UI controls are appropriate for your application and why?
Als UI-Controls kommen nur Maus und Tastatur, beziehungsweise die Umsetzung dieser durch einen Touchscreen in Frage. Alle Funktionen, die eine Maus kann auch über einen Touchscreen umgesetzt werden können, aber nicht anders herum, wird sich für die Analyse auf Maus und Tastatur beschränkt.
Which design patterns are suitable for your application and which ones have you implemented or used? Why?
Für unsere Anwendung wäre beispielsweise ein Design Pattern für die Suche nach Schemata verwendbar. Aktuell ist dort ein Input-Feld als Platzhalter angelegt. Im weiteren Verlauf wird dies entweder inspiriert durch Design Patterns abgeändert oder komplett durch eines ersetzt. Ansonsten haben wir bisher keines Umgesetzt und bis auf die Suchfunktion wird wahrscheinlich nichts durch solche ersetzt.
The QWERTY keyboard layout developed by Christopher Latham Sholes in 1874 for the typewriter was designed to be the most efficient layout possible for the English language. The idea was that the person typing move their fingers between the rows to type the most common letters. It is also told that the arrangement of the keys was designed to reduce the possibility of typebars hitting each other by placing often used combinations of letters further away from each other. The QWERTY layout now has become the de facto standard for English language keyboards.
The French-speaking countries often use the AZERTY layout which switches the Q for an A and W for Z. The M key has moved to the right of the L key and some special characters are accessible with the shift key.
The QWERTZ layout used in central Europe (Germany, Austria, Switzerland, and Czech Republic) swapped the Y and Z key, as well as special characters such as brackets, are replaced with characters such as Ä, Ö, Ü, ß.
The Dvorak layout was developed by August Dvorak in 1936 with the intention to be more efficient than the QWERTY layout and it is also better suited to right-handed people. Distance measurements showed that the Dvorak layout reduces your hand movement to almost half of that of the QWERTY layout. After getting used to the key arrangement users saw an increase in typing speed up to 10-15%.
Das Chorded Keyboard, oder auch Akkordtastatur ist eine andere Art von Eingebegerät. Dieses wurde auch, genauso wie die Maus, 1968 von Douglas Engelbart auf „the Mother of All Demos“ vorgestellt. Sein Model hatte 5 Tasten mit denen, ähnlich wie bei einem Klavier Akkorde gespielt werden können und daraus Buchstaben entstehen. Buchstaben wurden der Reihe nach kodiert also war das „c“ z.B. eine 3. Die verschiedenen Tasten seiner 5 Tasten Tastatur waren: 1,2,4,8 und 16 um als ein c zu schreiben musste man taste 1 und 2 drücken und sobald man sie losgelassen hat Erschien ein c. Neuartigere Akkordtastaturen haben meist zusätzliche Tasten da man oft zusätzliche Features, wie Zeichensetzung Absätze Umschalttaste etc. braucht so hat das Decatxt beispielsweise 10 Tasten. Auch gibt es Chorded keyboards programmierbaren Macrotasten.
Das Anti-Aliasing, oder auch Kantenglättung genannt, ist ein Verfahren in der Computergrafik, um bei erstellten 2D- und 3D-Objekten ein höheres Maß an Realismus zu erreichen. Dies geschieht durch die Verringerung des Treppeneffekts. Der Treppeneffekt in gerasterten Figuren ist der endlichen Anzahl an Pixeln des Ausgabegerätes geschuldet.
Das Grundprinzip des Anti-Aliasings ist das Auswerten nicht nur eines einzelnen Pixels, sondern auch der umliegenden Pixel. Durch Verwendung eines Rekonstruktionsfilters können daraufhin die Farben der abgetasteten Pixel angepasst werden, wodurch das Objekt einen glatteren Eindruck macht.
Je nach verwendetem Rekonstruktionsfilter kann das Objekt, auf dem Anti-Aliasing angewendet wurde unscharf erscheinen. Beim Echtzeitrendern fällt die zusätzlich benötigte Rechenleistung des Anti-Aliasing ebenso zur Last, was einen großen Nachteil dieses Verfahrens darstellt.
(1) Continue to develop (or start a new) paper prototype based on new insights or feedback from your peers.
Da es während dem Tutorium nicht stattgefunden hat, wurde kein Feedback erhalten und somit auch nichts groß verändert.
(2) Conduct 3 formative usability tests.
a) Skript
Hinweise für den User: Wir testen die App, nicht dich! Fragen gerne stellen, wir können aber versprechen, dass wir sie alle direkt beantwortet werden. Du kannst also nichts falsch machen! Wir bitten dich deine Gedanken laut auszusprechen.
Kontext der Anwendung: ScenicRoute ist ein unkonventionelles Routenplanerprogramm. Es berechnet anders als herkömmliche Routenplanung nicht die schnellste Route, sondern diejenige mit den meisten Sehenswürdigkeiten, den außergewöhnlichsten Attraktionen oder den als sehenswert erachteten Wanderwegen.
Fragebogen: Wie alt bist du? Wie lange wohnst du in xxx?
Szenario: Du stehst morgens um 9 Uhr, machst dir einen Kaffee, frühstückst und kümmerst dich um deine heutigen Uniaufgaben. Deine Arbeit für die Uni ist gegen 17 Uhr in der Regel erledigt und Du nutzt die Zeit um spazieren zu gehen. Meistens zieht es Dich in Richtung des nahegelegenen Parks, indem Du gerne spazieren gehst. An dem heutigen, recht sonnigen, Tag wanderst Du allerdings ziellos durch die Straßen Deines Viertels, Du nutzt den Spaziergang um Dir bei einer nahe gelegenen Rösterei einen Kaffee zu holen und Dich auf eine Bank zu setzen. Auf der gegenüberliegenden Straßenseite fällt Dir ein sehr schönes Gebäude auf. Du vermutest es stammt aus der Renaissance bist Dir aber nicht sicher. Das Gebäude sieht recht offiziell aus und Du fragst Dich, ob es öffentlich genutzt wird. Du probierst das zu Googeln kommst aber nicht weiter und brichst die Suche nach 3 Minuten ab und wünschst dir einen einfacheren Weg bei deinem Spaziergang an eine solche Informationen zu kommen.
Aufgaben: Gucke Dir die App an und beschreib uns wie sie auf Dich wirkt. Mach Dich mit der App vertraut. Beginne eine neue Route zu planen und diese zu starten. Anschließend probiere eine neue Route hinzuzufügen.
Abschließende Fragen: Bist Du der Meinung alles Nötige, was Du für die Nutzung einer solchen App erwartest gefunden zu haben? Hat Dich irgendwas am Design (abgesehen der mangelnden künstlerischen Fähigkeiten der Macher) gestört?
Abschluss: Hast Du noch weitere Anmerkungen oder Fragen?
Vielen Dank für Deine Teilnahme und beim Helfen bei der Weiterentwicklung der App.
b) Rollenverteilung
In Interview 1 und 2 war Marc der Facilitator und Sebastian der Observer. Wir haben uns entschieden für das letzte Interview die Rollen zu tauschen, da Marc die ersten beiden und Sebastian den dritten Interviewten kannte und wir der Meinung waren, dass diese sich wohler fühlen, wenn jemand Bekanntes sie durch die App führt.
c) Decide if you want to record your test session and how you take notes during the test sessions.
Wir haben uns dazu entschieden, die Sessions nicht aufzunehmen, weil wir unsere Interviewees nicht unter Druck setzen wollten. Wir bemühten uns mit den Interviewten eine entspannte Atmosphäre aufrechtzuerhalten, da alle aus unserem Bekanntenkreis stammen. Demnach haben der Observer immer fleißig mitgeschrieben, Kommentare festgehalten und Bewegungen und Mausklicks analysiert.
d) Document who you are inviting for a test session and how long the session lasted.
Tabea (23 Jahre, lebt seit 23 Jahren in Berlin, Interview 15min)
Patricia (24 Jahre, lebt seit 16 Jahren in Berlin, Interview 20min)
Daniel (26 Jahre, seit 8 Jahren in Berlin, Interview 15min)
(3) Document and evaluate the results of your testing.
a) What method did you use to evaluate the results of your usability tests? How did you evaluate the results?
Wir haben uns dazu entschieden, alle Interview Ergebnisse in einem Affinity-Diagram festzuhalten.
Zu Beginn haben wir alle Kommentare und Ideen als Anmerkung gesammelt, dann haben wir passende Über- und Unterüberschriften gesucht und im Anschluss die Kommentare gruppiert. Dies hat uns geholfen einen guten Überblick über unsere Nutzbarkeitstests zu erhalten und was für Verbesserungen wir noch durchführen sollten.
b) What did you learn from the testing? What are your main takeaways?
Durch das Testen haben wir zusätzliche interessante Verbesserungsvorschläge an die wir bisher noch nicht gedacht haben erhalten können. Wir haben wertvolle Kritik erhalten bzgl. der Nutzung des Prototypens. Dieser kam größtenteils gut bei den Nutzer:innen an. Der Usability Test hat uns gezeigt, dass unsere Nutzer:innen sehr explorativ an den Prototypen herangegangen sind und teilweise entgegen unserer Erwartung sich durch einen anderen Weg geklickt haben. Lediglich die Darstellung der App, aufgrund der nicht wirklich großen künstlerichen Fähigkeiten der Entwickler wurde regelmäßig kritisiert (obwohl der dritte Testteilnehmer äußerte, dass es die App individuell machen würde (allerdings eher mit einem Augenzwinkern)). Wir haben also einen Blick outside the box erhalten können
(4) Reflection
Wer hat welchen Beitrag geleistet? Aufgrund von begrenzter zeitlicher Möglichkeiten haben Marc und Sebastian diese Woche die Durchführung der Interviews übernommen und die Ergebnisse im Anschluss zusammengestellt. Milos hat das Ganze dann nochmal überprüft und abgesegnet.
Was habt ihr gelernt? Wir haben gelernt, dass verschiedene Nutzer:innen mit einer App unterschiedlich umgehen und man aus diesem Grund vor der professionellen Entwicklung einer Anwendung definitiv eine Vielzahl von Usability-Tests mit unterschiedlichen Personen durchführen sollte. Dies hilft ein breites Spektrum der Nutzung zu erhalten und dadurch die Bedürfnisse der Nutzer:innen zu erfüllen.
Was lief gut? Wir hatten Glück mit unseren Interviewees, da diese spontan Zeit gefunden haben und sehr motiviert mitgearbeitet haben. Das Moodboard hat uns geholfen besonders schnell einen Überblick über die gesammelten Informationen zu bekommen. Unsere Gruppenarbeit war sehr kommunikativ. Unstimmigkeiten konnten wir schnell klären.
Was möchtet ihr verbessern? Uns ist aufgefallen, dass wir uns sehr gut verstehen, dadurch die Arbeitsatmosphäre sehr gut im Team ist, wir dennoch mittlerweile häufig vom Thema abkommen und uns verquatschen, weswegen die Arbeit nicht mehr ganz so effizient ist wie früher. Einerseits macht sie viel Spaß, andererseit verlieren wir viel Zeit. Wir wollen versuchen in Zukunft wieder etwas fokussierter zu arbeiten.
Testperson: Datum: Beginn / Startzeit: Ende / Endzeit: Max. Zeit: 30minuten
(1) Einführung
Vorstellungsrunde + Aufgabenerklärung
Wir testen die App – oder genauer, einen digitalen interaktiven Prototypen. Wir testen nicht dich!
Wir nehmen zur nachträglichen Auswertung die digitale Testung auf. Die Aufzeichnung bleibt bei uns intern und wird direkt nach der Auswertung gelöscht. Es wird nur das Audio aufgenommen. Du selbst bist nicht zu sehen.
Stelle gerne Fragen! Ich kann aber nicht versprechen, alle Fragen direkt zu beantworten!
Bitte denke laut (Think aloud)
(2) Kontext der Anwendung erklären
GoWalkies ist eine WebApp mit der es möglich sein soll, Gassirouten zu planen. GoWalkies bietet dazu an, vorgefertigte Routen auszuwählen und zu verändern. Im Rahmen dieses Usability Test möchten wir die Schnellroutenplanungs-Funktion (anhand unsere digitalen Papierprototypen) testen und Feedback dazu einholen.
(3) Fragebogen
… Hast du einen Hund oder mehrere?
… Welche digitalen Geräte besitzt Du?
… Welche digitalen Geräte benutzt Du regelmäßig im Alltag? Wie bspw. Smartphone, Tablet, Laptop, Desktop-PC.
… Wie würdest Du Dich selbst im Umgang mit digitalen Geräten einschätzen? (Anfänger/in) 1-6 (Experte)
… Wie würdest Du Dich selbst im Umgang mit dem Internet und Webseiten einschätzen?(Anfänger/in) 1-6 (Experte)
Bevor es losgeht, eine letzte Frage: Mit welchem Gerät wirst Du den Usability Test jetzt durchführen?
(4) Szenario(s)
Du kommst nach einem langen Arbeitstag im Büro (vor dem Rechner und über Akten) nach Hause und hast wenig Zeit, denn deine zwei Kinder und dein/e Partner/in warten auf Dich und erwarten, dass Du am häuslichen Familienleben teilnimmst. Dein zweijähriger Schäferhund braucht aber auch Auslauf – und Abwechslung. Denn Du hast selbst höhere Ansprüche, wenn man sich ein Haustier anschafft. Deshalb willst Du eine halbe Stunde raus mit dem Hund und es soll nicht jedesmal die gleiche Route sein.
Da Deine Zeit so knapp bemessen ist, darf die Planung nicht länger als 15 Minuten dauern.
Du setzt dich also an den Essenstisch im Wohnzimmer,
öffnest deinen Laptop,
den Browser,
tippst die Adresse der Webseite von GoWalkies ein,
meldest Dich an und
legst los mit der Planung.
Für den Test bist Du Harry Hausen!
(5) Aufgaben
1. Mache Dich mit der Anwendung vertraut. Beschreibe, was Du siehst und Deinen ersten Eindruck.
2. Wie würdest Du nun, nachdem Du Dich an Deinen Rechner gesetzt hast, einen solchen kurzen Spaziergang planen?
(6) Abschließende Fragen
Welche Vor- und Nachteile siehst Du grundsätzliche bei der Schnellrouten-Funktion von GoWalkies? Stell Dir vor, Du könntest ein Feature bezogen auf die Routenplanung verbessern, was wäre das und wie würdest Du es verbessern? Warum?
(7) Abschluss
Hast Du weitere Fragen oder Anmerkungen? Vielen Dank für Deine Teilnahme! Du hast uns sehr geholfen.
(2.1) Document who is taking what role.
1. und 2. Usability Testing: Ailis und Hanna Mitschrift, Aljoscha Moderator
3. Usability Testing: Aljoscha abwesend (Uni-Seminar), Hanna: Mitschrift, Ailis: Moderator
1. Usability Test:
Familienangehörige, Hundebestitzerin eines Hundes, nutzt regelmäßig Smartphone & Laptop
schätzt sich als erfahren im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 27 Minuten
2. Usability Test:
Wer ist das? Mitbewohner, Hundebesitzer eines Hundes, nutzt regelmäßig Smartphone, Laptop, Desktop PC und Tracker
schätzt sich als Experte im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 27 Minuten
3. Usability Test:
Wer ist das? Freundin, Hundebesitzerin von zwei Hunden, nutzt regelmäßig Smartphone
schätzt sich als eher erfahren im Umgang mit Webseiten und digitalen Geräten ein
Dauer: 25 Minuten
Dokumentation:
1. Usability Test: Mitschrift durch Hanna und Ailis als nicht-standardisiertes Verlaufsprotokoll
2. Usability Test: Mitschrift durch Ailis als stichwortartiges, nicht-standardisiertes Verlaufsprotokoll
3. Usability Test: Mitschrift durch Hanna als nicht-standardisiertes Verlaufsprotokoll, Ailis als Moderatorin
Wir haben uns für eine reine Audioaufnahme entschieden, um – durch die reine Digitalität der Testungen – Ängste ggü. (dauerhafter) Bildspeicherungen auf Seiten der Tester:innen zu vermeiden. Damit wollten wir eine möglichst angstfreie und offene Umgebung schaffen, die zu einem produktiven Austausch und möglichst großer Offenheit führt. Weiterhin waren wir (meist) zu dritt, sodass wir eine protokollierende Person, eine moderierende Person und eine observierende Person während der Testungen hatten. So konnte mind. eine Person sich vollständig auf die Mausbewegungen und die Aussagen der Person konzentrieren, ohne parallel (inter-)agieren zu müssen.
Die Testpersonen waren alle vor Ort bei einem aus unserem Team (bei Hanna zwei und bei Ailis). Dadurch war der Mitschriftenführer auch immer bei der Testperson und konnte so einfacher jede Regung notieren.
Ein Screencast wäre wahrscheinlich sinnvoll gewesen, wäre der Prototyp insgesamt größer. Da er sich auf wenige Bildschirme beschränkt und „nur“ einen Weg/eine Aufgabe ermöglicht, wären Screencasts zur nachträglichen Auswertung ein zu großer Overhead. Außerdem konnten wir als Gruppe nach jeder Testung direkt ein Auswertungsgespräch führen und so die wichtigen Erkenntnisse direkt herausfiltern.
(3) Document and evaluate the results of your testing.
Gesammelte Notizen aus unseren Usability Tests – 1Gesammelte Notizen aus unseren Usability Tests – 2Gesammelte Notizen aus unseren Usability Tests – 3
Wir haben uns dazu entschieden, alle (analogen) Notizen im Miro-Board zusammenzutragen, um gemeinsam darauf zugreifen zu können. Anschließend haben wir die Notizen in ein Affinity Diagramm übersetzt. Mit Hilfe des Affinity Diagramms und Dot-Votings konnten wir die Ergebnisse und Einsichten gewichten und so entsprechend weitere wichtige Schritte für Änderungen und Ideen festhalten.
Gruppierte und gevotete Notizen
Bei der Erstellung des Affinity Diagramm trat wieder der Prozess der Kategorienaushandlung auf: Während der Sortierung der Notizzettel sind uns weitere Kategorien eingefallen, die zur Sortierung Sinn machen könnten. Dadurch haben wir nochmal neue Perspektiven zur Auswertung gewonnen. So hatten wir begonnen, die Notizzettel nach den einzelnen Ansichten (Pages) der Anwendung zu sortieren, dort jeweils nach „Aussehen“ und „Inhalt“. Dann haben wir aber die größeren Kategorien erweitert noch mit „Accessibility“/“Farben und Co.“ sowie „Usability“ und „Nice-to-have“.
Alle unser Erkenntnisse und next Steps aus unseren Usability Tests.
Die main takeaways und nächsten Schritte haben wir dann direkt im Miro-Board festgehalten – helle Post-its. So können wir die nächsten Schritte angehen und haben dadurch auch eine Priorisierung.
Der Klickdummy auf der Startseite ist zu eingeschränkt. Einige Tester:innen wollten direkt mit der Planung loslegen. Hier ist entweder der Klickdummy auf der Startseite zu erweitern oder das Szenario anzupassen.
Auch auf der Seite der Routenplanung hätte man den Filterdialog einbauen sollen – um die Aufgabe bzgl. der 30 Minuten zu erfüllen. Denn so gab es immer ein kurzes Stocken in dem Bildschirm bezogen auf die Aufgabenstellung/das Szenario.
Es kam zu etwas Verwirrung durch die Karte von Frankfurt, weil mit Charlottenburg in der Ansicht gestartet wurde. Hier muss detaillierter an den entsprechenden Inhalten, die den Testern präsentiert werden, gearbeitet werden – zu viel Zeitaufwand für das gesamte Modul, nicht leistbar im Rahmen des Moduls.
Insgesamt: Es sollte ggf. mehr als ein Weg durch die Anwendung im Klickdummy implementiert sein, um die gestellte Aufgabe durch eine Person erfüllen zu lassen, damit die Usability Testung dafür aussagekräftiger wird.
