Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Probleme beim Multi-Document-Design (https://www.delphipraxis.net/178952-probleme-beim-multi-document-design.html)

Uwe Raabe 5. Feb 2014 13:49

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?
Springe ich einfach zu der bereits offenen Datei oder öffne ich einfach nur ein zweites Editierfenster auf diese Instanz?
Was, wenn die bereits geändert wurde und der Anwender die Originalversion sehen will?
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?
Wie wirkt sich das auf die andere Datei gleichen Namens aus?

Mir geht es hier gar nicht darum, wie das implementiert werden kann, sondern erstmal welches Verhalten ein Anwender intuitiv erwarten würde.

Bernhard Geyer 5. Feb 2014 13:50

AW: Probleme beim Multi-Document-Design
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1246798)
Mir geht es hier gar nicht darum, wie das implementiert werden kann, sondern erstmal welches Verhalten ein Anwender intuitiv erwarten würde.

Probier mal das doppelte Öffnen mit Word/Excel und Co.
Und mach es dann genauso. Denn genau dieses Verhalten werden viele Erwarten.

Nersgatt 5. Feb 2014 13:54

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.

Bummi 5. Feb 2014 14:03

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.

Bentissimo 5. Feb 2014 14:58

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.

Jumpy 5. Feb 2014 15:54

AW: Probleme beim Multi-Document-Design
 
Zitat:

Zitat von Bummi (Beitrag 1246805)
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.

Ist das nicht eigentlich auch so, das bei einer geöffneten Datei, wenn diese anderswo nur geöffnet(!) nicht auch noch gespeichert wird, schon nachgefragt wird, welche Version beibehalten werden soll?
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.

p80286 5. Feb 2014 16:53

AW: Probleme beim Multi-Document-Design
 
Zitat:

Zitat von Jumpy (Beitrag 1246835)
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.

Mir wäre das nicht egal!

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

Uwe Raabe 5. Feb 2014 17:09

AW: Probleme beim Multi-Document-Design
 
Zitat:

Zitat von Bentissimo (Beitrag 1246822)
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.

Grundsätzlich keine schlechte Idee - wenn es denn nur um einen Kunden ginge. Neben den paar Tausend bestehenden, weltweit verteilten Nutzern (deren Meinung einzuholen ist schon mal ein logistisches Problem) möchte ich mit diesem neuen Feature ja auch potentielle Neukunden ansprechen.

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.

Uwe Raabe 5. Feb 2014 17:19

AW: Probleme beim Multi-Document-Design
 
Zitat:

Zitat von p80286 (Beitrag 1246846)
c) alle Änderungen an einer Datei werden zusammengeführt ( und Kollisonen gemeldet)

Das wäre ja durch die Bearbeitung ein und derselben Instanz in zwei Editfenstern von Haus aus schon der Fall. Änderungen in dem einen Editfenster würden im anderen direkt sichtbar, wobei beide Editfenster unterschiedliche Bereiche anzeigen können. Das ließe sich auch relativ leicht implementieren, wenn das Speichern als dann auch für beide Fenster gilt.

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.

Bentissimo 6. Feb 2014 08:04

AW: Probleme beim Multi-Document-Design
 
Zitat:

Grundsätzlich keine schlechte Idee - wenn es denn nur um einen Kunden ginge. Neben den paar Tausend bestehenden, weltweit verteilten Nutzern (deren Meinung einzuholen ist schon mal ein logistisches Problem) möchte ich mit diesem neuen Feature ja auch potentielle Neukunden ansprechen.
Dann ist das natürlich kein gangbarer Weg. :oops:

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