Teamprojekt

» Die möglichen Projektthemen sind auf einer separaten Seite zusammengefasst.

Organisatorisches

Arbeiten in Vierer-Teams

• Die Benutzung des Forums kann helfen Teampartner zu finden
• Bitte sofort mit den LV Leitern reden sprechen, wenn es Schwierigkeiten mit der Teamfindung gibt.
• InformatikerIn mit Nicht-InformatikerIn besonders erfahrenswert

Abgaben in 4 Meilensteinen

• M1 Problemanalyse
• M2 Low-fidelity Prototypen
• M3 App Entwicklung
• M4 Evaluierung, Weiterentwicklung & Abschlussbericht
• Details siehe: Meilensteine
• Bitte geben sie unbedingt bei jeder Meilenstein-Abgabe ihr Thema und alle (aktiven) Teammitglieder an!
• Benennen Sie Ihre Abgabe bitte nach dem folgenden Schema: [Gruppe]_[Projektthema]_[Meilenstein].fileendung, wobei [Gruppe] MO/MI/DO/FR sein kann und [Meilenstein] M1/M2/M3/M4.

Deadlines beachten:

• Deadline für die Abgabe ist jeweils 48h vor der nächsten VU (ausser bei Ferien oder Feiertagen), d.h.
  • Sa um 13:15 Uhr für die Mo-Gruppe (Löw/Möller)
  • Mo um 11:30 Uhr für die Mi-Gruppe (Kralj)
  • Di um 15:00 Uhr für die Do-Gruppe (Hödl/Kriglstein)
  • Mi um 16:45 Uhr für die Fr-Gruppe (Haselberger)
• Teamarbeit in VU und in den MO-MI-DO-FR-Gruppen planen
• Vorsicht: der Semesterschluss ist nur die technische Deadline; Meilenstein-Abgaben sind vorher zu den angegebenen Deadlines fällig.

Meilensteine

M1 Problemanalyse

• Analyse von vorhandener Literatur
  • Recherchieren sie wissenschaftliche und nicht-wissenschaftliche Texte, die sich mit ihrem Thema befassen. Fassen sie mindestens n Quellen (n = Anzahl der Personen im Team, d.h. 3-4) kurz zusammen und diskutieren sie die Folgen, die sie für ihr Projekt ziehen (ca. 1 Seite insgesamt).
  • Potentielle Quellen für wissenschaftliche Literatur sind: IEEE Xplore, ACM digital library, google scholar, CHI Conference Proceedings... Hinweis: Sie müssen möglicherweise u:access verwenden, um an Publikationen hinter Bezahlschranken zu gelangen.
• Analyse von Konkurrenz Produkten & der bisherigen Applikation (falls zutreffend):
  • Recherchieren sie, ob es ähnliche Systeme gibt und analysieren Sie diese. Wie sind diese Systeme zu ihrer Idee verwandt? Worin sehen sie die wesentlichen Vor- und Nachteile der Konkurrenzprodukte? Identifizieren sie potentielle Usability-Probleme dieser Systeme, sowie Usability Aspekte, die bereits gut abgedeckt sind.
  • Insgesamt sollen n Systeme (n = Anzahl der Personen im Team) analysiert werden.
• Nutzeranalyse und Kontextanalyse:
  • Führen sie eine Nutzeranalyse durch.
  • Fokussieren sie dabei auf Aufgaben und Ziele der Nutzer, sowie potentielle Probleme mit dem System.
  • Führen sie eine Kontextanalyse durch und dokumentieren sie das Ergebnis.
• Erstellen sie Personas, die die wichtigsten Nutzerszenarien abdecken: 3 primäre (für Teams mit 3 Personen oder weniger nur 2), 1 sekundäre, 1 negative Persona.
• Aufgabenanalyse (task analysis):
  • Führen sie eine Aufgabenanalyse in Form von Use-Cases (für die primären Personas) durch und bewerten/schätzen sie die Wichtigkeit der Aufgaben.
• Projektmanagement:
  • Basierend auf den obigen Aspekten, beschreiben sie kurz Kontext, Motivation, Ziele, und Nichtziele ihres Projekts.
  • Stellen sie sich als Teampartner im Projekt vor und teilen sie ihre Schwerpunkte und Lernwünsche mit.

M1 Abgabe:

Die Abgabe erfolgt über Gitlab in ihrem Gruppenprojekt im Branch M1

Erstellen Sie bitte 3 Ordner: Dokumente, Source, App

Laden Sie Ihre Lösung in einer pdf-Datei in den Ordner Dokumente im Branch M1 hoch.

Der Abgabe Branch wird erst nach 3 Tagen gesperrt, der letzte Commit in diesem Branch zählt als Abgabedatum

• Ein pdf mit folgenden Inhalten:
  • Angabe des Themas / Angabe der Teammitglieder (IST FÜR JEDEN MEILENSTEIN ERFORDERLICH)
  • Diskussion von relevanter Literatur (ca. 1 Seite Text)
  • Analyse & Diskussion von Konkurrenzprodukten (Screenshots + ca. 1 Seite Text)
  • Übersicht und Beschreibung von Benutzergruppen (ca. 1 Seite)
  • Kontextanalyse (kurz genügt, ca. 1/2 Seite)
  • Pro Persona eine Seite
  • Aufgabenanalyse: Tabelle zu Tasks/Use-Cases und Wichtigkeit/Häufigkeit
  • Beschreibung der Projektmanagement-Aspekte (kurz)
  • Beschreiben Sie die Arbeitsverteilung (wer hat was gemacht): kann zu Punkte-Umverteilung oder -Abzügen führen -- es muss klar beschrieben werden wer genau was gemacht hat, d.h. insbesondere, dass "wir haben alle gleich viel an M1 gearbeitet" nicht genügt und zu Punktabzug führen würde.
• Nur für Vortragende: Präsentationsfolien für max. 13 Min. (Folien können bis zum Datum der eigentlichen Präsentation hochgeladen werden, dafür gibt es selbstverständlich keinen Punktabzug!)

M1 Bewertungsschema:

• Diskussion von relevanter Literatur (ca. 1 Seite Text)
  • 20% Punkte: Identifikation und Beschreibung der Quellen, inkl. Diskussion der Implikation für das eigene Projekt
• Analyse & Diskussion von Konkurrenzprodukten (Screenshots + ca. 1 Seite Text)
  • 15%: Identifikation und Beschreibung von verwandten Systemen, inkl. Screenshots und Diskussion von Vor- und Nachteilen
• Nutzer und Aufgabenanalyse
  • 15%: Übersicht und Beschreibung von Benutzergruppen (ca. 1 Seite)
  • 15%: Aufgabenanalyse: Tabelle zu Tasks/Use-Cases und Wichtigkeit/Häufigkeit
  • 5%: Kontextanalyse (kurz genügt)
• Personas (ca. 2-3 primäre, 1 sekundäre, 1 negativ Persona)
  • 20%: 4-5% Punkte pro Persona. Anteilig bewertet nach Qualität (z.B. Bild dabei, präzise Beschreibung, etc.)
• Beschreibung der Projektmanagement-Aspekte
  • 5%: Kontext, Motivation, Ziele, und Nichtziele des Projekts
  • 2% Vorstellung der Teampartner im Projekt
  • 3% Aufgabenverteilung im M1

---

M2 Low-fidelity Prototypen

Die Abgabe erfolgt über Gitlab in ihrem Gruppenprojekt im Branch M2

Erstellen Sie bitte 3 Ordner: Dokumente, Source, App

Laden Sie Ihre Lösung in einer pdf-Datei in den Ordner Dokumente im Branch M2 hoch.

Der Abgabe Branch wird erst nach 3 Tagen gesperrt, der letzte Commit in diesem Branch zählt als Abgabedatum

• Ideensammlung: Generieren, skizzieren und diskutieren Sie ein breites Spektrum an Lösungsideen für Ihr Projekt. Benutzen Sie dazu mindestens eine dedizierte Kreativitätstechnik (basierend auf Eigenrecherche, ein guter Startpunkt ist zum Beispiel folgender Wikipedia-Artikel).
• Prototypen: Basierend darauf, erstellen sie n (n = Anzahl der Personen im Team, d.h. 3-4) von grundauf unterschiedliche und voneinander unabhängige low-fidelity Prototypen, die ihre Lösungsideen widerspiegeln (z.B. mit der "Fake It Till You Make It" Methode). Die low-fidelity Prototypen sollen so gestaltet sein, dass die Aufgaben von den primären Personas abgedeckt werden.
• Evaluierung der Prototypen: Führen sie Interviews mit n (siehe oben) Testusern (z.B. mit ihrer Kommilitonen aber nicht aus eigenem Team!) durch, in denen sie die Prototypen diskutieren, analysieren, und bewerten (jeder Testuser soll alle Prototypen testen).

M2 Abgabe:

• Ein pdf mit folgenden Inhalten:
  • Skizzen/Photos/... + Beschreibung der Ideensammlung (ca. 1-2 Seite Text exklusive Bilder)
  • Bilder + Beschreibung der low-fi Prototypen, sodass auch die Interaktion nachvollziehbar ist (ca. 1-2 Seite Text exklusive Bilder)
  • Beschreibung der Interviews hinsichtlich Vorgehensweise und Ergebnissen (ca. 1-2 Seite Text exklusive Bilder)
  • Beschreiben Sie die Arbeitsverteilung (wer hat was gemacht): kann zu Punkte-Umverteilung oder -Abzügen führen.
• Nur für Vortragende: Präsentationsfolien für max. 13 Min. (Folien können bis zum Datum der eigentlichen Präsentation hochgeladen werden, dafür gibt es selbstverständlich keinen Punktabzug!)

M2 Bewertungsschema:

• Ideensammlung (1-2 Seiten Text): 30%
  • Methodenwahl: 10%
  • Ergebnisse: 20%
• low-fi Prototypen (1-2 Seiten Text): 40%
  • Prototypen: 30%
  • Bezug auf primäre Aufgaben: 10%
• Beschreibung der Interviews (1-2 Seiten Text): 30%
  • Durchführung: 10%
  • Ergebnisse: 20%

---

M3 Erstellung der App

• Leiten sie aus der Ideensammlung und den low-fidelity Prototypen ein stimmiges Konzept für ihre App ab.
• Implementieren Sie die App mit dem von ihnen geplanten Spektrum an Aufgaben und Funktionen (high-fidelity Prototyp).
  • Stellen sie sicher dass ihr Interface die Komplexität des zugrundeliegenden Problems realistisch widerspiegelt (z.B. hinsichtlich der Anzahl an Songs im Falle des Million Song Themas).
  • Anmerkung: technische Details des Backends dürfen prototypisch realisiert werden (high-fidelity Prototyp der App).
• Begründen sie Design Entscheidungen und nehmen sie insbesondere Bezug auf die Aufgaben- und Nutzeranalyse aus M1!

M3 Abgabe

• Die Abgabe erfolgt über Gitlab in ihrem Gruppenprojekt im Branch M3
• Erstellen Sie bitte 3 Ordner: Dokumente, Source, App
• Geben Sie Ihr gesamtes Projekt im Source Ordner ab
• Erstellen Sie eine kompilierte Version Ihrer App und geben Sie diese im Ordner App ab
• Der Abgabe Branch wird erst nach 3 Tagen gesperrt, der letzte Commit in diesem Branch zählt als Abgabedatum

• Funktionsfähiger Prototyp (inkl. Code). WICHTIG: Es soll sich hierbei um einen fertigen Prototyp bzw. eine fertige App handeln. M4 ist nicht dazu da "noch zu implementieren was sie in M3 nicht geschafft haben". Ein unvollständiger Prototyp führt zu Punktabzug.
  • Geben sie ebenfalls eine Readme.md Datei mit ab. Folgen Sie dabei folgender Struktur: Readme-Grundgerüst.
  • Anmerkung: Ein nicht lauffähiger Prototyp gibt bis zu 75% Abzug der Gesamtpunkte. Für formelle Dinge wie schlecht lesbaren oder strukturierten Code (sinnvolle Klassen- und Methodennamen, Code ist kommentiert, Einrückungen etc.) gibt es bis zu 10% Abzug der Gesamtpunkte.
• Screenshots und Beschreibung des Prototyp hinsichtlich Funktionen, Inhalte und Interaktionen (pdf, ca. 2-3 Seiten Text und Screenshots)
• Beschreiben Sie die Arbeitsverteilung (wer hat was gemacht): kann zu Punkte-Umverteilung oder -Abzügen führen.
• Nur für Vortragende: Präsentationsfolien für max. 13 Min. (Folien können bis zum Datum der eigentlichen Präsentation hochgeladen werden, dafür gibt es selbstverständlich keinen Punktabzug!)

M3 Bewertungsschema (Änderungen vorbehalten)

• PT (Software) — 75%
  • Readme & code 10%
  • Fehlerfreiheit 20%
  • Vollständigkeit 20%
  • Komplexität/Qualität 25%
  • Backend gut (evtl. Sonderpunkte falls Backend sehr gut und Frontend aber etwas "gelitten" hat)
• Schriftliche Abgabe: PT Beschreibung — 25%
  • Designentscheidungen 20%
  • Rückbezug auf früher Meilensteine 5%

---

M4 Usability Evaluierung, Weiterentwicklung, und Abschlussbericht

• Benutzertest: Erstellen Sie n (n = Anzahl der Personen im Team, d.h. 3-4) Usability Test Aufgaben für Ihre App, die typische Nutzerszenarien darstellen. Des Weiteren erstellen Sie einen Fragenkatalog bzw. einen Interviewleitfaden, oder adaptieren Sie bestehende Fragebögen. Dabei sollen Fragen beinhaltet sein, die Sie nach jeder Aufgabe den Testbenutzer fragen bzw. für das Abschlussinterview der jeweiligen Testperson notwendig sind. Führen Sie eine Usability Studie mit mindestens 2n (d.h. 6-8) "typischen" Testnutzern durch (keine Testnutzer aus dem eigenen Team!).
• Leiten Sie Lösungsvorschläge ab, wie das Design entsprechend verbessert werden kann. Implementieren Sie (machbare) Verbesserungsvorschläge. Argumentieren Sie plausibel warum nicht-implementierte Verbesserungsvorschläge über den Projektrahmen hinausgehen würden.
• Erstellen sie einen Abschlussbericht, der folgende Aspekte beinhaltet. Der Bericht kann auf Deutsch oder Englisch geschrieben werden (letzteres bevorzugt).
  • Motivation
    • Background information about the problem, tasks, and users
  • Related work
    • Other solutions to this problem or similar problems
    • Any previous work that you incorporated into your solution?
  • Design
    • Description of the design of your final App
    • Reasons for your design choices, e.g. what you learned from the earlier prototyping steps
  • Implementation
    • Brief(!) description of how the App was implemented (toolkits, languages, platforms)
    • Any serious implementation challenges you encountered and how you handled them
  • Evaluation
    • Describe how you evaluated the App in M4
      • Briefly describe the 3-4 usability tasks + the questionnaire;
      • Describe how you conducted the study (number of participants, sequence of steps in the study, etc.)
    • Provide the results from this evaluation
      • Explain what you learned about your App: strengths and weaknesses
      • Explain implications for design that you derived from the findings, and how you further improved the App respectively
  • Reflection
    • Give a clear separation of tasks between the group members for the entire project: you have to detail who did what for this milestone.
    • What were important lessons you learned from this course
  • Conclusions and future work
    • Summarize the main strengths and weaknesses of your approach and implementation
    • Give an outlook concerning interesting next steps that could be done building up on your work
  • References

M4 Abgabe

• Die Abgabe erfolgt über Gitlab in ihrem Gruppenprojekt im Branch M4
• Erstellen Sie bitte 3 Ordner: Dokumente, Source, App
• Geben Sie Ihr gesamtes Projekt im Source Ordner ab
• Erstellen Sie eine kompilierte Version Ihrer App und geben Sie diese im Ordner App ab
• Der Abgabe Branch wird erst nach 3 Tagen gesperrt, der letzte Commit in diesem Branch zählt als Abgabedatum

• Weiterentwickelter Prototyp (funktionsfähiger Code).
  • Abgabe & Co. wie bei M3, insbesondere wieder inklusive einer Readme-Datei.
  • Es wird eine Live-Demo für max. 5 Min. in den Abschlussgesprächen benötigt, bringen sie bitte ein entsprechendes mobiles Device oder einen Laptop (für Emulation) mit.
• Abschlussbericht (pdf, max. 6 Seiten inkl. Bilder) der Nutzerstudie mit folgenden Inhalten, bitte benutzen sie das ACM CHI Proceedings Format zur Erstellung des Berichtes.
• Anhang (pdf)
  • Protokolle des Usability Tests;
  • Screenshots und Beschreibung (pdf, ca. 1 Seite plus Bilder) des weiterentwickelten Prototyps hinsichtlich Funktionen, Inhalte und Interaktionen, beschreiben Sie insbesondere die Unterschiede zu der Version aus M3
• Nur für Vortragende: Präsentationsfolien für max. 13 Min. (Folien können bis zum Datum der eigentlichen Präsentation hochgeladen werden, dafür gibt es selbstverständlich keinen Punktabzug!)

M4 Bewertungsschema (Änderungen vorbehalten)

• Durchführung und Ergebnisse der Studien — 20%
• Weiterentwicklung des Prototyps — 20%
• Abschlussbericht — 60%

---

» Alle Abgaben (PDFs, Folien, Code, etc.) haben im Gitlab zu erfolgen. Bei Fragen bitte an die Tutoren wenden.