Sowohl im Bachelor als auch im Master werden bei uns eine Reihe von Wikis geschrieben. Hier allgemeine Tipps dazu:

Jedes Projekt-Wiki sollte enthalten:

  • Projekttitel, gerne mit sinnvollem Untertitel.
  • Kurstitel, Studiengangstitel (und zwar bitte korrekt)
  • Komplette Namen aller Projektteilnehmer mit Funktionen und Matrikelnummern. Mindestens eine Kontaktadresse.
  • BetreuerInnen.
  • Projektzeitraum.
  • Video / eingebettete Software / Screenshots (mehr dazu unten).
  • Abstract / Kurzbeschreibung (1-2 Absätze), gerne auch nur auf Englisch.
  • Genre / Projektart, relevante Plattformen / Technologien.
  • Inhaltsverzeichnis (außer bei kurzen Arbeiten).
  • Quellenverzeichnis und Abbildungsverzeichnis (außer bei kurzen Arbeiten oder wenn's keine Quellen oder Abbildungen gibt).
  • Abbildungen mit Bildunterschriften.

  • Als Zitationsstil bevorzugen wir den „APA Stil“.

  • Titelmotive (Banner odgl.) sind meist erfreulich, aber kein Muss.

Während des Projekts

Während eines Projekts sollte ein Projekt-Wiki eher ein internes Konzeptions-, Planungs-, Management und Dokumentations-Tool sein. Es wird sich entsprechend meist an das Team selbst und die BetreuerInnen wenden, vielleicht stellenweise auch schon an externe TeilnehmerInnen, zum Beispiel AuftraggeberInnen oder Zulieferer/Zulieferinnen.

Anfangs wird es also meist Skizzen, Recherchequellen, Vorbilder, Mood-Boards, Links, frühe Projektpläne, frühe Produktionslisten, SWOT-Analysen usw. enthalten.

Meist entsteht so auch eine Seite, bei der das Ergebnis ganz unten steht. Das ist für die interne Phase auch in Ordnung. Derartige Seiten enden dann oft mit den letzten Ergebnissen aus der Präsentation, Findings aus den Anwendungstests, den letzten To-Do-Listen aus der Polishing/Verfeinerungs-Phase und idealerweise mit Lessons Learned / Findings und evtl. mit einem Ausblick (was konnte nicht mehr umgesetzt werden, wäre aber wichtig für kommende Projektphasen).

Nach dem Projekt: Projektdokumentation

Nachdem die Projektbearbeitungszeit abgeschlossen ist, sollte das gesamte Wiki umgearbeitet werden in eine nach außen und an neue InteressentInnen gerichtete Projektdokumentation. Das Dokument richtet sich nun an Außenstehende, die das Projekt zum ersten Mal kennenlernen. Das heisst vor allem: die besten / letzten Ergebnisse ganz nach oben und erledigte Inhalte oder Detaillisten nach unten oder auf Sub-Seiten.

Wenn Sie ein (Anwendungs-/Ingame-) Video haben (und das sollten Sie immer, viele Software läuft nach 1-2 Jahren nur noch mit Zusatzaufwand) oder eine benutzbare Software: ganz nach oben damit! Immer flankiert von ein paar aussagekräftigen und kommentierten Screenshots (bei Software) oder Fotos (bei Installationen usw.).

Inhaltliche Vorgaben

Es gibt keine ganz strengen, verpflichtenden Vorgaben. Finden Sie gerne einen für Ihr Projekt passenden Weg. Hier ist jedoch eine Struktur, die oft gut funktioniert:

  • Zuerst Idee, Zielsetzung, Scope, Vorbilder, Abgrenzung (meist: was ist es nicht), Verweise auf relevante Quellen (im Detail dann gerne am Ende).
  • Spezifikation Ihres Projekts, zum Beispiel mit Feature List / Pflichtenheft, MoSCoW, ggf. Alleinstellungsmerkmal(e).
  • Dann meist eine Dokumentation / Darstellung des Erreichten, was bei Software oft ein Werk(statt)bericht ist. Konzept und Umsetzung sollten da wesentliche Elemente sein und es ist meist vorteilhaft, wenn Konzept und Umsetzung plausibel miteinander verzahnt sind.
  • Falls es einen Test oder ein Experiment gab – was oft eine gute Idee ist: Darstellung des Aufbaus und der Ergebnisse sowie kritische Diskussion.
  • Danach ist meist ein 3 bis 5-Minuten-Video oder eine spiel-/nutzbare Version mit den besten Momenten gut. Diese können dann gerne, wie oben ja auch schon gesagt, direkt ganz am Anfang gebracht werden. Direkt im Browser ist hier meist besser als erst downloaden und installieren. Falls Download unabdingbar ist, sollte umso mehr ein Video bereitstehen.
  • Zum Schluss ein Fazit, was geschafft wurde und ein Ausblick, was für die Zukunft offen ist.

Formelle Vorgaben

  • Wir bevorzugen kürzere, besser geschriebene Arbeiten vor längeren, redundanten und nachlässig geschriebenen.
  • Wir bestehen auf sorgfältig recherchierten, geschriebenen und gegengelesenen Texten. 
Anderenfalls nehmen wir die Dokumentation nicht zur Bewertung an.
  • Bullet-Listen sind meist etwas übersichtlicher als fortlaufender Text (so wie hier gerade).
  • Wir mögen gute Abbildungen, Grafiken, Diagramme und Tabellen, die unnötig lange Texte abkürzen.
  • Rechnen Sie die Auflösung Ihrer Grafiken passend runter und verwenden Sie JPGs statt PNGs, so es sinnvoll ist.
  • Bitte benutzen Sie im Wiki die Standard-Formate und wenden Sie keine komplizierten Layouts (wie Spalten) oder Sonderformate an. 
  • No labels