Kategorie: Week #10

Remote Usability Testing

Compared to traditional in-lab usability testing, remote usability testing is an alternative to get rid of those on-site limitations, such as the lack of representative end-users, the expense of testing, time management problem, and the lack of a proper simulation of the users‘ true environment settings. Remoste usability testing can be usually categorized into synchronous (moderated) and asynchronous (un-moderated) testing.

Synchronous remote usability testing is operated in real time, with the evaluator being spatially detached from the participants. Synchronous testing is also called „live“ or „collaborative“ remote evaluation, is a usability evaluation method that possesses a great deal of similarity to traditional in-lab usability evaluation. This testing enables actual users to take part in the process from their natural environments, using their personal computers to keep the test conditions natural. The benefits of synchronous remote testing are the ability to obtain data from actual users in their normal environment, and reducing inconvenience for participants as there is no need for them to travel to a lab or test centre. Limitations related to the Internet and telecommunications (poor bandwidth/delays) represent some of the disadvantages of this method. Typical synchronous remote usability testing forms may include video call, screen sharing etc.

Asynchronous remote testing is done by detaching the evaluators both temporally and spatially from the participants, it splits the user from the evaluator in terms of location and time. Compared to synchronous testing, asynchronous testing may reach a larger user sample sizes, which would offer a true representation of the users. A more natural test surroundings could offset the testing bias that may occur from a lab, which often leads to participants feeling pressured that can affect the accuracy of usability results. However, this testing is narrow in scope as it doesn’t include observational data and recordings of sudden verbal data. This lack of testing data scope may limit the validity and accuracy of the results, which will lessen the chances of discovering usability problems. Typical asynchronous remote usability testing forms may include Auto-logging, user-reported critical incidents (UCI), unstructured problem reporting, etc.

References:

  1. Alghamdi, AHMED S., et al. „A comparative study of synchronous and asynchronous remote usability testing methods.“ International Review of Basic and Applied Sciences 1.3 (2013): 61-97.
  2. https://www.uxmatters.com/mt/archives/2010/01/unmoderated-remote-usability-testing-good-or-evil.php

[A#8, P8] Heuristic Evaluation

(1) Improving our high-fidelity prototype

Our prototype is improved with some tiny updates so that the test users can have a more near to reality feel by heuristic evaluation and usability testing. We aim to create an easily usable interface for our potential users with corresponsing changes to user tasks.

(2) heuristic evaluation (Phase 1 and 2)

Phase 1 Prepare

Use case:

You have finished a long day of work and would like to have a game night with your friends. After consultation, you decided to organize a game night together online on Social Play. You already have an account on Social Play and you would like to invite your friends join your group. You have sent a link via Social Play to your friend by email. After your friend has logged in, you have started to play together in a meeting.

Tasks for evaluators:

1.register/log-in on Social Play

2.meet with your friends in your group

3.search a game you want to play

4.enjoy your Gaming Night with your friends with Games together with chat

Online form for evaluation collection:

we use google form to collect our feedbacks. The google form is designed using the template given by the lecturer.

Phase 2 Evaluation

We evaluate the protype of JuurMate under the scenario:

Anwendungsfall:

Du musst als Hausaufgabe einen Rechtsfall prüfen. Aktuell bist du auf dem Weg nach Hause und möchtest schon mal damit beginnen. Also öffnest du die JuurMate Anwendung auf deinem Notebook. Nach dem öffnen erscheint ein Auswahlbildschirm, bei dem du dich entscheiden kannst, ob du die geleitete Variante der Anwendung oder die ungeleitete Variante benutzen möchtest. Mit der geleiteten Variante kannst du nun ganz einfach in der Bahn auf dem Nachhauseweg ein einziges Schema dynamisch generieren lassen, dass dir dabei hilft deine Hausaufgabe zu Hause schneller zu beenden.

Aufgaben:

1.Fertige mithilfe der Anwendung ein Prüfungsschema zum Prüfen einer Rechtsfrage zu Mord an.

2. Öffne ein altes Schema, das im Vorhinein abgespeichert wurde. 

3. Suche nach einem Tatbestand.

Documentation and Reflection

The individual evaluation was done separately. Ina and Brendan filled in the online form with their observations, Xin has problem filling in the form, therefore documented on a document with screenshots.

Summary of Evaluation

Based on our evaluations, we found out that (3) user control and freedom and (8) Aesthetic and Minimalist Design are the most violated guidelines. We have found out some critics in common, for example once we entered in a case, there is no „back“ button to go back to previous page. The only choice we could do is to click on the „JuurMate“ and begin with the main page.

We also encountered some problems here, there are some problems we are not so sure to which guideline they belong to. Some heuristics are hard to be evaluated, since we don’t really find any error message in the prototype (we also don’t include them in our prototype). (7) Flexibility and Efficiency of Use is also a hard to be evaluated guideline.

Reflection

Who did what?

Ina improved prototype ready for evaluation. Ina and Brendan prepared the template in google form and described the test case of JuurMate. Xin described the test case of Social Play prototype. The heuristic evaluation regarding JuurMate was done individually. Xin then summarized the evaluation while creating the blogpost.

What have we learned?

We learned how to prepare a prototype for evaluation as well as the heuristic evaluation methods. My only concern was that since our prototyp is really simple at the moment but the evaluation guidelines seem to be well-rounded, is it the good timing to do the heuristic evaluation on such a simple prototype?

What went well?

The individuell evaluation went well (not without problems) even though with difficulties by problem categorization. We were happy that the templated are provided so only minor changes need to be done by us.

What do we want to improve?

The 1st task was some how confused since it is not so clear which preparation is for us and which step is for classmates. The evaluation form is not well established, it is really hard to summarize the severity of each guideline violation and to see the screenshots indicating the problems.

Parametrisches Design

Die Grundlage für Parametrisches Design ist die Erzeugung von Geometrien anhand von Anfangsparametern und der Beziehung, die sie zueinander haben.

Um ein spezielles Design zu erzeugen, werden bestimmte Variablen und Algorithmen verwendet. Zwischen diesen unterschiedlichen Parametern können Beziehungen bestehen. Je nach Anfangsparametern kann eine große Bandbreite an Möglichkeiten erforscht werden.

Parametrisches Design ist von grundlegender Bedeutung, für diejenigen, die den Aufwand für die Erstellung und Prüfung von Designvarianten minimieren möchten.

Im Zuge der integrierten Produktentwicklung wurde es notwendig, zu einer umfassenderen Produktrepräsentation im Rechner zu gelangen. Insbesondere bei einem Concurrent-Engineering-Prozess sollten Änderungen schnell und einfach umsetzbar sein. Um diese Forderungen erfüllen und dem Entwerfer ein möglichst intuitiv zu nutzendes Modellierungssystem zur Verfügung stellen zu können, wurden ab Anfang der siebziger Jahre parametrische CAD-Systeme für den Maschinen- und Fahrzeugbau entwickelt. Der Grund dafür ist, dass viele Produkte und Einzelteile in diesen Bereichen Variationen von Grundtypen und -elementen darstellen.

Quelle: http://parametric-van-conversion.de/was-ist-parametrisches-design/ (20.6.2021)

Im Rahmen von Software Engineering werden beim Parametrischen Design den Softwareentwicklern, also Informatiker:innen, Programmier*innen, Designern usw. durch Machine Learning ausgewählte Alternativen vorgeschlagen, aus denen dann gewählt werden kann. Die Datengrundlage für die Auswahl können eben die Definition von Fokusgruppen, Parametern in Personas (das haben wir bisher noch nicht behandelt) sowie quantitative Daten aus Usability Tests sein.

Quelle: LU #9 – Evaluating Techniques II, Folie 11 + Video der VL zu dieser Folie

[A#8, P2] Heuristic Evaluation

1) Continue to improve your high-fidelity prototype.

In unserem Prototypen war bereits vieles testbar, weshalb wir lediglich ein paar Anpassungen durchgeführt haben. Dazu gehörte unter anderem das erweitern des Gruppenfeatures, sowie das Hinzufügen mehrerer Connections.

2) Conduct the first and second phases of a heuristic evaluation

Phase 1: Prepare

Wir haben ein cryptpad-Dokument für die Gruppe 6 erstellt, in dem wir das Evaluationstool, sowie unser Projekt verlinkt haben. Wir haben uns für die Nielsens’s Heuristics entschieden, da sie zum einen sehr gut zu unserem Prototypen passt, aber auch da sie in der Vorlesung am Besten beschrieben wurde und sie daher auch allen Beteiligten bekannt sein sollte.

cryptpad-Dokument: https://cryptpad.fr/pad/#/2/pad/edit/NmpvphcJUXetv62DG5jLBhLx/

Prepare the tasks for the evaluators

Unsere Aufgaben sahen wie folgt aus. Unser Ziel dabei war, dass möglichst viel der App erforscht und entdeckt wird.

  • Aufgabe 1: Logge dich ein
  • Aufgabe 2: Ändere in deinem Profil deine Ernährungsform zu „vegan“
  • Aufgabe 3: Gehe zurück auf die Startseite und füge „Saftigen Orangenkuchen“ zu deinen Favoriten hinzu. 
  • Aufgabe 4: Gehe in die Rezeptsuche und verwende Zutaten aus deinen vorherigen Einkäufen. Du hast nur noch 2 Tomaten statt 3. Du Möchtest ein bestimmtes Lebensmittel verwenden und nach Rezepten suchen.
  • Aufgabe 5: Suche ein bestimmtes Rezept.
  • Aufgabe 6: Gehe in deine Gruppen und schau dir die Unverträglichkeiten von „Mutter“ in der Familiengruppe an. 

Please use an (online) form to collect the violations by each evaluator in a systematic way.

Wir haben uns für das Google-Template entschieden, welches nachfolgend zu finden ist. Da wir uns ebenfalls für die Nielsen’s Heuristics entschieden haben, war dies zusätzlich passend.

https://docs.google.com/forms/d/19qxXKwOrF2GhEKbMbcQY2g3BIninJRPmy7dk3O-h4nk/edit

Prepare so everybody can take screenshots and is able to link them in the previous form.

Das Sammeln der Screenshots haben wir über ein cryptpadDrive-Dokument verwirklicht. Hier konnte jeder Nutzer nach Anmeldung seine zuvor erstellten Screenshots hochladen und dementsprechend in dem von uns bereitgestellten Inspektionstool verlinken.

cryptpadDrive-Dokument: https://cryptpad.fr/drive/#/2/drive/edit/2Ih4r49Im3ZYPCkd9SvZSkNx/

Phase 2: Evaluate

DOCUMENT EVALUATION (Friederike)

  • Die von Gruppe 6 geschickte Anleitung zum Testen des Prototypens war leider sehr knapp beschrieben und führte bei allen Gruppenmitgliedern zu Problemen. Nach anfänglichen Schwierigkeiten haben wir es dann aber alle geschafft den Prototypen zum Laufen zu bekommen.
  • Gruppe 6 arbeitet ebenfalls mit Nielsen’s Heuristics, weshalb mir diese bereits bekannt waren und ich direkt mit der Evaluation anfangen konnten.
  • Da das Hochladen der Screenshots in dem bereitgestellten Dokument nicht so funktioniert hatte, wie ich erwartet hatte, habe ich die Screenshots im nachhinein hochladen müssen und konnte sie nicht richtig im Evaluationstool verlinken.
  • Bei manchen Aufgaben war ich mir leider nicht ganz sicher, ob ich sie erfüllt habe, oder nicht, da es mir nicht ganz klar war was ich genau machen soll.
  • Da der Prototyp der Gruppe 6 noch im Anfangsstadium ist, habe ich mich neben den gestellten Aufgaben teilweise sehr lange an kleinen Details aufgehalten und auch mehrere Issues zu einer einzelnen Sache erstellt.

Documentation and Reflection (Janis)

  • Die Kommunikation mit der Gruppe 6 lief gut, wir haben dafür Mattermost benutzt um miteinander zu schreiben, es gab ein paar technische Schwierigkeiten auf beiden Seiten die aber recht schnell aus der Welt geschaffen wurden (github und Figma Zugriffsrechte waren jeweils nicht ganz richtig konfiguriert).
  • Ich konnte die Aufgaben der Gruppe 6 problemlos ausführen.
  • Die bei weitem meist verletzte Heuristik war die der Konsistenz und irgendwann habe ich mich etwas doof gefühlt da immer und immer wieder zu sagen, dass es nicht Konsistent ist und wegen des frühen Stadiums des Prototypen auch teilweise nicht alles genannt.
  • Ich hatte Probleme manche Sachen den Heuristiks zuzuordnen, so habe ich ein Feature (top 5 Freunde) nicht verstanden, allerdings habe ich dazu keine wirklich passende Heuristik gefunden.

DOCUMENTATION AND REFLECTION (Nirmin)

  • Ich konnte alle Aufgaben der anderen Gruppe problemlos lösen. Gleichzeitig dabei habe ich von den Issues, die ich gefunden habe, Screenshots gemacht. Ich habe zudem Screenshots von Stellen aufgenommen, wo mir etwas besonders aufgefallen hat.
  • Die Aufgaben waren klar formuliert.
  • Die ähnliche Arbeitsweise von der Gruppe 6 hat den Umgang mit der Evaluierung für mich erleichtert und Abschrecken vom Nutzen neue Tools genommen. Dass die Gruppe 6 das XAMPP genutzt hat, war die einzige neue Sache für mich.
  • Die Einführung zum Nutzen von XAMPP von der anderen Gruppe war nicht ausführlich beschrieben, daher musste ich meine Kommilitonen z.B. beim Starten des Servers nach Hilfe fragen.
  • Obwohl ich mir die Heuristiken mit voller Konzentration angeschaut habe, ist mir die Zuordnung nicht sehr einfach aufgefallen.
  • Die Zeit zur Antwort auf die Evaluierungsfragen hat nicht so lange gedauert (Nach 25 Minuten war ich fertig). Das Installieren von der Evaluierungsumgebung und herausfinden, wie die Anwendung gestartet werden kann hat ca. 30 Minuten gedauert.

Phase 3 und 4: Group discussion, Document

In der LabSession konnten wir Phase 3 und 4 der Heuristic Evauluation durchführen. Das Ergebnis dazu ist nachfolgend hochgeladen.

GoWalkiesHerunterladen
Seiten: Seite 1, Seite 2

​​​​​​​​​​​​​[A#8, P6]: Heuristic Evaluation

(1) Continue to improve your high-fidelity prototype

  • Unser Prototyp ist bereits testbar und wir haben letzte Woche schon gut vorarbeiten können. Wir belassen unseren Prototypen daher so, wie er ist. Wie zuvor ist er unter folgendem Link zu finden und herunter zu laden.
  • Wir fügen lediglich noch die Funktion hinzu, Routen starten zu können (ans Handy senden/drucken)
  • Um unseren Prototypen zu testen muss ggf. ein Webserver lokal installiert werden, Dafür schlagen wir für Linux & Windows Xampp vor (https://www.apachefriends.org/de/index.html)  und für Macs MAMP (https://www.mamp.info/de/mac/)
    • nach der Installation Anwendung starten und Server starten
    • unser Projekt GoWalkies muss in das Verzeichnis xampp/htdocs gelegt werden
    • anschließend kann man im Browser über localhost/gowalkies unseren Protypen aufrufen

(2) Conduct the first and second phases of a heuristic evaluation

Phase 1: Prepare

  • Das Dokument für die Gruppe 2: ​​​​​​​https://cryptpad.fr/pad/#/2/pad/view/0sCGv1qfIRow26KBZP3NekXAZs6iSvcwpo9tYAMX5dw/
  • Prepare the tasks for the evaluators.
    • Aufgabe 1: Erstelle dir ein Konto (Daten werden nicht gepeichert, man kann sich aber durchklicken)
    • Aufgabe 2: Melde dich an
    • Aufgabe 3: Finde eine max. 30 min lange Route
    • Aufgabe 4: Finde heraus, wie oft du bestimmte Routen bereits gelaufen bist.
    • Aufgabe 5: Finde heraus, wer die Hunde von Martin sind und was er über sich und seine Hunde schreibt.
    • Aufgabe 6: Melde dich ab
  • Please use an (online) form to collect the violations by each evaluator in a systematic way.
    • Wir haben und für das Goolge-Template entschieden. Die Skala und Auswahl der einzelnen Heuristiken von Nielsen finden wir passend und benutzen das so. Wir wählen die Methode außerdem, da sie bereits gut ausgetestet und bekannt ist.
    • GoogleSheet: https://forms.gle/YnmeCyz7i7YdxizZ7
  • Prepare so everybody can take screenshots and is able to link them in the following form.

Phase 2: Evaluate (Individual Inspection)

Document and reflection

Zur Evaluation haben wir folgende Infos aus den Vorlesungen genutzt:

Hints for a „good“ evaluation

  • grounded in known usability guidelines
  • justify each problem by appealing to a heuristic and explain how it violates
  • list every problem separately
  • inspect the interface at least twice 

Document Evaluation (Aljoscha)

  • Ich habe die Nr. 1 genommen als Evaluator-Nr.
  • Der von der Gruppe geschickte Link zum Prototyp auf Figma funktionierte nicht. Dadurch wurde ich zeitlich ausgebremst und muss nun wieder umplanen.
  • Die Gruppe nutzt Nielsens Heuristiken. Deshalb habe ich die Folie der Vorlesung als Grundlage genutzt.
  • Weiterhin habe ich die Tipps für eine „gute“ Evaluation herangezogen.
  • Die Eingabe habe ich über das bereitgestellte Google Formular erledigt.
  • Bei der Aufgabenbearbeitung ist aufgefallen, dass die Aufgaben teilweise unpräzise gestellt wurden, sodass ich ein wenig raten musste, was von mir gewollt wird. Die Aufgaben waren z. T. nicht der UI entsprechend gestellt.
  • Issues sind teilweise mehreren Heurstiken zuordnenbar.
  • Teilweise ist es schwierig, kurz und prägnant die Issues zu beschreiben – sonst wären es „Romane“ geworden.
  • Der Prototyp war in Teilen nicht fertig, um alle Heuristiken anwenden zu können (Favoriten adden, …).
  • Ich habe das Interface zwei Mal untersucht.
  • Ich habe nach 60 Minuten aufgehört.

DOcument our Evaluation (Hanna)

  • Da die Gruppe 2 ähnlich arbeitet, wie Unsere, war es sehr einfach, sich in der Aufgabe zu orientieren. Sie haben uns ein CryptDrive File-Link geschickt, in dem die Aufgaben standen und der Link zum Google Sheet.
  • Nielsens Heuristiken waren mir bereits bekannt, trotzdem war es nicht immer einfach, jedem Issue eine Heuristik zuzuordnen. Die Heuristiken sind schließlich sehr speziell und zum Beispiel eine Fehlplatzierung von Textfeldern passt zu keiner perfekt.
  • Die Screenshots haben wir alle erst bei uns gespeichert, da uns nicht gesagt wurde, welches zusätzliche Tool wir dafür benutzen sollten. Im Anschluss haben wir dann die Bilder alle in einen Ordner hochgeladen, die Gruppe muss dann die Bildernamen selber zuordnen.
  • Nachdem ich die gestelleten Aufgaben erledigt habe (wobei es zwischendurch ein Missverständnis gab, dass mir meine Gruppenmitglieder parallel erklärt haben), habe ich mir noch ein wenig den Prototypen allgemein angesehen. Mir fiel auf, dass man nicht von jeder Seite eigentlich erreichbare Seiten anklicken kann oder der Home-Button nicht immer klickbar ist. Das werde ich dann in Phase 3 (Discussion) ansprechen, es ist aber eben auch noch ein Prototyp.

Document Our evaluation (Ailis)

  • Auch diese Gruppe hat die Nielsens Heuristiken genutzt, was das Evaluieren einfacher gemacht hat, da ich bereits etwas vertraut war mit den Heuristiken.
  • Während des Lösens der Aufgaben habe ich das Interface untersucht und dabei evaluiert wie einleuchtend mir das Design dabei erscheint
  • Ich habe alle Aufgaben gelöst und dabei Screenshots gemacht und mit dem provideten Google Formular Issues gesammelt
    • jedes Issue habe ich einzeln  gesammelt und erklärt, auch wenn es sich um denselben Button handelte
    • ich habe versucht möglichst konstrukives Feedback zu schreiben und dabei auch Sachen die mir gut gefallen haben hervorzuheben
  • Allerdings hat die Gruppe keine Möglichkeit bereitgestellt Screenshots hochzuladen, was das ganze etwas erschwert hat
Seiten: Seite 1, Seite 2, Seite 3

Keystroke Level Model

Beim Keystroke Level Model handelt es sich um ein quantitatives Verfahren aus dem Forschungsbereich des Human Computer Interaction, welches eine Vorhersage darüber treffen soll, wie lange ein erfahrender Benutzer für die fehlerfreie Bearbeitung einer Aufgabe auf einem genannten System braucht.
Um eine Analyse durchzuführen, sollte im besten Fall schon ein High Fidelity Prototype vorhanden sein. Das KLM gehört zu den weitverbreitetsten Techniken und wird oft bei Textverarbeitungsaufgaben verwendet. Für eine Berechnung können verschiedne Operatoren genutzt werden.

K = Ein Tastenanschlag oder Mausklick
P = Mit der Maus auf etwas zeigen
H = Wechsel der Hand zwischen den Eingabegeräten
D = Zeichnen auf einem Bildschirm
M = Mentale Vorbereitungszeit auf eine physische Aktion
R = Antwortzeit vom System

Beispielaufgabe: Ziehen einer Datei in einen Papierkorb

Sources:
Vorlesungsvideo – HCI 09-3 Quantifications
Wikipedia – Keystroke-Level-Model