Redesign von Rückgängig/Wiederherstellen

Es passiert selten, aber heute habe ich eine Bitte an meine Leser: Im folgenden geht es um ein neues Design, an dem ich mit einer Gruppe arbeite. Die Funktion dürfte jeden betreffen, der Texte am Computer schreibt. Ich möchte euch deswegen bitten, den folgenden Text zu lesen (zumindest den vorletzten Absatz) und mir zu sagen, was ihr von der Idee haltet.

Heute haben wir mit der Gruppenarbeit angefangen. Eigentlich waren die Gruppen ja schon aufgeteilt, als ich hier verspätet ankam, aber ich war nicht der einzige und so kam doch noch eine Gruppe von drei zustande.

Unsere Aufgabe besteht darin, für den Human-Computer-Interaction-Kurs entweder ein Design zu evaluieren oder selbst etwas zu designen. Beim Lesen des Buches kam mir eine Idee, die von der Gruppe angenommen wurde und an deren Design wir jetzt arbeiten. Es geht um die Edit-History. Jeder kennt das: Wenn man zum Beispiel in Word (oder in jeder anderen Textverarbeitung) einen Text schreibt, kann man mit den Button “Rückgängig” in der Edit-History zurück gehen und mit dem Button “Wiederherstellen” geht’s wieder zum aktuellen Stand. Leider hat sich diese Art des Zugriffs auf die Dokument-History seit der Einführung des Konzepts kaum geändert (weiß jemand zufällig, wann das eingeführt wurde?).

Generell gibt es ein paar Beschränkungen, die früher vielleicht nötig waren, heute aber dank immenser Rechen- und Speicherkapazität eigentlich nicht mehr bestehen sollten. So ist es bei ausnahmslos allen Textverarbeitungen (die ich kenne) der Fall, dass die Dokument-History nicht mitgespeichert wird. Wer ein Dokument schließt und wieder öffnet, verwirkt die Möglichkeit des “Undos”, des rückgängig machens. Warum eigentlich, ist Speicherkapazität heute wirklich so knapp?

Ein anderes Beispiel ist automatisches Speichern. Früher war es aufgrund der Langsamkeit der Speichermedien/Prozessoren und des fehlenden Multitaskings nicht möglich, einen Text immer mitzuspeichern, der User wäre ständig unterbrochen worden und hätte nicht mit dem Programm arbeiten können. Heute gibt es keinen Grund mehr für diese Beschränkung und tatsächlich gibt es gerade auf dem Mac schon einige Programme, die einfach immer mitspeichern und deswegen gar keinen Speichern-Button mehr haben. Das Konzept des Speicherns ist auch völlig unintuitiv. Wenn ich etwas auf meiner Schreibmaschine schreibe, muss ich auch nicht erst den Speichern-Knopf drücken, es wird auf dem Papier gespeichert, in dem Moment, in dem ich auf eine Taste der Schreibmaschine drücke. Genau so sollten auch Textverarbeitungs-Programme heute funktionieren, leider sieht die Realität anders aus.

Nach alle diesem Vorgeplänkel aber jetzt zu meiner Idee: Die Idee ist, dass die Dokumenten-History immer mitgespeichert werden sollte und der Zugang zu dieser History massiv vereinfacht werden muss. Gerade wenn man ein Dokument über ein halbes Jahr bearbeitet, ist die aktuelle Methode nicht zumutbar. Mein Vorschlag: Ein History-Slider, der ähnlich aussieht wie ein horizontaler Scrollbalken, beim verschieben nach links aber in der Zeit zurückgeht und nach rechts in der Zeit nach vorne. Wenn ich also den Scrollbalken nach links ziehe, kann ich mir in “Echtzeit” anzeigen lassen, wie mein Dokument vor einer Woche aussah. Beim Ziehen nach rechts kann ich dann zusehen, wie sich das Dokument entwickelt hat.

So muss man sich keine Gedanken machen, wenn man einen Absatz überschreibt, und ihn später vielleicht doch noch mal
lesen möchte. Als Vielschreibe spüre ich die Beschränkungen aktueller Textverarbeitungen sehr deutlich. Wenn ich einen Text schreibe, dann bin ich mehr mit dem Umschreiben beschäftigt, als mit dem eigentlichen Schreiben. Jedes Mal wenn ich einen Absatz umformulieren möchte, hab ich aber den Gedanken im Kopf “und was, wenn die aktuelle Formulierung doch besser war?”. Entweder muss ich dann eine neue Version des Dokuments anlegen oder ein paar Sätze in einem anderen Dokument zwischenspeichern, beides eigentlich nur unzureichende Hilfskonstruktionen.

Was meint ihr, ist die Idee es Wert, umgesetzt zu werden?

18 thoughts on “Redesign von Rückgängig/Wiederherstellen

  1. nils

    Weckt Assoziationen mit Time Machine, finde ich aber trotzdem cool. Vor allem das mit dem horizontalen Scroll-Balken, quasi als Zeitleiste, finde ich gut.

    Ich gebe aber zu Bedenken, dass gerade MS Word des Öfteren ins Gerede kam, weil vorherige Bearbeitungsstände mitgespeichert wurden, die dann an die Öffentlichkeit kamen, was nicht intendiert war. Es muss auf jeden Fall eine Möglichkeit geben, die History rauszuwerfen – und es muss hinreichend klar sein, dass es eine Art Sicherheitsrisiko ist, Dokumente mit History weiterzugeben. Oder sein kann.

  2. Stefan

    Die Assoziation zu Time Machine hatte ich auch sofort. Aber eben das finde ich ja so cool an der Idee. Vielleicht solltest du Apple mal darauf ansprechen? ;-)

    Nils hat allerdings recht damit, dass es eine Möglichkeit muss, die History vor dem Versenden der Datei zu entfernen. Kleines Beispiel von mir und manchen Bekannten: wenn ich nicht weiter weiß, kommt es bisweilen vor, dass ich den Fluch, der mir in dem Moment durch den Kopf geht, einfach in das Dokument tippe, speichere und es beende. Wäre peinlich, wenn mein Prof das bei der Abgabe der endgültigen Arbeit dann auch noch sehen könnte… :-)

  3. Morty

    So hier mal meine Chaotischen Gedanken zu dem Thema:

    Autospeichern: Z.B. bei Open Office dauert das länger, da die Datein ja noch gezipt werden. Allerdings kann man dies sicher optimieren. Ist etwas bescheuert, das OO das im Hauptprozess macht. Man könnte ja auch das Speicherabbild kopieren und einen eigenen niederprioren Thread starten oder so etwas.

    Was mich viel mehr nervt, was z.B. auch ein Problem beim FF ist, dass wenn man zurück geht, und dann aus Versehen auf eine Taste kommt (auf einen Link klickt) alles was man nach diesem Zeitpunkt gemacht hat weg ist.
    Mal ein Beispiel: Du bearbeitest einen Absatz, bist der Meinung das die Vorherige Version besser ist. Gehst also zurück und überarbeitest ihn nochmal. Jetzt stellst Du fest, dass die vorherige Überarbeitung besser war. Was nun?
    Dieses Problem tritt bei bei mir beim Programmieren ständig auf – aber da hab ich eine Versionsverwaltung. Wäre es da nicht sinnvoll die Überarbeitenfunktion, die alle gängigen Programme haben, mit einer Versionsverwaltung und der Zurück-Funktion zu kombinieren? Allerdings muss man dann auch die Verschiedenen Äste auch noch irgendwie darstellen.
    Außerdem will ich meist eine vorherige Version von einem Absatz und nicht von einem ganzen Text. Und ich will ja auch nicht jeden Vertipper mit abspeichern. Man bräuchte also auch hierfür ein Konzept. Zum Beispiel eine Version nach jedem Satz oder immer wenn der Kursor den Absatz verlässt.

  4. Steve

    Ich denke auch das dass Speichern der Historie viele Sicherheitsprobleme bereiten würde weil die Leute Doc Dateien mit Historie ins Internet stellen und jeder sehen kann wes irgendwann mal da gestanden hatte und in der letzendlichen Version entschärft wurde.
    Um das zu verhindern, müsste man den Usern erstmal beibrigen das Texte in einem neue Format ins Internet veröffentlich werden müssen ( PDF oder XPS ).

    Etwas ähnliches wie der Silder bietet Photoshop schon. Nur nicht als Slider, sondern als Liste :-)

  5. atopal Post author

    Dass Bedenken wegen des Datenschutzes eine Rolle spielen ist klar, aber mal angenommen, das Problem würde sich einfach lösen lassen, wenn es also nur um die Funktion selbst ginge, wie sinnvoll wäre es?

    Time Mashine ist tatsächlich eher eine Versionsverwaltung für Dateien, hier geht es um einzelne Edits in einem einzigen Dokument.

    Morty, vielleicht gefällt dir ja dieser Editor, er hat Branching schon eingebaut. Allerdings dürfte dir auf den ersten Blick auch die komplexität der Sache bewusst werden: http://e-texteditor.com/blog/2006/making-undo-usable

    Steve, du verlierst in PS diese Möglichkeit, sobald du das Dokument schließt.

  6. Fenris

    Das Sicherheitsproblem ließe sich dergestalt lösen, dass die Versions- und Dokumentdaten separat gespeichert werden.
    Etwas ähnliches haben wir bei uns in der Firma für unser Webshopverwaltungstool selbst gebaut:
    Um verschiedene Stände von Produktdaten zu dokumentieren wird immer nur der aktuelle Stand auf der Website veröffentlicht die Älteren werden in einer Datenbank abgelegt und können jederzeit, von allen die Zugang haben, angesehen oder auch wieder neu bearbeitet werden.
    Um beim Beispiel Office zu bleiben würden hier die Versionsdaten vom Office-Programm gespeichert und das eigentliche Dokument würde weiter als .doc, .xls oder .ods gespeichert. Das hätte zusätzlich den Vorteil, dass kein neues Format eingeführt werden müsste und zumindest die entstehenden Dokumente kompatibel zu älteren Anwendungen wären.
    Auch wäre denkbar diese Daten innerhalb einer Firma, Workgroup freizugeben so, dass die Dokumente von mehreren Personen bearbeitet werden können.Ich glaube die neuesten Adobe Produkte in der Creative Suite haben so eine Funktion. (VersionCue oder so ähnlich)
    Aber ich fange wieder an zu schwafeln..

  7. atopal Post author

    Sicherheit ist ja schön und gut, aber ich fänds wirklich schön, wenn jemand was zu der Funktion selbst sagen würde. Hier geht es schließlich nicht um die Implementierung in ein fertiges Produkt, sondern um einen Prototypen.

  8. Axel Hecht

    Was du hier eigentlich suchst, ist ein VCS. Müssen da erst die hardcore-Mozillianer kommen?

    Das Dokumentenformat ist dann im Wesentlichen ein repository.

    Undo und anderer change ist wohl ein branch.

    Da du files rumsenden willst, mit anderen leuten editieren etc, ist ein P2P VCS wohl die richtige Metapher.

    In der Richtung gibt’s ja jetzt einiges, git, bazaar, mercurial, svk, etc. Aktuelle Entwicklungen sind insbesondere zu besseren merges in der Lage, also z.B., “ach den einen Paragraphen den ich vorhin gelöscht habe, den hätte ich jetzt doch ganz gerne wieder.”

    Was die Performance solcher Systeme angeht, da gibt’s zwei posts auf jst’s blog, das wäre ja ganz interessant für das inkrementelle Speichern. Was an sich ja nicht teuer sein muss, wenn man patches abspeichert. Und selbst, wenn man das zipped, kann man die ja eine Zeitlang unkomprimiert anhängen, was schneller wäre. Oder so.

  9. nils

    Wenn Sicherheit nicht im Prototypen mitgedacht wird, lässt sie sich hinterher nur noch schwer aufsetzen, ist zumindest meine Erfahrung/Meinung.

    Aber natürlich ist Sicherheit nicht alles.

    Ich bin gerade am Überlegen, ob eine 2D-Struktur (Slider) dafür das richtige ist. Vielleicht wäre ein Baum da sinnvoller. Dann kann man zu verschiedenen Branches zurückspringen.

    Insbesondere wäre es cool, wenn ich in einem Dokument drei Schritte zurückgehe, dort etwas ändere, die drei Schritte danach nicht verlieren würde. Da wird es aber knifflig, weil man wahrscheinlich eine Art automatisches Merging bräuchte – andere Systeme können das ja irgendwie einigermaßen, vllt. kann man da was übernehmen.

  10. atopal Post author

    Axel, darüber hab ich gestern mit einem Freund gesprochen. Im Grunde ist es merkwürdig, dass aktuelle VCSe diese Art von Diff nicht anbieten, aber was ich meine, funktioniert doch etwas anders. Ein VCS verwaltet nur States, die bewusst abgelegt werden, meine Idee wäre aber ein stufenloses vor und zurück in einem Dokument. Andererseits hätte es auch nicht die Mächtigkeit eines VCS, denn Branches sind wirklich nur schwer zu vermitteln.

    Nils, Branches wären dann auch die Hilfsmittel, die man für deinen Vorschlag bräuchte. Es gibt diesen Edtior hier: http://e-texteditor.com/blog/2006/making-undo-usable
    Es ist aber in der Tat einfach zu kompliziert. Dafür ein simples Interface zu finden, wäre genial, man könnte dadurch das Leben von Autoren enorm vereinfachen, aber mir ist bisher noch nichts dazu eingefallen.

    Die Idee mit dem horizontalen Slider kam daher, dass das Konzept zwar recht beschränkt ist (eben auf eine Ebene), dafür aber simpel genug, um es sofort zu begreifen.

    Wenn es noch mehr Ideen gibt, immer her damit. Vielleicht ist der Slider auch nur ein erster Schritt, mit bestimmten Trackern könnte es sogar möglich sein, einzelne Sätze durch die History zu verfolgen. Mit direktem Zugriff auf so eine History wäre es möglich zu ändern, wie wir momentan noch über das Svhreiben und Bearbeiten von Dokumenten denken. Digitaler Text soll schließlich flexibler sein als auf Papier, warum sollten wir schon das Limit dafür erreicht haben?

  11. Master X

    Grafisch ließe sich das sicher mit einem Tree-Slider, d.h. einer Baumstruktur, auf der man einen Punkt hin und herschieben kann, wie einen Zug auf einem Schienennetz.

  12. atopal Post author

    Schau dir mal den Link in meinem letzten Posting an, da hat der Programmierer von e genau das gemacht. Meiner Meinung nach ist das ein eingebautes VCS, in dem man verschiedene Zustände manuell abspeichern kann, es ist aber nicht das, was ich meine.

  13. Axel Hecht

    Irgendwie erinnert mich das etwas an bookmarks vs. places.

    Für Tippfehler sollte es einfach back-and-forth tun, für alles, was darüber hinaus geht, mag es nützlich sein, die Änderungen automatisch in Transaktionen zu zerlegen (vielleicht sogar hierarchisch) in denen man dann Volltextsuche betreiben kann.

    Denken wir mal an den “Ich hatte da schon mal was geschrieben” Use-Case. Den will doch keiner wirklich in einem branch-und-merge Graphen suchen, oder? Denn spätestens nach dem ersten Merge ist der Baum kein Baum mehr.

    Ich würde mal tippen, dass man brauchbare Transaktionen mit ein bisschen Analyse automatisch detektieren kann, Tipppausen sind eine Begrenzung, in den meisten Sprachen kann man auch Wort- oder Satzgrenzen benutzen. Und dann gibt es Absätze, Kapitel, und ähnliche Gliederungen.

    Der Unterschied zwischen einem herkömmlichen VCS und einer guten undo History liegt für mich übrigens im automatischen Erkennen von brauchbaren Transaktionen.

  14. atopal Post author

    Bei einer History gibt es noch weitere Probleme, die zu beachten sind, was passiert zum Beispiel mit dem Fokus, wenn sich gerade auf Seite 26 ändert, man aber auf Seite 3 ist, springt der Cursor, oder passiert die Änderung im Off?

    Unabhängig davon könnte es ein interessantes Projekt sein, eine visuelle History in ein VCS einzubauen.

  15. atopal Post author

    Die hab ich (bis auf meld) alle schon seit meiner ersten Woche mit OS X durch, durch die Bank grauenhaft bis grausam. Bei wirklich großen Diff-Aktionen muss ich immer noch Windows booten, kein Diff-Programm kommt an Beyond Compare ran. Man muss bei denen wirklich schon froh sein, wenn elementare Diff-Funktionen klappen, Diffs über Generationen eines Dokuments schafft keines der Tools.

  16. Pingback: EnVision » Blog Archiv » FOSDEM 2007

  17. Pingback: anothr user

Comments are closed.