Update Dokumentation authored by Hezel Tamara's avatar Hezel Tamara
...@@ -31,7 +31,7 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B ...@@ -31,7 +31,7 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B
## 5.1 Vorarbeit ## 5.1 Vorarbeit
## 5.2 Arbeitsphase ## 5.2 Arbeitsphase
Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgestellt. Dabei wird auch auf aufgetretene Problematiken, sowie die Lösung deren eingegangen. 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.
### 5.2.1 Department "Design" ### 5.2.1 Department "Design"
> Susanne/Niklas > Susanne/Niklas
...@@ -44,7 +44,12 @@ Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgeste ...@@ -44,7 +44,12 @@ Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgeste
### 5.2.3 Department "UX" ### 5.2.3 Department "UX"
> Julian/Tamara > Julian/Tamara
#### Moodboard: #### Moodboard:
Julian erstellte das Moodboard und zwei Personas, um unser Vorhaben und Zielgruppe greifbarer zu machen.
![Moodboard](uploads/d0a51d83082c9d293f078f493e0bddd5/Moodboard.png) ![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. (...)
![WhatsApp_Image_2019-11-04_at_21.56.02](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.
#### UI Kit: #### UI Kit:
![UI_Kit_1](uploads/1f9fb727978c42bc78e9f9187bb36921/UI_Kit_1.png) ![UI_Kit_1](uploads/1f9fb727978c42bc78e9f9187bb36921/UI_Kit_1.png)
...@@ -53,24 +58,26 @@ Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgeste ...@@ -53,24 +58,26 @@ Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgeste
### 5.3.4 Department "Projektmanagement" ### 5.3.4 Department "Projektmanagement"
> Tamara > Tamara
#### Allgemeiner Zeitplan: #### Allgemeiner Zeitplan:
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde ein groben Zeitplan erstellt und die wichtigsten Daten eingetragen [Bild Zeitplan GDrive]. 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). Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde von Tamara ein groben Zeitplan erstellt 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).
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. 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.
#### Git Issue Board: #### Git Issue Board:
Git Issues werden als Liste und Board in Git strukturiert. Dabei stellt Letzteres ein einfaches Kanban Board dar, das mit verschiedene Spalten und Labels für die Organsiation von anfallenden Aufgaben verwendet werden kann. Für unser Projekt erstellte Labels wie z.B. "Design", "UX", "Development", "Organizational", "Must-have" oder "could-have", um Priorisierung und die Zuordnung der verschiedenen Departments deutlich zu machen. Außerdem ist es möglich ein Ticket direkt einem Teammitglied zuzuweisen, sowie Duedates und Milestones anzuhängen. Das Erstellen der Tickets stellten keine Schwierigkeit dar. Jedoch könnte man das nächste Mal z.B. "ready for test or review" einfach in "blocked" integrieren, um die Anzahl der Spalten zu reduzieren und die Übersichtlichkeit zu erhöhen. Als weitere Ebene der Organisation nutzten wir Milestones. Dazu haben wir den MI Präsentationstag, die Media Night und Projektabgabe angelegt. Granularere Milestones waren in diesem Projekt nicht nötig. Die Zeitplanung und -Organisation der Aufgaben sollte so einfach wie möglich gehalten werden. Git Issues werden als Liste und Board in Git strukturiert. Dabei stellt Letzteres ein einfaches Kanban Board dar, das mit verschiedene Spalten und Labels für die Organsiation von anfallenden Aufgaben verwendet werden kann. Initial setzte Tamara das Board auf und erstellte Labels wie z.B. "Design", "UX", "Development", "Organizational", "Must-have" oder "could-have", um Priorisierung und die Zuordnung der verschiedenen Departments deutlich zu machen. Außerdem ist es möglich ein Ticket direkt einem Teammitglied zuzuweisen, sowie Duedates und Milestones anzuhängen. Das Erstellen der Tickets stellten in unserem Projekt keine Schwierigkeit dar, auch wenn die Issues von den Teammitglieder unterschiedlich stark. genutzt wurden. Insgesamt hat die Organisation der Aufgaben darüber aber reibungslos funktioniert und nichts Wichtiges wurde vergessen. Jedoch könnte man das nächste Mal z.B. "ready for test or review" einfach in "blocked" integrieren, um die Anzahl der Spalten zu reduzieren und die Übersichtlichkeit zu erhöhen. Als weitere Ebene der Organisation nutzten wir Milestones. Dazu haben wir den MI Präsentationstag, die Media Night und Projektabgabe angelegt. Granularere Milestones waren in diesem Projekt nicht nötig. Die Zeitplanung und -Organisation der Aufgaben sollte so einfach wie möglich gehalten werden.
#### Git Wiki: #### Git Wiki:
Alle (Teil-)Dokumentationen und Zwischenergebnisse wurden über das Git Wiki festgehalten, um nichts Wichtiges zu vergessen und strukturiert arbeiten zu können. Das stellte besonders im Bereich UX sehr eine große Hilfe dar, um die Recherche und User Test Ergebnisse zu dokumentieren. Dazu wurde Markdown als allgemeingültige Syntax verwendet. Alle (Teil-)Dokumentationen und Zwischenergebnisse wurden über das Git Wiki festgehalten, um nichts Wichtiges zu vergessen und strukturiert arbeiten zu können. Das stellte besonders im Bereich UX sehr eine große Hilfe dar, um die Recherche und User Test Ergebnisse zu dokumentieren. Dazu wurde Markdown als allgemeingültige Syntax verwendet.
#### Teamkommunikation: #### Teamkommunikation:
Die interne Kommunikation wurde komplett über Whatsapp abgehandelt. War zuerst die Idee "Slack" zum Austausch im Team zu verwenden, wurde schnell klar, dass sich WhatsApp dafür besser eignete. Grund dafür war die höhere Präsenz und Regelmäßigkeit auf der Plattform. Slack wurde vom Team hingegen kaum akzeptiert und stellte dabei somit keine praktikable Alternative dar. Wir haben uns zudem jede 2. Woche als ganzes Team remote oder persönlich für wichtige Absprachen getroffen, was sehr gut funktionierte. Die Synchronisation zwischen den einzelnen Departments erwies sich als sehr wichtig, um an einem gemeinsamen Ziel arbeiten zu können. Besonders die Absprache zwischen Design und UX war von Bedeutung, um einzelne Komponenten in das Prototyping rechtzeitig einbauen zu können. Meetings innerhalb der verschiedenen Subteams fanden häufiger statt und wurden selbst organisiert. Die interne Kommunikation wurde komplett über Whatsapp abgehandelt. Tamara hatte zuerst die Idee "Slack" zum Austausch im Team zu verwenden, jedoch wurde es schnell klar, dass sich WhatsApp dafür besser eignete. Grund dafür war die höhere Präsenz und Regelmäßigkeit auf der Plattform. Slack wurde vom Team hingegen kaum akzeptiert und stellte dabei somit keine praktikable Alternative dar. Wir haben uns zudem jede 2. Woche als ganzes Team remote oder persönlich für wichtige Absprachen getroffen, was sehr gut funktionierte. Die Synchronisation zwischen den einzelnen Departments erwies sich als sehr wichtig, um an einem gemeinsamen Ziel arbeiten zu können. Besonders die Absprache zwischen Design und UX war von Bedeutung, um einzelnen Komponenten in das Prototyping rechtzeitig einbauen zu können. Meetings innerhalb der verschiedenen Subteams fanden häufiger statt und wurden selbst organisiert.
Die Absprache mit Herr Prof. Kriha erfolgte ebenfalls nach Absprache und war besonders am Anfang sehr hilfreich, um Anforderungen zu klären und die Erwartungen auf beiden Seiten zu synchronisieren.
#### Datenablage: #### Datenablage:
Alle Dokumente werden primär auf einer geteilten GDrive Ablage abgelegt. Im UX Bereich hat es Sinn gemacht direkt die Cloud Funktion von AdobeXD zu verwenden, um immer an der neusten Version der Prototpyen arbeiten zu können. Dazu gehörte neben den Prototypen auch das Moodboard, Personas oder das UI Kit. Alle Dokumente werden primär auf einer geteilten GDrive Ablage abgelegt. Im UX Bereich hat es Sinn gemacht direkt die Cloud Funktion von AdobeXD zu verwenden, um immer an der neusten Version der Prototpyen arbeiten zu können. Dazu gehörte neben den Prototypen auch das Moodboard, Personas oder das UI Kit.
## 6. Medianight ## 6. MI-Präsentationstag & Medianight
Zur Präsentation an der Medianight erstellten wir ein Werbeplakat und stellten unser Spiel vor. 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. Für den MI-Präsentationstag erstellte Tamara ein Factesheet und Alexander präsentiere 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. 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 ## 7. Lernerfolg
... ...
......