Nachlese Interaction Design Stammtisch 14.2. – 1. Teil
Diese Postings sollen einen kleinen Einblick geben was bei unserem Interaction Design – Stammtisch so alles besprochen wurde (und wird). Ich hab die Nachlese vom 14.2. auf mehrere Posts verteilt weil das Ganze sonst zu lange wird. Hier nun der erste Teil.
Versionierung
Dieses Thema wurde von Jürgen eröffnet. Versionierung betreiben zwar wahrscheinlich die meisten User zumindest hin und wieder, aber nur die eher technikaffinen Benutzer kennen den dazugehörigen Begriff auch. Es geht darum, verschiedene Versionen eines Dokuments (das kann im Prinzip jede Art von Datei wie etwa eine Word-Datei oder ein Photoshop-File sein) abzuspeichern, um auf frühere Zustände Zugriff zu haben. Die meisten User machen das vermutlich so wie ich mit fortlaufenden Nummern oder Buchstaben im Dateinamen, also etwa
- Dokument1.doc
- Dokument2.doc
- Dokument3.doc
Davon gibt es dann verschiedene “more sophisticated”
Nun stellt sich natürlich die Frage, welches System von den Benutzern gewünscht wird. Auch sind sicherlich die Motive warum jemand Versionierung betreibt interessant. Geht es darum frühere Zustände zu dokumentieren, oder führt eher ein Sicherheitsgedanke dazu, dass ein User den zusätzlichen Aufwand betreibt?
Weiters wäre es interessant zu wissen ob nicht eigentlich das Betriebssystem diese Aufgabe übernehmen sollte. Diskutiert wurde auch über anwendungsinterne Rollback-Mechanismen, so ist es (bei bestimmten?) Programmen unter OSX so, daß ein “Rückgängig machen” über einen Speicherpunkt hinweg funktioniert. Speichert ein User also ein Dokument unter OSX ab und arbeitet danach daran weiter, so ist es möglich, den letzten Schritt (der vor dem Speichern gesetzt wurde) rückgängig zu machen (unter Windows funktioniert das nicht).
Ein weiterer Diskussionsansatz in diesem Themenkreis war dann die Frage, ob Speichern als zentrale Funktion nicht überhaupt aus den Interfaces verschwinden sollte. Speichern ist ja an und für sich ein künstlicher Vorgang der in der “realen” Welt so nicht vorkommt. Aus Benutzersicht wäre es durchaus vorteilhaft wenn alles was am Bildschirm zu sehen ist auch später wieder hergestellt werden kann ohne daß dazu zuerst gespeichert werden muß.
Da einige der Anwesenden Tools wie Writely oder Writeboard (von 37Signals) verwenden, wurde anschließend daran auch über die Versionierungsfunktionen dieser Applikationen gesprochen. Diese Anwendungen speichern ja teilweise automatisch Snapshots des gerade bearbeiteten Dokuments (siehe Screenshot). Writely etwa speichert alle 10 Minuten und ermöglicht es dem User so, schrittweise in die Vergangenheit eines Dokuments zu gehen ohne dazu etwas aktiv dazu beitragen zu müssen. Ähnliche Funktionalitäten gibt es auch bei Wikis, nur muß hier aktiv gespeichert werden.

Es gibt also große Unterschiede bei den bereits verfügbaren Versionierungsfunktionen.
Mir persönlich scheinen folgende Merkmale wichtig zu sein:
- Der User muß immer das Gefühl haben die Anwendung zu kontrollieren. Eine Versionierung die zwar automatisch arbeitet, deren Ergebnisse aber unvorhersehbar und möglicherweise auch kontraproduktiv sind hilft niemandem.
- Ein eigener Standard für Versionierungsfunktionen wäre dringend notwendig sobald diese von mehreren Applikationen angeboten wird. Innerhalb eines Betriebssystems müssten diese Funktionen konsistent arbeiten (idealerweise sollte es natürlich einen betriebssystemübergreifenden Standard geben, aber so etwas wirds wohl noch längere Zeit nicht spielen…).
Ähnliche Beiträge:
| Interaction Design – Stammtisch, heute um 19:00 im Glacis Beisl (MQ) | Interaction Design Stammtisch heute um 19:00 & zweiter Teil der Nachlese vom 14.2. | Interaction-Design-Stammtisch heute im Lux, 19:00 | Interaction Design – Stammtisch morgen um 19:00 im WerkzeugH | Interaction Design – Stammtisch heute um 19:00 im WerkzeugH |








März 15th, 2006 at 16:19
[...] Nachlese Interaction Design Stammtisch 14.2. – 1. Teil [...]