Workflows (Draft)

Derzeit läuft es auf drei Benutzergruppen hinaus:

1. der Leser
2. der Lizenznehmer als Inhaltslieferant
3. "Admin" als Betreiber der Plattform

Benutzergruppe Leser

• Beispiel: Kommissar hat drei Fälle. Wenn ein Leser zwei davon gelesen hat, muss als erster “Weiterlink” auf jeden Fall der dritte Fall genannt werden. Schematische Darstellung: Wenn ein Nutzer erstmalig auf ein Themenfeld (Topic) klickt, wird ihm intern zufällig eine Story zugewiesen. Daraufhin wird der INTRODUCTION-Textnode der Story geladen. Von dort aus können die DEEPENING-Textnodes erreicht werden. Schließt der Leser den Browser, wird bei der nächsten Anmeldung der zuletzt angezeigte Textnode geladen. Bei der gegenwärtigen Darstellung müssen Textnodes auch um Logik-Komponenten ergänzt werden können, um die Bevorzugung des einzigsten noch nicht gelesenen Falls zu realisieren (wirkt sich auch auf [https://github.com/typearea/dembelo/issues/51](Issue #51) aus). Ein weiterer neuer Nicht-Textnode-Bausteintyp ist deshalb nicht eingeführt worden, weil die Textnodes sämtliche Logik enthalten müssen, wenn das INTRODUCTION-Merkmal herangezogen wird, um den Einsprungspunkt zu wählen (d.h. auf andere Baustein-Typen kann nicht verwiesen werden im Moment), und an derselben Stelle auch ausgewählt wird, welchen Fall der Nutzer zuerst zu lesen wünscht. Außerdem wird es sich hierbei wahrscheinlich nicht um einen rein generischen Baustein ohne längeren Text wie z.B. ein generisches Menü (zwecks Trennung von Lesetext und Logik) handeln, sodass auch hier der längere Text für die Ausschmückung der Wahl des Falles (müsste diese dann auch noch kontextualisiert werden?) aus der Datenbank kommen sollte. Wenn gemerkt werden muss, welche Entscheidungen welche Pfade unzugänglich machen, ist man schnell bei einem Textadventure-System und braucht bedeutend mehr Logik. Vielleicht sollte für die erste Version solche Logik ausgespart bleiben, vielleicht sollte sie aus dem Projekt gänzlich ausgeschlossen werden, sodass der Lesefluss rein aus Weiterleitungen besteht, die statisch angeordnet und vorgegeben sind. Der Nutzer kann für jedes Themenfeld (Topic) in unterschiedlichen Storys und Textnodes stehen und diese am letzten Textnode fortsetzen, wenn auf das entsprechende Themenfeld geklickt wird.
• Nach dem dritten Fall dieses Kommissars sollte es irgendwie die Möglichkeit geben, für einen vierten Fall zu votieren - unabhängig davon, was Lizenznehmer anbieten.
• Leser zahlt unter Vorbehalt für noch nicht geschriebene Knoten, beteiligt sich mit einem Betrag x an der Vorfinanzierung eines Strangs für die nächsten drei Monate. Er hinterlegt sich selbst eine Notiz dazu. Nach drei Monaten bekommt er eine Mail: “Willst du weiterhin? ja, nein”. Bei Nein oder keiner Antwort wird die Bezahlung verworfen.
• Der Leser kann auch von einem Blog beispielsweise kommen. Die Vorgehensweise muss beschrieben werden.

Benutzergruppe Lizenznehmer

• Neue DB-Tabelle “Lizenznehmer”
• wir legen einen neuen Lizenznehmer (LN) an
• wir schalten über eine einfache Oberfläche einen neuen Benutzer dieses Lizenznehmers frei
• LN-Benutzer bekommt Benutzerdaten
• kann bis zu zwei weitere Benutzer dieses LN anlegen
• LN-Benutzer loggt sich ein, kann LN-Metadaten pflegen
• LN-Benutzer sieht eine Liste bereits hochgeladener Twine-Dateien
• LN-Benutzer kann eine Twine-Datei ersetzen, um z.B. neue Knoten freizuschalten, hinzuzufügen, Tippfehler zu korrigieren
• LN-Benutzer kann eine neue Twine-Datei hochladen
• Dembelo validiert die Datei
• wieviel Einstiegstexte (wichtig für Lizenz)
• gibt die nicht validen Texte aus
• semantische Auszeichnung
• Orthographie- und Grammatikprüfung
• mind. 2 Verlinkungen; max. 8 Verlinkungen, davon 2 nach außen
• spätestens in der vierten Ebene muss ein Link nach außen führen
• Fragen:
• wie bindet der LN in der Twine-Datei einen externen Link ein?
• wie werden die Entscheidungen gepflegt?
• LN-Benutzer steuert über Tags innerhalb Twine, welche Knoten zu veröffentlichen sind.
• Tina: Tags sind unsicher
• LN-Benutzer sieht Statistiken, Abrechnungen, sonstigen Kram
• LN-Benutzer sieht eine Liste von Anfragen zur Verlinkung von anderen LN
• LN-Benutzer kann eigene Anfragen zur Verlinkung an andere LN schreiben/verwalten
• LN-Benutzer wird darüber informiert, wenn an einem Knoten genügend Geld zusammengekommen ist, um den Strang weiterzuschreiben
• LN-Benutzer erfährt statistisch, welche Stränge für den Leser interessant sind.