Update Dokumentation authored by Hezel Tamara's avatar Hezel Tamara
......@@ -25,7 +25,7 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B
| Tamara Hezel | UX, Projektmanagement | Interdisziplinäres Projekt | 34331
## 4. Projektziel
...
< TODO
Aus Projektmanagement Sicht war es außerdem sehr interessant ein größeres Team zu organisieren, da Tamara bisher nur kleinere Teams betreute. Zudem war dieses Projekt eine gute Möglichkeit die gelernten agilen Methoden anzuwenden.
## 5. Projektablauf
......@@ -34,40 +34,47 @@ Der Projektablauf teilt sich in die Vorarbeit und eigentliche Arbeitsphase auf.
## 5.1 Vorarbeit
Vor der eigentlichen Arbeitsphase ging es darum ein einheitliches Verständnis von der Spielidee und dem Projektziel zu bekommen. Dazu erstellte Julian anfänglich ein Moodboard und zwei Personas, um unser Vorhaben und Zielgruppe greifbarer zu machen.
![Moodboard](uploads/d0a51d83082c9d293f078f493e0bddd5/Moodboard.png)
Das Moodboard orientierte sich an ähnlichen Spielen und fasst anhand von Screenshots für uns wichtige Elemente wie z.B. die verschiedenen Biome und die Comicheften Figuren als Kämpfer mit Waffen zusammen. Auf Basis dieser Zusammenstellung einigten wir uns auf einen Design Stil, Features und wesentliche Aspekte für die Entwicklung des Spieles. (... < Julian)
![Persona](uploads/f7fdf11edf9e0fcea1ae781af7cfc14e/WhatsApp_Image_2019-11-04_at_21.56.02.jpeg)
Sophia Martens, als eine der zwei Personas, repräsentiert Charaktereigenschaften, Ziele und Gewohnheiten unsere Zielgruppe und hilft uns auf einer einheitlichen Basis arbeiten zu können. Die spezifische Zielgruppe beeinflusst nicht nur Designelemente, sondern auch die Navigationsstruktur und konzeptuelle Aspekte wie z.B. der Schwierigkeitsgrad.
Das Moodboard orientierte sich an ähnlichen Spielen und fasst anhand von Screenshots für uns wichtige Elemente wie z.B. die verschiedenen Biome und die Comicheften Figuren als Kämpfer mit Waffen zusammen. Auf Basis dieser Zusammenstellung einigten wir uns auf einen Design Stil, Features und wesentliche Aspekte für die Entwicklung des Spieles. (... > Julian)
Die beiden Personas, repräsentiert Charaktereigenschaften, Ziele und Gewohnheiten unsere Zielgruppe und hilft uns auf einer einheitlichen Basis arbeiten zu können. Die spezifische Zielgruppe beeinflusst nicht nur Designelemente, sondern auch die Navigationsstruktur und konzeptuelle Aspekte wie z.B. der Schwierigkeitsgrad.
Auf Basis dieser Vorarbeiten wurden dann erste Tasks im Git Issue Board (siehe unten) erstellt und der grobe Zeitplan abgestimmt. Tamara gab zudem eine kurze Einführung in die Projektmanagement Tools und der allgemeinen Vorgehensweise. Außerdem wurde darüber geredet welchen Grafikstil wir verwenden wollen und welche Funktionen besonders wichtig oder weniger wichtig waren. Dabei war es sinnvoll Aufgaben, die für das Spiel als verpflichtend markiert wurden, auch mit dem Label "must-have" zu kennzeichnen, um den Überblick zu behalten. Da Alexander und Olivia letztes Semester schon ein Multiplayer Spiel entwickelten, fiel die Eingrenzung der Funktionen, aus Sicht der Entwicklung, dieses Mal viel leichter und wir konnten ohne Probleme starten. Julian und Tamara hatten zuvor noch nie ein Spiel mit solch einem großen UX Anteil entwickelt, warum sie sich anfänglich unsicher waren wie viele Iterationen von User Tests möglich waren.
## 5.2 Arbeitsphase
Die Arbeitsphase erfolgte in Iterationen mit regelmäßigen Austausch und Synchronisation zwischen den Departments. Näheres zu der verwendeten Projektmanagement Methode ist unter Punkt 5.3.4 zu lesen. Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgestellt. Dabei wird auch auf aufgetretene Problematiken, sowie die Lösung deren eingegangen. Alle erstellten Dateien, mit direkten Bezug auf die Erläuterung in der vorliegenden Dokumentation, wurden eingefügt. Größere Dokumente, Bilder oder zusätzliches Material ist im Ordner "Zusätzliche Abgaben" zu finden, indexiert über eckige Klammern.
### 5.2.1 Department "Design"
> Susanne/Niklas
> Susanne/Niklas: TODO
#### Charaktere & Eye Candy:
![UI_Kit___2](uploads/f68169a5368f32adfd9fe545cfdae9d4/UI_Kit___2.png)
### 5.2.2 Department "Entwicklung"
> Olivia/Alex
> Olivia/Alex: TODO
### 5.2.3 Department "UX"
> Julian/Tamara
#### State of the Art/Research
> Julian: TODO
#### Informations- und Navigationsarchitektur:
Tamara erstellte zu Projektbeginn eine Informations- und Navigationsarchitektur [1], um den Flow des Spiels festzuhalten. Im Laufe der Entwicklung merkte man aber relativ schnell, dass nicht alle Funktionen darin in der vorgegebenen Zeit zu implementieren waren.
Tamara erstellte zu Projektbeginn eine Informations- und Navigationsarchitektur [2], um den Flow des Spiels festzuhalten. Ersteres dient zur Identifikation und Definition von Seiten Inhalt bzw. Funktionalität. Im Laufe der Entwicklung merkte man aber relativ schnell, dass nicht alle Funktionen darin in der vorgegebenen Zeit zu implementieren waren. Trotzdem war es sehr hilfreich einen Überblick über mögliche Features zu haben, die in Zukunft noch implementiert werden könnten. Mithilfe der Navigationsstruktur war es Julian und Tamara möglich Fragen zur Nutzungspriorität, Anordnung und das allgemein verwendete Muster festzulegen, um Inhalte am besten finden zu können.
#### UI Kit:
Das UI Kit [2]
Das UI Kit [3] stellte einen einheitlichen Design-Leitfade dar. Durch Angaben zu Farb-Hexwerten und der Gestaltung von Buttons, Textfelder etc. erreichte Tamara eine einheitliche Basis zwischen UX und Design. Dies erwies sich auch später als sehr nützlich, da die Einteilung in primäre und sekundäre Farben die Gestaltung des Posters oder Factsheets maßgeblich vorgab und so alles sehr einheitlich erscheinen ließ. Auch hatten wir immer einen zentralen Ort, um Änderungen zu besprechen verhinderten somit Mehrarbeit und Missverständnisse.
#### Prototyping und User Testing
< TODO
Alle Dokumente und ausführlichen Testergebnisse finden sich unter Anhang [4].
### 5.3.4 Department "Projektmanagement"
> Tamara
#### Projektmanagement Methode:
Als Projektmanagement Ansatz wurde eine verschlankte Version von "Scrumban" verwendet. Die Kombination aus der agilen, flexiblen Arbeitsweise von "Scrum" und der Visualisierungskraft von "Kanban" war rückblickend für uns eine gute Wahl. Wir arbeiteten in Iterationen, was besonders für die Zusammenarbeit sehr hilfreich war. Somit war es uns möglich Features zu verschlanken und Feedback von Tester direkt in die nächste Welle der Implementierung oder des Designs einbauen zu können. Nachdem das Team "UX" durch Befragung von Tester zum Papierprototyp merkte, dass z.B. Pop-ups statt Full-Screen Menüanzeigen sinnvoller sind, konnte diese Erkenntnis gleich verbessert werden.
Mithilfe des Kanban Boards hatte jeder im Team zu jedem Zeitpunkt eine klare Übersicht über kommende Aufgaben und konnte seine/ihre Arbeit selbst strukturieren, was in unserem Projekt mit häufiger Remote-Arbeit eine große Hilfe war.
#### Allgemeiner Zeitplan:
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde von Tamara ein groben Zeitplan erstellt [3] und die wichtigsten Daten eingetragen. Dabei spielten besonders Abgaben und die Zeit zu Beginn des Projekts und vor der Medianight eine Rolle. Da wir anfänglich noch nicht genau abschätzen konnten wie viel Zeit die Einarbeitung in das Thema brauchte, wurde die Arbeitsphase selbst hier nicht abgebildet. Die Abgabetermine und einzelnen Tasks, innerhalb des Projektablaufs, wurden über Git Issues und Milestones organisiert (siehe unten). Sie kümmerte sich außerdem auch um die Projektanmeldung, und -koordination, sowie die Bearbeitung der Stage.
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde von Tamara ein groben Zeitplan erstellt [5] und die wichtigsten Daten eingetragen. Dabei spielten besonders Abgaben und die Zeit zu Beginn des Projekts und vor der Medianight eine Rolle. Da wir anfänglich noch nicht genau abschätzen konnten wie viel Zeit die Einarbeitung in das Thema brauchte, wurde die Arbeitsphase selbst hier nicht abgebildet. Die Abgabetermine und einzelnen Tasks, innerhalb des Projektablaufs, wurden über Git Issues und Milestones organisiert (siehe unten). Sie kümmerte sich außerdem auch um die Projektanmeldung, und -koordination, sowie die Bearbeitung der Stage.
Die knappe Zeitspanne von einem Semester ließ es leider nicht zu, jedes Feedback der Tester und die von Usability Sicht konzertierten Funktionen zu vollständig implementieren. Grund dafür waren die vielen Einzelheiten und der geplant große Funktionsumfang, der mit zwei Entwicklern nicht zu schaffen war. Wir fokussierten uns somit auf die wichtigsten Aspekte des Spiels. Nach Absprache mit Herr Prof. Kriha werden die Prototypen als zusätzliche Komponente zum aktuellen Entwicklungsstand gesehen. Es hat sich gezeigt, dass zur Realisierung eines zu umfangreichen Spiels inkl. Usability Testing mehr Zeit benötigt wird.
......@@ -89,16 +96,18 @@ Alle Dokumente werden primär auf einer geteilten GDrive Ablage abgelegt. Im UX
Für den MI-Präsentationstag erstellte Tamara ein Factesheet und Alexander und Niklas präsentierten unsere Idee vor den Studierenden und Professoren. Zur Präsentation an der Medianight erstellte Tamara außerdem noch ein Poster und organisierte die benötigten Materialen und den Ablauf. Dabei hatte sie anfänglich Probleme mit der Erstellung der Materialen, besonders mit der Druckdatei. Durch fehlende Vorkenntnisse mit Adobe Illustrator fiel ihr die Erstellung erst schwer, zumal eine Umwandlung in den YCYK Farbraum und ein spezifischer Anschnitt für das Drucken des Posters nötig war. Nach Einarbeitung in das Programm, war jedoch die Erstellung kein Problem mehr und sie konnte ihre Fähigkeiten in dem Bereich stark verbessern. Zudem stand sie in ständiger Kommunikation mit Frau Schlitter, um einen reibungslosen Ablauf zu ermöglichen. Uns war möglich das Spiel soweit fertigzustellen, dass es direkt an der Media Night ausprobiert werden konnte. Es fand durchweg positiven Anklang und begeisterte besonders durch die comichafte Grafik und die Idee des Nebels.
## 7. Lernerfolg
> TODO
## 8. Möglichliche Weiterarbeit
> TODO
## 9. Fazit
(...)
> TODO
Bedanken wollen wir uns außerdem bei Herrn Prof. Kriha, der uns jederzeit für Frage und Angregungen zur Seite stand.
## Anhangsverzeichnis:
[1] Informations- und Navigationsarchitektur
[2] UI-Kit
[3] Zeitplan
[]
[]
\ No newline at end of file
[1] Personas
[2] Informations- und Navigationsarchitektur
[3] UI-Kit
[4] Prototypen inkl. Testergebnisse
[5] Zeitplan
\ No newline at end of file