![]() |
Probleme beim Multi-Document-Design
Ich brauche mal ein paar Ideen und Anregungen zu einem UI-Problem.
Also, ich habe eine Anwendung mit der man eine Datei öffnen, bearbeiten und speichern kann. Dabei ist natürlich auch Speichern unter einem anderen Namen möglich. Sind ungespeicherte Änderungen beim Schließen vorhanden erfolgt eine Rückfrage. Soweit alles ganz normal. Nun soll die Anwendung so erweitert werden, daß mehrere Dateien gleichzeitig offen sind und bearbeitet werden können. Das funktioniert soweit auch problemlos, solange die offenen Dateien nichts miteinander zu tun haben. Jetzt gibt es aber verschiedene Szenarien, bei denen Probleme auftauchen, für die ich noch keine Regel habe, wie das sinnvoll und für den Benutzer intuitiv behandelt werden kann. (Hinweis: Die Dateien werden nur zum Lesen geöffnet und beim Speichern überschrieben. Es liegt während der Bearbeitung kein Lock darauf.) Szenario 1: Es wird eine Datei geöffnet, die bereits offen ist. Erlaube ich das?Szenario 1a: Ich lasse zwei unabhängige Instanzen zu. Wie löse ich den Konflikt, wenn beide gespeichert werden sollen?Szenario 1b: Ich öffne dieselbe Instanz in einem zweiten Editfenster. Wie reagiere ich bei Speichern als ? Bekomme ich dann zwei unabhängige Instanzen?Szenario 2: Eine Datei soll unter einem Namen gespeichert werden, unter dem schon eine Datei offen ist. Lasse ich das zu? Mir geht es hier gar nicht darum, wie das implementiert werden kann, sondern erstmal welches Verhalten ein Anwender intuitiv erwarten würde. |
AW: Probleme beim Multi-Document-Design
Zitat:
Und mach es dann genauso. Denn genau dieses Verhalten werden viele Erwarten. |
AW: Probleme beim Multi-Document-Design
Klingt für mich eher nach dem Verhalten von Notepad.
Wer zuletzt speichert, hat gewonnen. Speichert man unter einem anderen Namen, hat man hinterher 2 Dateien. Bei Scenario 2: Kann man zulassen. Wenn die andere Instanz dann aber auch speichert, wird die Speicherung der ersten Instanz wieder überschrieben. |
AW: Probleme beim Multi-Document-Design
Ich empfinde das verhalten von Notepad+ sehr angenehm. Beliebiges öffnen letzte Speicherung überschreibt alles, beim Aktivieren eins Fensters dessen Datei seit dem Laden neu gespeichert wurde fragt ob die geänderte Datei geladen werden soll.
|
AW: Probleme beim Multi-Document-Design
Ich würde Bernhard und Bummi zustimmen.
Was andere Firmen und insbesondere Microsoft machen ist sicher kein schlechter Einstieg. Du hast geschrieben, dass es sich um eine Erweiterung der Software handelt. Ich würde mal vermuten, dass diese Anforderung vom Kunden stammt. Wenn ja, finde ich es völlig legitim, den Anwender selbst entscheiden zu lassen. Er möchte eine Änderung, die neue Herausforderungen nach sich zieht und um diese zu meistern muss das Programmverhalten neu gestaltet werden. Wenn Du dann noch die beiden erwähnten Optionen als Vorschlag mitlieferst, sollte einer fruchtbaren und letzendlich erfolgreichen Diskussion nichts im Wege stehen. |
AW: Probleme beim Multi-Document-Design
Zitat:
Ich hab das schonmal wenn ich ein HTML Datei editiere (Offlineversion natürlich), diese parallel im Browser offen habe, kriege ich jedes mal wenn ich im Browser aktualisiere und dann zu Notepad++ zurückwechsle die Meldung, was mich immer iritiert, weil der Browser ja nix an der Datei ändert. Zur Eigentlichen Frage. Es kommt, mMn auch auf die Art des Dokumentes und die Frage paralleler Zugriffe durch einen oder mehrere User an. Wenn ich gerade in einem Excel-Dokument (das zufällig noch wer anders auf hat (nur theorisch! Geht ja nicht wirklich!)) irgendwelche tollen Daten ermittelt hätte und die speichere, wäre ich ziemlich sauer, wenn mein Kollege anschließend auch speichert und mir das Ganze wieder überschreibt. Aber bei Textdokumenten, wie z.B. den HTML-Dateien, wär mir das egal, da find ich wie die Vorredner das Notepad-Verhalten auch OK. |
AW: Probleme beim Multi-Document-Design
Zitat:
Aber zur Frage zurück. Meiner Meinung nach gibt es drei Möglichkeiten: a) wer zuletzt speichert gewinnt. b) wer zuerst öffnet darf auch speichern c) alle Änderungen an einer Datei werden zusammengeführt ( und Kollisonen gemeldet) wobei c) einiges an Arbeitsaufwand mit sich bringt (darum gibt es das auch so selten!) Gruß K-H |
AW: Probleme beim Multi-Document-Design
Zitat:
Ich habe bisher leider sehr oft die Erfahrung machen müssen, daß einzelne Kunden eigentlich immer nur die Lösung für ihr gerade aktuelles kleines Problem haben wollen. Dabei fehlt dann aber der Gesamtüberblick und man frickelt dann auf die Schnelle irgendwas zusammen. Genau um das zu vermeiden, setze ich mich ja im Vorfeld hin und überlege mir die möglichen Anwendungsfälle um dann eine konsistente Lösung zu erarbeiten. Aber trotzdem: Danke für die Vorschläge und Hinweise. Die unterschiedlichen Sichtweisen sind wirklich hilfreich. Übrigens: Word 2013 lässt ein zweifaches Öffnen derselben Datei nicht zu und springt dann direkt in die bereits offene Datei. Das wäre sicher am einfachsten zu implementieren. Versucht man ein Dokument unter einem Namen zu speichern, der dem in einem anderen Fenster geöffneten entspricht, wird das unterbunden. Ist sicher auch eine akzeptable Lösung. Das Verhalten von Notepad++ muss ich mir noch ansehen. |
AW: Probleme beim Multi-Document-Design
Zitat:
Die Delphi-IDE erlaubt es z.B. nicht, zwei Tabs mit derselben Datei zu öffnen. Dies geht aber sehr wohl in zwei Editfenstern. Damit kann ich dann auch zwei unterschiedliche Bereiche einer einzigen Datei am Bildschirm darstellen. Es handelt sich aber immer nur um die eine Datei und alle Umbenennungen werden zwischen den Editfenstern synchronisiert. |
AW: Probleme beim Multi-Document-Design
Zitat:
Ich würde dazu tendieren, die für Kunden am einfachsten zu verstehende Variante zu nehmen. Also vielleicht beliebig viele geöffnete Instanzen erlauben, aber ab der zweiten Instanz nur noch schreibgeschützt. Mag vielleicht nicht alle Kunden glücklich machen aber in meinen Augen besser als Beschwerden der Art zu bekommen, dass "irgendwas" von "irgendwem" "irgendwie" überschrieben wurde und natürlich "nichts gemacht" wurde. :wink: Oder als potentiell ultimative Variante eine Möglichkeit einbauen, die es dem Kunden erlaubt, die für ihn beste Verhaltensweise selbst zu bestimmen. Natürlich mit entsprechender Warnung für den Fall mehrerer frei schreibbarer Instanzen. Ist natürlich einiger Aufwand aber (Neu-)Kunden werden ers Dir hoffentlich danken. :) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:11 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz