Abstrakte Wikipedia/Frühe Modelle
Hier sind ein paar sehr frühe Modelle für das Wikifunctions-Wiki.
Funktionen
Die Multiplikationsfunktion
Funktionsdefinition
Die Kopfzeile zeigt die Bezeichnung und den Typ des Objekts (hier eine Funktion). Eine Funktion enthält ihre Signatur als ihren Typ. Darunter sehen wir die Dokumentation.
Es folgen die Argumente der Multiplikationsfunktion, der Rückgabetyp und eine Liste der verfügbaren Implementierungen. Darunter sehen wir eine Liste von Tests mit einer Matrix der Implementierungen und schließlich am Ende ein Formular, in dem der Leser die vorhandene Funktion auswerten kann.
Implementierung in JavaScript
Dies ist eine der Implementierungen der oben definierten Multiplikationsfunktion, hier in JavaScript.
Komposition
Dies ist eine weitere Implementierung der Multiplikationsfunktion, diesmal zusammengesetzt aus anderen Funktionen im Wiki.
Test
Hier ist ein Beispiel für einen Test für die Multiplikationsfunktion.
Nachfolge
Beachte, dass alle NLG-Objekte einen bestimmten Ansatz kodieren. Dabei geht es nicht darum, vorab eine Entscheidung über den konkreten NLG-Ansatz zu treffen, sondern lediglich darum, Ideen zu veranschaulichen und zu visualisieren. Der konkrete NLG-Ansatz, den wir verfolgen werden, steht noch nicht fest.
Konstruktor
Dies ist der Nachfolgekonstruktor. Es ist ein ziemlich komplexer Konstruktor, der zu einer Klausel führt.
Englischer Renderer
Dies ist ein englischer Renderer für den Nachfolgekonstruktor. Er ist sehr stark vereinfacht und dient nur dazu, die Idee grob darzustellen.
Konjunktion
Beachte, dass alle NLG-Objekte einen bestimmten Ansatz kodieren. Dabei geht es nicht darum, vorab eine Entscheidung über den konkreten NLG-Ansatz zu treffen, sondern lediglich darum, Ideen zu veranschaulichen und zu visualisieren. Der konkrete NLG-Ansatz, den wir verfolgen werden, steht noch nicht fest.
Dies ist ein englischer Renderer für den Konjunktionskonstruktor. Er ist sehr stark vereinfacht und dient nur dazu, die Idee grob darzustellen.
Dies ist im Grunde das Gleiche, es gibt jedoch eine Option bezüglich des Oxford-Kommas.
Hauptseite
Objekt erstellen
Ein neues Objekt ist erstellt. Wir müssen zunächst den Typ auswählen.
Wir haben uns für den Typ "Test" entschieden. Die entsprechenden Schlüssel werden automatisch angezeigt.
Im ersten Schlüssel, "Funktionsaufruf", beginnen wir mit der Eingabe und wählen als Funktion "Multiplizieren" aus. Automatisch werden die relevanten Argumente für die Multiplikation angezeigt.
Wir beginnen mit der Eingabe des ersten Werts. Dies wird als Literal vom Typ positive Ganzzahl analysiert.
Nun geben wir im zweiten Argument "hinzufügen" ein. Dies wird als Funktion erkannt. Felder für die entsprechenden Argumente werden hinzugefügt. Wir fügen Literale hinzu.
Die Ergebnisbedingung ist der zweite Schlüssel des Testobjekts. Wir beginnen mit der Eingabe eines Funktionsnamens und wählen ihn aus. Die Ergebnisbedingung ist vom Typ Funktion, die ein Objekt übernimmt und eine Liste von Fehlern zurückgibt. Wir geben "gleich int" ein, wählen die Funktion aus und es wird das eine Argument dieser Funktion angezeigt.
Nachdem wir nun ein Literal eingegeben haben, ist das Objekt vollständig und validiert. Es zeigt die Schaltfläche zum Veröffentlichen an.
Objekt anschauen
Das Folgende ist eine Ansicht des frisch erstellten Testobjekts. Es wird davon ausgegangen, dass der Name ein Rendering des Tests ist. Es sieht wirklich nicht schön aus, kann aber automatisch durchgeführt werden. Beachte, dass die Ansicht des Objekts eine spezifische Ansicht für Tests ist.
Hierbei wird die generische Ansicht für ZObjekte verwendet, vorausgesetzt, dass es keine spezifische Ansicht für Testobjekte gibt.
Dies ist die Ansicht, nachdem sich jemand die Mühe gemacht hat, eine schönere Bezeichnung zu erstellen, ein wenig Dokumentation zu schreiben (warum dieser Test relevant ist) und den Test zur Multiplikationsfunktion hinzuzufügen.
Objekt ändern
Dies ist die Benutzeroberfläche, die wir erhalten, wenn wir das Testobjekt bearbeiten. Dies bedeutet jedoch nicht, dass die Bezeichnung des Objekts oder die Dokumentation nicht bearbeitet werden können. Dies ist die generische Bearbeitungsoberfläche für ZObjekte. Beachte, dass es im Wesentlichen mit der Erstellungsoberfläche identisch ist.
ZObjekte können recht umfangreich werden. Es ist möglich, die Zweige des ZObjekts zu reduzieren. Hier haben wir den Teil reduziert, der die Addition im zweiten Term der Multiplikation durchführt.
Magisches Eingabefeld
Ein zentraler Bestandteil der oben genannten UX ist das magische Eingabefeld. Warum sind diese Eingabefelder magisch? Schauen wir uns genauer an, was sie können: Sie können vier Arten von Eingaben verarbeiten. Jedes Eingabefeld hat einen erwarteten Typ (im schlimmsten Fall ist der erwartete Typ “Beliebig”).
- Ein Verweis auf ein ZObjekt mit dem erwarteten Typ, d. h. eine ZID, die anhand ihrer Bezeichnung oder ihres Alias (oder ihrer ID) ausgewählt wird und eine Dropdown-Auswahl verwendet (wie bei der Auswahl eines Datenobjektes in Wikidata).
- Ein Funktionsaufruf, der zu einem ZObjekt des erwarteten Typs führt. Dies beginnt mit der Auswahl eines Verweises auf ein ZObjekt einer Funktion, deren Rückgabetyp den erwarteten Typ hat und sobald dieser ausgewählt ist, wird die Benutzeroberfläche aktualisiert, um die Angabe der Argumente zu ermöglichen.
- Ein Literal. Wenn der erwartete Typ als Literal dargestellt werden kann (z. B. für eine Zeichenkette oder eine Ganzzahl), kann dieses Literal einfach in das Eingabefeld eingegeben werden. Wenn es sich bei dem Literal möglicherweise auch um eine Referenz des richtigen Typs handelt, wird im Dropdown-Menü das Literal als erste Option aufgeführt. (Ob der erwartete Typ als Literal dargestellt werden kann, hängt davon ab, ob eine Funktion zum Parsen von Werten angegeben ist, die eine Zeichenkette entgegennimmt und eine Instanz des erwarteten Typs zurückgibt.)
- Ein Power-User kann jedes dieser eingebetteten magischen Eingabefelder in ein größeres Textfeld umwandeln und eine Rohbearbeitung durchführen. Sieh dir dazu das folgende Modell an.
Da die Magie manchmal etwas falsch macht (stell dir vor, du hättest beispielsweise einen erwarteten Funktionstyp (beliebig, beliebig), d. h. eine beliebige Funktion, wird es immer unklar sein, ob du tatsächlich auf eine Funktion verweist oder ob du einen Funktionsaufruf durchführst, um eine Funktion zu erzeugen, und daher könnten wir im falschen Modus landen. Das magische Eingabefeld verfügt über einen Schalter 𝌹, der es ermöglicht, einen der vier Modi explizit zu sperren (die Anzahl der Modi kann je nach erwartetem Typ unterschiedlich sein, d. h. wenn der erwartete Typ eine Funktion oder beliebig ist, gibt es keinen Literalmodus, etc.) und du kannst auch den erwarteten Typ ändern.
Dies zeigt eine funktionale Syntax für die Rohbearbeitung. Beachte, dass dies nur eine UX-Sache ist — die Eingabe wird vor dem Speichern analysiert und kanonisiert. Aber gerade beim Codieren kommen viele Leute nicht ohne Kopieren und Einfügen etc. aus und sonst hat das noch keine Benutzeroberfläche hinbekommen, also bieten wir diese Option an.
Dies ist das Gleiche wie das vorherige Modell, aber statt einer Funktionssyntax und Inhalten mit Bezeichnungen ist es so roh wie möglich und verwendet JSON und die ZIDs. Nun, irgendwann sollte es eine Möglichkeit sein.
Designalternativen
Die folgenden beiden Modelle zeigen einige alternative Designideen, um die Gruppierung der Formen deutlicher zu machen, indem hier die zusammengehörenden Formen mit einem gestrichelten Rahmen umrandet werden. Es zeigt auch deutlich, was das Einklappen bedeuten würde.
Hier verschieben wir das Symbol, um ein Feld einzuklappen, nach links.
Mobile Modelle
Dies sind Entwürfe für die mobile UX. Wir haben viel weniger horizontalen Platz, daher könnte es problematisch sein, den Baum nach Einrückung zu gruppieren.
-
Hier verwenden wir Felder und minimale Einrückungen. -
Hier verschieben wir das einklappbare Element nach links, um etwas mehr Platz zu schaffen. -
Hier ist eines der Felder eingeklappt, um zu veranschaulichen, wie es aussehen würde.
