Entwurf speichern? Gerne – aber nur auf Befehl!
Vor längerer Zeit stieß ich in einem Projekt auf eine Problematik, die sich um das Zwischenspeichern von Entwürfen rankt. Nicht aktuell – aber vielleicht interessant genug, um es hier im Blog nachzutragen.
Die Ausgangssituation
Es geht um eine eigentlich recht einfache Situation: Der Nutzer möchte ein Dokument oder eine Mail erstellen. Nun, unser Vertrauen in die Technik hat durch den ein oder anderen Bluescreen oder andere Abstürze gelitten. Was machen wir also? Ctrl+S gehört zu den Shortcuts, die man schnell lernt und schon fast automatisch alle paar Minuten eingibt… Wenn man nicht ein UI einer browsergestützten Anwendung vor sich hat! Das führt nämlich dazu, dass man die HTML-Seite lokal speichert. Das WordPress, an dem ich gerade sitze, bietet mir an, post-new.php.html lokal zu speichern. Hm, das möchte ich aber nicht. Ich möchte nur sicherstellen, dass der Artikel nicht verloren geht. Ctrl+S ist also nicht die Lösung.
Die vermeintliche Lösung
Dieselbe Situation habe ich in jenem Projekt erlebt: Eine browserbasierte Oberfläche, in der umfangreiche Dokumente erstellt werden. Wie löst man das? Beim Erstellen eines Dokuments wird sofort ein Entwurf angelegt. Dieser wird aktualisiert, sobald man innerhalb eines Assistenten vor oder zurück navigiert. Dies wird dem Nutzer nicht signalisiert. Wenn man das Dokument erstellt und versendet hat, wird der Entwurf gelöscht. Das klappt alles ganz prima, solange man die Erstellung des Dokuments nicht abbricht. Beim Abbrechen wurde dann nämlich gefragt: “Es ist ein Entwurf automatisch angelegt worden. Wollen Sie den Entwurf löschen?” Wie bitte? Was soll ich hier entscheiden? Ich weiß doch gar nicht, was da im Hintergrund passiert ist und was im Entwurf drin steht. Ich habe den nicht angelegt. Da wir aber vorsichtige Nutzer sind, löschen wir den Entwurf nicht und klicken auf Nein. Die Erfassungsmaske der Mail schließt sich und alles ist gut. Wirklich? Es sammeln sich so im Laufe der Zeit viele Entürfe an, deren Inhalt ich nicht einschätzen kann. Ok, das ist das Usability-Problem Nr. 1.: Ansammeln unbekannter Dateien. Das ist besonders dann ein Problem, wenn mehrere Nutzer an einem Ordner arbeiten und nicht wissen, was die Entwürfe des anderen Kollegen sollen. Lieber Finger weg!
Doch es geht weiter. Jetzt öffne ich am nächsten Tag den Entwurf wieder und möchte an ihm weiterarbeiten. Ich tippe also los und navigiere durch den Erfassungsassistenten (siehe hierzu auch meinen anderen Artikel zum Thema Tabpages). Jetzt muss ich bspw. wegen eines Telefonats meine Arbeit unterbrechen, will aber keine Daten verlieren. Das fürsorgliche System fragt, ob der Entwurf gespeichert oder verworfen werden soll. Welcher denn? Der von gestern oder meine aktuellen Eingaben von heute? Usability-Problem Nr. 2: Der Status ist nicht nachvollziehbar.
Was lernen wir daraus?
Das Anlegen von automatisch erzeugten Entwürfen im Hintergrund ist ok, solange der Nutzer damit nicht behelligt wird. Sie treten ausschliesslich bei der Wiederherstellung nach einem Systemabsturz in Erscheinung.
Der Nutzer kann nur über Entwürfe entscheiden, die er selbst “in Aufttrag“ gegeben hat.
Wir müssen trennen zwischen automatisch erzeugten Entwürfen und manuell angelegten Zwischenspeicherungen.
Die bessere Lösung
Und jetzt komme ich wieder auf den vermeintlichen Lösungsansatz zurück, Datenverluste durch Zwischenspeicherungen zu vermeiden. Das muss im Hintergrund geschehen. Das darf der Nutzer nicht mitbekommen. Der Nutzer kann nur über Zwischenspeicherungen entscheiden, die er aufgrund einer bewussten Aktion initiiert hat (Button “Jetzt speichern” oder “Zwischenspeichern”, oä…). Alles andere überfordert ihn, da nicht verständlich ist, wie das jeweilige System funktioniert.
Ergo
Liebe User Interface Designer, unterscheidet zwischen systeminternen Temp-Datei-Backups für die Wiederherstellung und bewusst durchgeführten Entwurfs-Speicherungen!
#Usability #UserInteractionDesign #UserInteractionPattern #UserInterfaceDesign