bearbeitet von: Jannis Hamann
Da es durch die aktuelle Lage schwierig ist an die Zielgruppe Schüler für Nutzertests heranzukommen, plane ich so weit es geht iterativ und ansonsten wasserfallartig vorzugehen.
Die Grundlage für die Anforderungsbestimmung ist der Wunsch nach Public Goods als Spielmodus. Was das genau bedeutet, werde ich in detaillierten Anforderungen ausarbeiten und ausformulieren. Dabei werde ich mich vor allem auf den bisherigen mündlichen Austausch mit Dr. Stefan Nessler, wissenschaftlichen Quellen zu Public Goods und Introspektion beziehen.
Die aktuelle Ansicht der Spieler zum Spielen unterstützt aktuell nur das Prisoners Dilemma und ist nicht kompatibel mit Public Goods. Um das zu beheben, gibt es 2 Möglichkeiten: 1 Design erstellen, was beide Modi vereint oder 2 Designs erstellen; für jeden Modus eins. Ich werde eine Begründung ausarbeiten, welche Variante für diese Anwendung geeigneter ist, Designs ausarbeiten und gegeneinander abwägen.
Aktuell höre ich gerade die Veranstaltung Human-Computer Interaktion, die sich viel mit Design beschäftigt. Dort haben wir Designrichtlinien kennengelernt, wovon noch weitere Folgen werden. Dies möchte ich auf das bestehende Interface anwenden, schauen ob diese erfüllt werden und gegebenenfalls das Design anpassen. Hier ist vermutlich gutes Potenzial für einen wissenschaftlich orientierten Teil in der Arbeit, was aber noch schwierig einzuschätzen ist, da ich die Veranstaltung noch nicht abgeschlossen habe.
Ansonsten müssen für die anderen Erweiterungen nur an bereits existierenden Seiten Veränderungen durchgeführt werden. Für diese muss kein neues Design angefertigt werden.
Nachdem das Design so weit fertiggestellt wurde, werde ich dieses im Forschungsgruppenseminar von Frau Müller-Birn, der Zweitkorekteurin, vorstellen und danach daraus resultierende Änderungsvorschläge umsetzen.
Im Backend muss die API um Public Goods erweitert werden. Das Frontend muss die neue API Änderung übernehmen, es müssen einige Views angepasst werden und das neue Design für Public Goods umgesetzt werden. Außerdem müssen bestehende Tests um Public Goods erweitert werden.
Geplant sind nebend er Designevaluation 3 Tests:
Einen vor Beginn der Arbeit, um ein Gefühl über die Akzeptanz und Verständlichkeit des Projektes aktuell zu bekommen. Einen zur Mitte der Arbeit, um noch rechtzeitig Änderungen durchführen zu können. Und einen zum Abschluss der Arbeit.
Für diese Tests werde ich vorher ein genauen Ablaufplan mit Skript ausarbeiten.
Idealerweise werden diese Tests alle mit Herr Nessler durchgeführt und als Think aloud Tests mit einer Person gleichzeitig ablaufen. Zusätzlich zu Herr Nessler (der diesem Vorschlag zum aktuellen Zeitpunkt noch nicht zugestimmt hat) werde ich die App auch mit weiteren Einzelpersonen testen.
Jamie, der seine Masterarbeit über das gleiche Softwareprojekt schreibt, hat vorgeschlagen den Abschlusstest von mir gemeinsam durchzuführen. Ob das klappt ist abhängig davon, ob er dann schon soweit in seiner Arbeit ist, dass man diese im Web schon testen kann.
Zeitrahmen | Milestone | Ziele | Status |
---|---|---|---|
22.7. - 31.7. | Analyse | Planung, Heuristische Analyse, Usability Tests, Recherche Public Goods | - |
3.8. - 14.8. | Design | Anforderungen definieren, Anpassung bisherige Views, Ausarbeitung Public Goods View, Feedback Stefan, Feedback HCI Gruppe | - |
17.8. - 28.8. | Implementierung | Git Setup, Frontend + Backend neue + alte Views, Usability Tests, Feedback Stefan | - |
31.8. - 11.9. | 2. Iteration | Änderungen umsetzen, Finaler Test mit Stefan | - |
14.9. - 2.10. | Text schreiben | Inhalt der Arbeit, Dokmentation updaten, Drucken o.ä. | - |
5.10. - 13.10. | Pufferzeit | - | |
14.10. | Abgabe | - |
…