Abstract English

Software has developed a variety of methodologies for storing and providing access to past states (versions) of self-contained data.
Whether or not existing Version Control Systems like Git are implemented, the version history interface has not been much of a place for experimental features.
I propose a new way of accessing a Markdown editor document's version history by introducing elementwise storage of its content along with an experimental interface.
Here, a paragraph or any other enclosed structuring section is considered an element and its past states are versioned and accessible independently.
This way, a document is not forced to be reverted as a whole. Moreover, any ever so small content of the past can be extracted and inserted to make for a better new version rather than replacing it.

Vorabinformation

Hier werden Ausschnitte und ausgewählte Kapitel aus der Bachelorarbeit in zusammenfassender Form abgebildet.
Ich möchte ermutigen, die vollständige Arbeit unter https://fhp.incom.org/action/open-file/366438 eizusehen.

Während sich die Möglichkeiten zur Vervielfältigung von Daten — wie die des Kopierens, des Sicherns und des Teilens — fest im Interface etabliert und ausgeprägt haben, hat das Zurückspringen auf ältere Zustände des Dokuments dort kaum Beachtung erfahren. Nicht selten ist die Versionshistorie nur schwer zu erreichen und sind die Aktionsmöglichkeiten eingeschränkt. Dass hier Potential verloren geht, ist anzunehmen, da aus der potentiell schöpfbaren Fülle an Daten, die bei der Aufzeichnung aller Nutzerinteraktionen und den damit verbundenen Metadaten entstehen können, im Ergebnis ein größerer Mehrwert als die vollständige Revertierung des gesamten, aktuellen Dokumentes geschaffen werden kann.

copy and paste

Ein markantes Beispiel für das Nachzügeln von gestalterischen Lösungen für Probleme, die technisch bereits lange gelöste sind, ist die Einführung des mobilen Betriebssystems iOS mitsamt dem ersten iPhone im Juni 2007. Erst in der Version 3.0, welches ganze zwei Jahre später herausgegeben wurde, bot das Betriebssystem die Optionen des »Ausschneiden«, »Kopieren« und »Einfügen« von Text im Interface an. Zuvor gab es keine Möglichkeit, dieses elementar-digitale und technisch längst gelöste und ausgereifte Konzept zu nutzen. Bereits der Apple Lisa (1983), und nach ihm nahezu jedes relevante, computerartige Gerät, hatte diese Funktion über das Tastaturkürzel »Strg + C« und »Strg + V« implementiert.

Das iPhone jedoch markierte den Beginn einer völlig neuen Hardware-Kategorie, dessen neuartige Bedienung völlig neuer Ausgestaltung bedurfte. Kurz: Technisch war das Problem lange gelöst. Gestalterisch jedoch nicht. Mir solch ein ungelöstes Gestaltungsproblem im Interfacebereich zu suchen und vorzunehmen, ist meine Motivationsgrundlage für diese Arbeit.

Historie & Technik

Die Geschichte von automatisierten, digitalen Systemen zur Versionierung begann 1968 mit der berühmten Vorführung durch den Ingenieur und Erfinder der Computermaus sowie einer Vielzahl weiterer, computerhistorischer Pionierleistungen, Douglas Engelbart, die aufgrund der Fülle an historischen Innovationen später als »mother of all demo‘s« in die Geschichte eingehen sollte.

1972 — Bell Labs, UNIX — 1. Generation VCS

Wenige Jahre später entwickelte Marc Rochkind »SCCS«  — das erste, der Öffentlichkeit zugängliche lokale Versionsverwaltungssystem (VCS).
Mit diesem konnten einzelne Textdateien von einem Nutzer unter Linux versioniert werden.

In seiner, mit der Veröffentlichung von SCCS einhergehenden Publikation, definierte Marc Rochkind vier der wichtigsten Merkmale eines VCS (M. J. Rochkind, “The source code control system”]:

→ Speicherung — Alle Versionen eines »Moduls« werden in der selben Datei gespeichert. Quellcode, der in mehreren Versionen identisch ist, wird nicht doppelt gepeichert. Dies ist auch als Deduplikation bekannt und bietet sich nur für nicht-kompilierte Dateien an.

→ Schutz — Die einzige Zugriffsmöglichkeit auf Module läuft über das VCS.

→ Identifizierung — Metadaten wie die Versionsnummer, das Datum u.ä. werden dem Modul automatisch angefügt.

→ Dokumentation — Das System nimmt auf, wer eine Änderung vorgenommen hat, wann dies geschehen ist und warum (durch Kommentar).

Es folgten die 2. und 3. Generation an VCS sowie die objektbasierte Versionierung, was an dieser Stelle nicht tiefer ausgeführt werden soll und in der Arbeit nachzulesen ist.

Sinneinheiten

Die Formatierung dient auch der Gliederung eines Textes und teilt diesen üblicherweise in Sinneinheiten ein.

Texte besitzen je nach kultureller Prägung für gewöhnlich ihnen inhärente Sinneinheiten, in die er sich gliedert.
So wird ein Buch zumeist in Kapitel mit einzelnen Überschriften und Absätze unterteilt.
Dies ist eine kulturelle Errungenschaft und eine Art der Hierarchisierung zur Ordnung, d.h. zur erleichterten Übersichtschaffung und Erfassbarkeit, von strukturierten Texten.
Die Nutzung von Sinneinheiten bei der Versionskontrolle ist abhängig von der Art des Textes.

So vergleicht Git zwischen Versionen zeilenweise, während Google Docs auf der feinsten inhaltlichen Granularitätsstufe, auf Zeichenebene Vergleiche anstellt [J. Stopak, “A Technical Guide to Version Control System (VCS) Internals,”] [S. Chacon and B. Straub, Pro Git]. In beiden Systemen wird eine Version mindestens durch ein gesamtes Dokument repräsentiert, wenn auch nicht als ganzes Dokument sondern als Veränderungen in einer Datenbank gespeichert.
Für die Art, wie Programmcode üblicherweise geschrieben wird und funktioniert, hat sich die Darstellungsweise von Git aufgrund ihrer besonders guten Vergleichbarkeit bewährt.

Innerdateiliche Pseudoversionierung

Ein Phänomen konnte ich während meiner eigenen Arbeit am Computer beobachten und das, wie eine kurze Umfrage unter zehn Kommilitonen aus dem Fachbereich Design der FHP bestätigen konnte, weite Verbreitung findet. So möchte ich dies als »innerdateiliche Pseudoversionierung« bezeichnen und im Folgenden beschreiben.

Während des Arbeitsprozesses wird ein Zwischenstand, etwa eine Zeichnung auf eine neue Ebene dupliziert, diese verschoben, gesperrt und ausgeblendet. Dies geschieht zum Beispiel aus Gründen der Vorsorge für den Fall, dass im späteren Verlauf ein Fehler entsteht, der zu viele Schritte zurückliegt und so unkompliziert auf einen »gesunden« Stand zurückgegriffen werden kann.

Auch als Vergleichs-Grundlage — etwa im Falle einer Rohfassung — kann sie genutzt werden. So kann auf die zuvor in der selben Datei angelegte Kopie zurückgegriffen werden, ohne diesen Zwischenstand unter vergleichsweise größerem Aufwand in einer der alten Dateiversionen, welche durch das Programm separat geladen werden müsste, suchen zu müssen.

Drei Arten der Pseudoversionierung konnte ich erkennen.

→ Pseudoversionierung 1: Das Sicherheitskopieren. Der Designer dupliziert Zwischenzustände seiner Gestaltung innerhalb der Datei an eine andere Stelle und blendet sie aus. → Der Designer tut so, als gäge es eine Versionierung.

→ Pseudoversionierung 2: Das Rückgängigmachen. Das Interface bietet einen Pfeil-Zurück-Knopf bzw. die Tastenkombination Strg-Z, durch die jeweils ein Bearbeitungsschritt zurück gegangen werden kann. Diese Möglichkeit ist u.U. nach dem Beenden und Neuladen in aller Regel nicht mehr vorhanden, also nur temporärer Art. → Das Interface suggeriert ein Versionierungssystem.

→ Pseudoversionierung 3: Der »non-destructive workflow«. Das Interface bietet parameterbasierte Modifikatoren oder Bearbeitungsebenen, die in jedem Entwicklungszustand reversibel zu- oder weggeschaltet werden können. So kann etwa bei der Entwicklung eines dreidimensionalen Stuhls aus einem einfachen Grundkörper an den Parametern, die den einzelnen Arbeitsschritten zugeordnet sind, nachjustiert werden. → Das Interface suggeriert, alles wäre reversibel und eine Versionshistorie überflüssig.

Diese Spezialform von Versionierung spielt für meine weitere Beschäftigung insofern eine Rolle, als dass ich versucht habe, diese Problematik in der Gestaltungsarbeit aufzugreifen.
Ich vermute, dass die »innerdateiliche Pseudoversionierung« eine Reaktion auf drei ungelöste Gestaltungsprobleme ist, darunter die zwei fundamentalen Probleme der Zwischenablage.

→ Die Zwischenablage tritt nirgendwo visuell in Erscheinung, sondern befindet sich an unverortbarer, imaginärer Stelle im Zwischenspeicher — ihr Inhalt muss sich demzufolge gemerkt, bzw. durch Einfügen erinnert werden. Anmerkung: Es gibt Ausnahmen unter den Betriebssystemen.

→ Beim Kopieren eines weiteren Objektes wird das bisherige ohne Warnung überschrieben, was die Nutzung der Zwischenablage für spätere Rückgriffe, die sich nicht direkt an den Kopiervorgang anschließen, unpraktikabel macht.

→ Das Öffnen einer alten Version eines Dokumentes braucht Zeit. Es muss zunächst die richtige Version unter den zumeist vielen Dateien gefunden werden, diese muss durch das Programm geladen werden und erst dann kann das entsprechende Element gesucht und an entsprechender Stelle gefunden und verwendet werden.

Eine visuelle Zwischenablage, die innerhalb des Programm-Interfaces »on-demand« zur Verfügung stünde, würde sich dieser Problematik annehmen.

How long is now?

Was genau ist eigentlich ein »Schritt«? Um dies zu klären, habe ich mir zunächst angeschaut, wie verschiedene Texteditoren dies handhaben, was in dem Abschnitt »Zeitgenössische Beispiele von Versionierung« beschrieben wird und daraufhin recherchiert und reflektiert, wie sich Interaktionen am Text runterbrechen lassen.
Eine undefinierte Menge an Interaktionen und Tastaturanschlägen eines Bearbeitenden wird von dem Texteditor automatisch zu einem sogenannten »Schritt« zusammengefasst und kann durch die Tastenkombination Strg. + Z oder einen Klick auf den nach links zeigenden Pfeil rückgängig gemacht werden. Eine definierte Phase in der sequenziellen Abfolge an Phasen.

Der Schritt sollte dabei eine möglichst sinnzusammenhängende Menge an Zeichen besitzen, um bei einem Rückschritt keine Wortbruchstücke entstehen zu lassen. Dies setzt allerdings voraus, dass Wörter geschrieben werden und nicht etwa eine Zeichenkette aus n-vielen Zeichen, die sich unabhängig von der Zeit, in der sie entstanden ist, mit einem Rückschritt vollständig revertieren würde, was ggf. für den Revertierenden eine unerwartete Reaktion sein könnte. Da derartige Feinheiten i.d.R. nicht durch die Software vorab kommuniziert werden, muss die Schrittlänge »ausprobiert« werden, sodass sich die Ergebniserwartung beim Rückschritt aus der Erfahrung in der gewohnten Arbeitsumgebung ergibt.

Nun macht ein Schritt in einer Schrittkette noch keine Version. Auch hier gibt es eine keine klare Konvention, ab wann eine Menge an Schritten zu einer Version zusammengefasst wird bzw. ob die einzelnen Schritte überhaupt in einem abgeschlossenen Sinnzusammenhang zueinander stehen. Oftmals wird eine Version schlicht nach einer längeren, zeitlich undefinierten Phase der Inaktivität oder mit der Dokument-Speicherung beim Logout definiert und erstellt.

So hat sich diese Erwartungshaltung in unterschiedlicher Software, deren Nutzer auf unterschiedliche Weise das »undo« nutzen, unterschiedlich entwickelt. Zumeist definieren Texteditoren die Schrittphase in wortgebundenen Intervallen oder, öfter noch, in zeitgebundenen. Letztere bewegen sich meist zwischen zwei bis drei Sekunden und führen bei Rückschritten unter Umständen zu »zerhackten« Wörtern. Allerdings ist anzunehmen, dass sie im Gegenzug die erwartete »Rückspringlänge« recht genau treffen.

Interessant würde es, wenn die Granularität erhöht und ein Schritt eine gedankliche Intention während des Schreibprozesses erfassen würde. So könnten wenige zusammenhängende Wörter, Halbsätze, ganze Sätze, Fehlerkorrekturen, Dateneinträge oder sonstiges im Ganzen rückgängig gemacht werden, was zu wesentlich präziseren Rückschritten führen würde. Interessanterweise bezieht sich bei Editoren, die zur Entwicklung von Programmcode gestaltet wurden, ein »undo« nie auf einen »Gedankenschritt«, sondern stets auf ein einzelnes Zeichen, das chronologisch zuvor gesetzt wurde. Die Schrittlänge hier ist also die kürzest mögliche. Dies könnte darin begründet liegen, dass das Programmieren mitunter in minutiöserer Weise stattfindet als es beim Schreiben eines Textes anzunehmen ist. Auch kann bereits ein rückgängig gemachtes Zeichen zu viel über die Funktionalität des gesamten Codes entscheiden.

In dem Schreibprogramm Notion habe ich die Vermutung, dass eine Abfolge von Aktionen innerhalb eines Elementes — hier als blocks bezeichnet — ohne Zwischenpause (»idle state«) von definierter zeitlicher Länge, in der Versionshistorie zu einem Schritt vereint wird. Das heißt, dass die Bewertung des zeitlichen Empfindens von uns Menschen (durch den Programmcode und) über die Maschine als Grundlage genommen wird, um zu entscheiden, ob eine Summe von Aktionen noch als ein Schritt oder bereits als zwei separate Schritte zu bewerten ist.

Die Frage, wem ein Schritt »gehört«, wenn die Teilschritte von zwei unterschiedlichen Kollaborateuren in einer Echtzeit-Arbeitsumgebung miteinander verwoben sind, stellt sich mit Bezug auf die Darstellung im Interface. Solche Versionen können durchaus mehreren Teilnehmern zugleich zugeordnet werden oder ggf. in »Unterversionen« mit nur einem Autor aufgeteilt werden.

Vermittlung

Interfaces formulieren die Gesamtheit oder eine Teilmenge aller möglichen Maschinenbefehle um und stellen sie über eine Abstraktionsebene, der Benutzeroberfläche dar [M. Fuller, Ed., Software studies: a lexicon].
Diese bietet dem Anwender Möglichkeiten der Interaktion. Sie bieten sich ihm durch ihre grafische Oberfläche an und kommunizieren — im besten Falle durch ihren intuitiven Angebotscharakter [D. Norman, The Design of Everyday Things] —, welche Interaktionsmöglichkeiten bestehen und worin diese im Ergebnis resultieren.

Computer verarbeitet → Interface zeigt an → Nutzer agiert→ Schleife.

So in etwa ließe sich die Kulturpraxis, die in unserer »digitaler Gesellschaft« Einhalt gefunden hat, als Prozesskette darstellen.

Mit der Cloud und Datenverarbeitung, die außerhalb des eigenen Nutzungszeitraumes des eigenen Computers stattfindet, stellen sich hier neue Herausforderungen an die Kommunikation bzgl. dessen, was im Hintergrund geschieht und dessen, was dem Nutzer rückgemeldet wird. Diese Herausforderung betrifft die Versionskontrollsysteme im Besonderen, wie ein nachfolgendes Beispiel aus der Dokumentation des webbasierten Texteditors »Google Docs« unterstreichen soll.

Ein Konflikt scheint aufgebrochen. Ein Konflikt darüber, wer die Entscheidungsmacht besitzt [J. Distelmeyer, Machtzeichen: Anordnungen des Computers.].

»Ich möchte speichern!« Dem manuellen Strg + S-Tastenkombinations-Automatismus versuchen kollaborative Webtools mit kleinen Hinweisen, dass automatisch gespeichert wird, sanft Abhilfe zu schaffen. Diese Form der Vermittlung, im Sinne von »etwas beibringen«, erscheint also als direkte Reaktion auf das »Fehlverhalten«. Ein Programm zu schließen, ohne den Arbeitsstand explizit gespeichert zu haben, fühlt sich schlecht und ungewohnt an, wie eine kurze Umfrage unter fünf Männern und fünf Frauen im Alter von 27 bis 36 Jahren aus meinem näheren Bekanntenkreis ergab.

Gestaltung für Versionierung

Aus der vorangegangenen Auseinandersetzung mit tangierenden Konzepten rund um die Thematik Versionierung im Interface habe ich acht Aspekte bzw. Untersuchungskriterien herausgearbeitet, nach denen ich bestehende Interfaces betrachten wollte, woraus ich mir Erkenntnisse für meine anschließende Gestaltungsarbeit erhoffte.

1. Das Komplexitätsabbildungsproblem

→ Versionierung ist komplex. Da es eine potentielle Fülle an zu speichernden Informationen gibt, stellt sich die Frage nach der Relevanz.

→ Welche Daten werden gesammelt, abgebildet und vermittelt, welche abstrahiert?

→ Werden ggf. Abstraktionsstufen bzw. Hierarchieebenen eingeführt?

→ Wie tief geht die Detailabbildungstiefe / Skalierung / Granularität? Vom Tastaturanschlag bis hin zu jeweils explizit gespeicherten, ganzen Dokumentzuständen.

→ In welchen Intervallen wird (vermutlich) gespeichert?

2. Die Ergebnisüberraschung

→ Gibt es eine Vermittlung vom Inhalt der Änderungen einer Version — falls ja, wie sieht sie aus?

→ Wie wird die Version bezeichnet, dargestellt und ihr Inhalt ersichtlich sowie zu den anderen Versionen unterscheidbar gemacht?

→ Generell: Wie wird Nachvollziehbarkeit in der Versionshistorie hergestellt?

3. Ordnung in der Versionshistorie

→ Wie wird „Übersichtlichkeit“ in der Versionshistorie hergestellt?

→ Gibt es eine Suchfunktion, Sortiermöglichkeit oder Bezeichnungs- oder Gruppierungsoption einzelner Versionen?

4. Trennung von content und style?

→ Werden Formatierungsänderungen versioniert?

→ Wie werden diese in Unterscheidung zu Änderungen am plain text differenziert?

5. Beziehung von current und past

→ Wie hängen Bearbeitungsebene und Versionierungsebene zusammen?

→ Wie wird die Unterscheidbarkeit zur aktuellen Version dargestellt?

→ Wie wird die Unterscheidbarkeit zu chronologisch „benachbarten“ Änderungen dargestellt?

(→ Liegt der Fokus der Versionierung eher auf der Wiederherstellung eines sicheren, vergangenen Zustandes bei korrupten Daten / Datenverlust im Notfall oder eher auf den Änderungen und Unterschieden die herbeigeführt wurden?)

6. Umgang mit Kollaboration

→ Wie wird Kollaboration in der Versionierung behandelt?

7. Verortung von Versionierung

→ In welcher Region auf der zweidimensionalen Bildschirmfläche ist das Interface zur Versionierung zu verorten?

8. Cross-Metamorphosen

→ Besteht die Möglichkeit, Teile eines vergangenen Dokumentzustandes zu extrahieren und diese Bausteine als Teil-Wiederherstellung in die aktuelle Version zu überführen, ohne diese dabei in Gänze zu überschreiben?

→ Wie wird diese neue, rückgewandte Versionsmetamorphose in der Versionshistorie dargestellt — Als neuer Schritt oder als Teilrevertierung?

Analyse

Die ausführliche Analyse findet sich in unten angefügtem PDF zu dieser Bachelorarbeit.

Doxperiment

Um mit der Darstellung verschiedener Versionen frei gestalten zu können, brauchte ich zunächst einmal Versionen.

Hierzu habe ich meinen Bruder, meine Mutter sowie zeitversetzt zehn Freunde dazu eingeladen, mit mir an einem bestehenden, zuvor generierten wissenschaftlichen Paper zu arbeiten und Änderung aller Art am Text durchzuführen.

Anschließend habe ich vier Versionen ausgewählt, ausgedruckt und diese nach meinem Gefühl dafür, was zusammen gehört und was nicht, in Sinneinheiten zerschnitten.
Interessant hierbei war die Feststellung, dass ich die Teilüberschrift eines neuen Paragraphen an diesem behaftet ließ und nicht separierte, wie es in HTML geschieht und wie ich es zuvor in einer kurzen digitalen Skizze selbst getan hatte. Außerdem wurde mir bewusst, wie schwierig die Zuordnung einzelner Elemente sein kann, wenn diese über die Zeit sehr  stark aufgebrochen, verschoben und verändert worden sind. Dies ist z.T. jedoch eine technische Herausforderung, die über Kontexterkennung und Wahrscheinlichkeitsberechnung programmintern gelöst werden kann, sodass ich als Gestalter mich ihrer elegant zu entziehen gesinne.

Prozess: Iterationen auf Papier

Google PostDoc. Gestalten & Anwenden.

Zunächst erscheint der Markdown-Editor im »dark mode« recht schlicht. Unter der Haube jedoch steht ein größeres Konzept, das ich im Nachfolgenden näher erläutern möchte.

→ Auszeichnen

Die einzelnen Absätze sind vergleichsweise weit voneinander getrennt. Zwei weiße Balken markieren den aktiven Paragraphen, an dem aktuell geschrieben wird, wie auch an dem blaufarbenen Balken im Text zu erkennen ist. Text kann wie gewöhnlich mit dem Mauszeiger oder über die SHIFT+ Pfeiltastenkombination markiert werden, woraufhin ein modales Overlay zur Textauszeichnung erscheint.

Auch das Overlay ist knapp und schlicht gehalten — die meiner Ansicht nach wichtigsten vier zeichenweisen MD-Auszeichnungen sind Fettmarkieren, Schrägstellen, Durchstreichen und Verlinken und sind im rechten Teil des Me- nüs verortet. Unterstreichen ist nicht Teil von MD. Es bestünde Verwechslungsgefahr mit Verlinkungen und da dies als gegeben hingenommen werden muss, kann nur ein Link ohne Ziel eingefügt werden.

In der linken Spalte befindet sich ebenfalls wie in Notion ein Dropdown-Menü, über welches die Hierarchie bzw. die des Art Textes innerhalb des Dokumentes festgelegt werden kann: Titel, Überschrift der Ebene 1, Überschrift der Ebene 2 usw., normaler Fließtext, nummerierte Liste oder unnummerierte Liste. Insgesamt habe ich mich für diese Methode der Textformatierung im Editor mit WYSIWYG-Kontrollkästchen entschieden, da ich sie für am praktikabelsten halte.

Aus der im Hintergrund liegenden Markdown-Formatierung kann über den Export des Dokumentes formatierter oder unformatierter Text in diversen Dateiformaten generiert werden.
Wird der gesamte Inhalte eines Elementes markiert, so springt die Auswahl auf das Element als Einheit um und es erscheint die Möglichkeit, seine Versionen zu »streamen«.
Dabei werden die Versionen gestaffelt übereinander gelagert und standardmäßig chronologisch vom Zeitpunkt ihrer Entstehung her angeordnet. Von der am weitesten zurückliegenden (unterste Ebene) bis hin zu der vorletzten Version.

→ Elementweises Rückblicken

Die Darstellung lädt dazu ein, den Mauszeiger über den »Strom an Versionen« wandern zu lassen. Die dabei sanft, aber schnell umspringenden, textuellen Metainformation am linken, oberen Rand einer Karte, erscheinen nur für die tempräre Dauer, in der eine Karte »überhovert« wird.

Einerseits, um nicht zu viele Informationen auf einmal anzeigen zu lassen und anderseits, um die Autorenschaft einer Version mittels erhöhter Schriftgröße, hervorzuheben und an den Aspekt der gemeinsamen Urheberschaft über die Zeit zu betonen. Ähnlich, wie es einer der Grundgedanken der Groupware war. Karten, die die Karte, über der der Mauszeiger schwebt, verdecken würden, verblassen.

Über den Strom können die Versionen in der Historie völlig neu exploriert und angeordnet werden.
Eine Neuandordnung geschieht über eine Menüleiste am oberen Bildrand.

Hier können Autoren zu- oder ausgeblendet, nach Stichwörtern gesucht und die Art der Sortierung gewählt werden.
Werden Filtereinstellungen angewandt, so werden die herausgefilterten Versi- onen nahezu transluszent und die betreffenden Versionen und ihr Inhalt wird erkennbar. Kurz darauf erheben sich diese aus dem Strom und ihre Änderungs inhalte werden markiert.
Nun kann eine Auswahl getroffen werden, in dem auf die entsprechende Version geklickt wird. So kann sie näher betrachtet und mit ihr interagiert werden.

In einer Seite-an-Seite-Darstellung stehen die beiden Versionen des einen Elements nebeneinander. So wird auch der Kontext, in dem sich beide Versionen befinden, geliefert. Innerhalb der Dokumente kann gescrollt und eine Version eines anderen Elements ausgewählt werden.

Gelöschtes wird außerhalb der Karte und außerhalb des Textes angezeigt, um den Textfluss nicht stark zu unterbrechen, wie es in den untersuchten Interfaces häufig der Fall war. Ein roter Balken markiert die entsprechende Stelle im Text.

Über ein Klick auf das + öffnet sich ein Zeit-Slider und der Kontext des Elements verschwindet — Fokus.

→ Sezieren

In dieser Ansicht (oben), der mit der höchsten Granularität, kann über einen Slider von der Erstellung des Elements bis seinem letzten, aktuellen Stand in einer Schrittlänge von je einem Wort, fließend die Entwicklung samt der Autorenschaft exploriert werden. Der Teilbereich auf der x-Achse, der sich zwischen zwei Markierungen befindet, bildet je eine Version des Elements.

So kann bereits erkannt werden, wie viele wortweisen Schritte stattgefunden haben. Die Autorin dieser Version wird unterhalb des Sliders angezeigt. So bildet eine Version nicht nur den Stand nach einigen Änderungen ab, sondern die Summe aller Momentaufnahmen aller Änderungen. Die Einteilung in Versionen dient nur der Ordnung zwecks »Übersichtlichkeit«.

Wenn die Ansicht verlassen wird, so bleibt die Version an der ausgewählten Stelle und die anderen Elemente des Dokumentes zu diesem Zeitpunkt treten wieder dezent in Erscheinung.

→ Dream Stream

Die Sortierung der Versionen kann nicht nur streng chronologisch, sondern etwa nach Aktivität — Wo wird besonders viel gearbeitet? — oder nach der Gesamtmenge an enthaltenen Zeichen — Welcher Teil der Bachelorarbeit bedarf der Kürzung? — erfolgen.
Dies könnte ebenso in der chronologischen Anordnung über eine Farbkodierung nach »Heatmap«-Darstellungsweise als Information von besonderem Interesse im Einzelfall zusätzlich angebildet werden.

Als repräsentatives Beispiel für die Vielzahl an neuen Möglichkeiten, die sich in der Darstellung des »Stream of versions« eröffnen, ist dies linksseitig dargestellt.

→ Vergleichen und Schöpfen

Ein Teilstück des Textinhalts einer ausgewählten, vergangenen Version kann markiert, per drag-and-drop extrahiert und hinüber in die aktuelle Version gezogen werden. Sie kann kein ganzes Element »ersetzen« sondern wird an die Stelle im Text gezogen, an der sie eingefügt werden soll.

Ein aktuelles Element ersetzt werden kann, indem die Versionskarte im Ganzen selektiert und über ihr entsprechendes Pendant gezogen wird.

Wird es über dem Weißraum (bzw. Dark-Raum) zwischen zwei Elementen in der aktuellen Version »losgelassen«, so wird es zusätzlich zu den bestehenden Elementen eingefügt.

Erläuterungen

→ Umgang mit Dreidimensionalität

Dreidimensionales hat zunächst grundsätzlich einen höheren kognitiven workload als Zweidimensionales, da eine dritte Achse räumlich Größen zuordnet werden muss.
Um die, in meinen Augen entscheidenden Vorteile dieser Darstellung dennoch nutzen zu können und ohne zu überladen und komplex zu erscheinen, habe ich mich im Gestaltungsprozess für eine unverzerrte »Stapelung« der Elemente entschieden. Außerdem werden nie übermäßig viele Metadaten parallel angezeigt, sondern immer nur wenige, im Fokus stehende und erst auf Interaktion durch die Nutzerin präsentierte, textuelle Informationen.
Einfache Überlagerungsdarstellungen sind in der Regel leicht als mentales Konzept zu erschließen und eng mit dem Konzept eines chronologischen Ablaufs verbunden, weswegen ich hierauf gesetzt habe.

→ Rekombination

Wie Ben Shneiderman in »The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations« [B. Shneiderman, “The Eyes Have It: A  Task by Data Type Taxonomy for Information Visualizations”] bereits 1996 bemerkte, kann der Nutzen einer Aufzeichnung (Historie) aller Aktionen auch darin bestehen, dass diese neu miteinander Verknüpft werden können.

» Keep a history of actions to support undo, replay, and progressive refinement. It is rare that a single user action produces the desired outcome. Information exploration is inherently a process with many steps, so keeping the history of actions and allowing users to retrace their steps is important. However, most prototypes fail to deal with this requirement. Maybe they are reflecting the current state of graphic user interfaces, but designers would be better to follow information retrieval systems which typically preserve the sequence of sear- ches so that they can be combined or refined.«

Wenngleich sich seine Ausführungen auf den mehrstufigen Suchprozess in einem existierenden Datenraum beziehen, so ist diese Erkenntnis doch auf die Nutzung der Versionshistorie im Allgemeinen übertragbar.

→ Gelöscht ist gelöscht?!

Elemente, die gelöscht wurden, können beim Übergang in den Versionierungs- modus über eine rotfarbene Schaltfläche, die an der Stelle erscheint, an der das Element zuletzt existierte, eingesehen werden. Bei Interaktion ist dann ebenfalls auch eine Versionierung des Elements möglich.

→ Mehr Formatierung bitte.

Die Auswahl eigener Schriftarten, Satzeinstellungen wie Tracking usw. sind nicht Teil der MD-Syntax und sollen auch nicht Teil von Google PostDoc sein. In diesem Sinne soll die fokussierte Arbeit am Textinhalt vor der Arbeit an der Formatierung stehen und letztere nur der Gliederung, nicht aber der »Gestaltung« im ästhetischen Sinne dienen.

Für den Fall, dass die Absätze nicht getrennt und immer länger werden, als es die Fensterhöhe im »Strom der Versionen« erlaubt in einem Stück abzubilden, müssen diese scrollbar gemacht werden.

→ Wessen Version?

Google PostDoc hält alle Arbeitsschritte an einem Element in wortweisen Intervallen fest und stellt diese als Karte visuell dar.

Die Autorenschaft einer Version ist einer Person eindeutig zuzuordnen, da das entsprechende Element während des Arbeitens für andere Mitarbeiter gesperrt ist. Wechselt der Bearbeiter an eine andere Stelle des Textes, also zu einem anderen Element, so wird es wieder freigegeben.

Den Fall, dass zwei Personen parallel an einem Absatz schreiben, halte ich für einen unvorteilhaften edge-case und bilde ihn nicht ab.

→ Links Zukunft, rechts Vergangenheit

Ein Empfinden dafür, wo auf einer Fläche etwas beginnen sollte und wohin sich etwas entwickeln sollte, ist stark von der Gewohnheit geprägt, in der wir Text lesen und somit stark kulturell beeinflusst.

Ich habe alle Kombinationsmöglichkeiten der Anordnung der Achse zur Stapelung der Elemente-Karten durchgespielt und mich dennoch klar für die Variante entscheiden können, bei der rechts oben die Vergangenheit ist und links unten die Zukunft liegt.
Interessanterweise ist dies genau andersherum, als es bei dem »time tunnel« von MacOS der Fall ist.

→ Gedanken halten

Um gegen den workaround der Pseudoversionierung eine Abhilfe zu schaffen, steht eine grafische Zwischenablage in Form einer Leiste am linken Bildrand zu verfügung.

Bereits in ihrem eingeklapptem Zustand können dort abgelegte Elemente ausgemacht werden.

Ausgeklappt können Versionen, die dort zuvor abgelegt wurden, als reine »Inspirationsquelle« während des Schreibens genutzt werden oder über direkte Manipulation anderweitig in den neuesten Text einfließen.

Das vertikale Grundraster des Interfaces gliedert sich in drei gleichgroße Spalten, an denen sich die Bereiche je nach Nutzung ausrichten.

So nimmt der Schreibbereich die zwei rechten Drittel ein, wenn die Ablage ausgeklappt ist und die Versionierung nicht aktiv genutzt wird.

Hinweis

Die vollständige Arbeit kann unter https://fhp.incom.org/action/open-file/366438 heruntergeladen werden. Dort finden sich alle bibliographischen Nachweise.

Buch

Ein schönes Buch rundet ein wichtiges Projekt ab und hält es für zukünftige Tage in Erinnerung.
Zwar ist in die Buchgestaltung und -herstellung noch einmal viel Arbeit hinein geflossen, die ich eigentlich nicht hatte, sodass der Endbeschnitt am Abgabetag kurz vor deadline stattfinden musste.
Jedoch war das händische Arbeiten in der Buchbindewerkstatt eine wohltuende, gute Ergänzung zur Arbeit an PostDoc und hat mir wieder viel Freude bereitet — danke Friederike!