-
Notifications
You must be signed in to change notification settings - Fork 4
Workflows (Draft)
Derzeit läuft es auf drei Benutzergruppen hinaus:
- der Leser
- der Lizenznehmer als Inhaltslieferant
- "Admin" als Betreiber der Plattform
- 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 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.
Tina:
- Auf KEINEN FALL gibt es generische Menüs außerhalb der Optionen am Textende.
- Auf KEINEN FALL gibt es Kontextualisierung bei den Optionen am Textende.
Was wir jedoch bedenken müssen und was sich ggf. auf die Datenbankgestaltung auswirkt, ist, dass unsere Inhalte frei sind. Das heißt, dass wenn LN1 Kommissar Sos entwickelt und einen Fall A mit diesem schreibt, kann LN2 Kommissar Sos wiederverwenden und Fall B dazu schreiben, was bedeutet, dass sowohl Fall A wie auch Fall B eine eigene INTRODUCTION-Textnode hat, die im "Topic: Krimi" gleichberechtigt sind. Durch die zufällige Auswahl innerhalb des Topics, kann man also nicht wissen, ob der Leser Fall A oder Fall B zuerst liest, am Ende des Falls sollte ihm aber der jeweils andere angeboten werden, sofern dieser noch nicht im Lesepfad des Nutzers enthalten ist. Dabei nehmen wir keine Rücksicht auf Kontextualität, es ist also egal, ob Fall A vor Fall B spielt oder sonst irgendwie in Beziehung steht. Diese Beziehungen haben die jeweiligen LN zu berücksichtigen, wenn sie entscheiden, ob sie einen Fall als eigenen Einstiegstext einpflegen oder sich per Link "einhängen".
Vergleiche:
Fragen:
- Was passiert, wenn ein anderer Fall im Lesepfad nicht beendet wurde? Er sollte dann angeboten werden, aber wie stellt man das fest? Definiert man Endtexte für Storys?
- Jeder Text kann per URL erreicht werden und ist kostenlos, egal ob Einstiegstext oder Vertiefung.
- Ein Leser kann am Textende den Text "teilen" dafür wird die URL per Schnittstelle nach Außen geliefert und kann z.B. bei Facebook oder in einem Blogartikel eingebunden werden.
- Ein Leser des Blogs oder des Facebookprofils klickt diesen Link an und landet in dem entsprechendem Text
- Vor dem Text, erscheint ein verlinkter Hinweis: "Achtung, Text erfordert Vorwissen."
- Folgt man der Hinweisverlinkung erscheint ein Popup mit der Information, dass man einem externen Link in einen vertiefenden Textteil gefolgt ist und man ggf. die Hinweise des Verlinkenden berücksichtigen soll, und dass man am Ende des Textteils zum Einleitungstext springen kann.
- Am Textende wird die Option angeboten zu einem geeigneten Einstiegstext zu springen
Fragen:
- Was mache ich mit Textkonstrukten wie 1000 Tode? Da erfordern die einzelnen Texte kein Vorwissen, der LN kann aber nicht alle Texte ein Einstiege definieren?
- Was mache ich, wenn der Leser exakt diesen Pfad lesen möchte der zu diesem Textteil führt? Export des Pfades als epub/PDF/txt/etc.? Kosten? Leitsystem?
- 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 die vierte Verlinkung muss 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.