Design/Algorithm: Two 'dirty' states per document [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

Encountered a challenging situation, please help with the design decision.

I have an application dealing with 'A Document', which as actually some collection of data, not-so-important of which kind.

The data (the document) is managed through the application, and the standard mark as dirty / request save / save / save as workflow is maintain开发者_开发问答ed.

In addition to the main application functionality a number of plugins are developed, which are used for data analysis during its editing. It is assumed that these plugins may need a persistent data storage for some of their settings.

This data storage is an in-memory dictionary attached to the decoment instance, and it is later serialized to the document file, and deserialized on document load.

So, when an application starts and the document is opened, the extra data are read from the file. Then, as you browse the document, you can possibly run some plugin-based reports. The plugin would request for settings, and store them in the document extra-data. Then, this extra-data is supposed to be saved to the document file.

Thie gives us 2 dirty states: the document state (if it was changed during the session) and the extra-data dirty state.

Now, if the document was not changed, but the extra-data was, I assume the user is fine to save the extra-data, and silently save the document.

If the document was changed, and the user saves it, the extra-data is saved with the document, which is fine.

But what is the best solution if both are dirty, and the user says 'No, I don't like saving the document changes'. At the moment I notify them thet the extra data (plugin settings) would be lost as well. Saving data itself (and providing a separate option 'Save settings only') is possible, but a bit tricky.

Your opinion - which way is the most logical?

---

I think it's important that your application behaves consistently - either always save the plugin data silently, or always request whether the plugin data should be saved. I think changing the behaviour of the plugin save depending on whether the document content has changed will probably result in confusing behaviour to the user.

Without knowing about your application, I feel that if it makes sense to save the plug in data silently when the plugin content has changed but the document hasn't, then it probably makes sense to save the plugin data silently when the user changes the document content but doesn't save it. However, I also feel that that behaviour is unlikely to make sense for many applications- a "no, I don't want to save" probably shouldn't result in a hidden save of some of the things that have changed.

Consequently, I propose the following solution that is both consistent and clear to the user:

1. Maintain both flags as in your example, but treat the two dirty flags as one flag from the user's perspective - when either flag is dirty, pop up a "save changes?" dialog.
2. Use the information in the flags to determine the text of the dialog - eg "The plugin settings have changed since the last save" or "The plugin settings and document has changed" etc. This way the user always knows why the save dialog has appeared, and there's always one dialog.

For extra credit, you could even be specific about which plugins settings have changed.

I also agree with Miilimetric's observation that allowing partial saves might produce unpredictable behaviour with multiple users - if the settings can affect the way the document is treated, they should probably be treated as part of the document content from a saving perspective.

---

If you truly want to be able to save the extra data separately from the document, then you can do one of two things:

1. If it's possible to determine the maximum extra data size, and if that size is relatively small, you can define a header section of the document file where you can save only the extra data.
2. Save the extra data to a separate file and link the two files (either through some operating system mechanism or logically in your application).

However, I'd caution against allowing the user to save the extra data without the document. What if two users are separately changing the extra data and document? If they both save them separately, wouldn't the result be unpredictable for both users?