[xwiki-devs] Implementing pseudoversions
Hello devs, Auto-saving the content during long edit sessions, to prevent the complete loss of data in case of browser or OS crashes, (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful feature that people have been asking for. For 1.9 there will be the possibility to enable autosave. However, the implementation is pretty basic, more of a hack on top of the current architecture: an asynchronous JavaScript calls periodically save & continue, marking the saved versions as minor and setting the version comment to "(Autosaved)". This approach has some obvious disadvantages: - A lot of minor versions are created during the editing - Cancel does not undo the changes (a revert could be done to the version at the beginning of the editing session, which creates yet another document version) ... but at least it's a start. For properly implementing this in the future, some important changes are needed. In particular, the support for pseudoversions (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document. These pseudoversions will be memorized in a new table, similar to the document table or the recycle bin. Along with introducing pseudoversions, several behaviors should be changed, improving the user experience. For instance: - In all editors, "Save & Continue" should become "Save draft" and should create pseudoversions that can be canceled, and "Save and View" should become simply "Save" (these texts are also much easier to understand by the user). - In class editing, properties are added in the pseudoversion, and these changes can be canceled when the user presses the "Cancel" button. (canceling property addition is not possible ATM, unless the document is reverted). - In the object editor, objects can be added in the pseudoversion, and all changes can be saved at once. These changes are pretty substantial, from the data management and user experience point of view, but I believe it is worth making the step. Please tell me what you think. Should we try to get this done before 2.0? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Why invest in "pseudoversions" when they're not really needed. It's just more stuff to break, maintain, etc. Is there any reason why the draft can't be autosaved in a similarly named document ... for example emacs autosaves files with '#' leading and trailing, e.g. #cspanplayer-embed.vm# When the document is explicitly saved, the autosave is deleted. On document edit, if modify-time of the autosave file is later than the file it is autosaving for, pop a dialog with the times & sizes & a "diff" which allows the user to choose whether to edit the orignal file or continue editing the autosave file. If autosaving to a similarly named file isn't considered elegant, how about reusing the existing mechanisms of the recyclebin. Autosaves go into the recycle bin, using its facilities keep track of the original document associated with the auto-save. They can be recovered by deleting the original and restoring the auto-save. Niels http://nielsmayer.com On Sat, Apr 25, 2009 at 9:05 AM, Sergiu Dumitriu <[email protected]> wrote:
Hello devs,
Auto-saving the content during long edit sessions, to prevent the complete loss of data in case of browser or OS crashes, (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful feature that people have been asking for.
For 1.9 there will be the possibility to enable autosave. However, the implementation is pretty basic, more of a hack on top of the current architecture: an asynchronous JavaScript calls periodically save & continue, marking the saved versions as minor and setting the version comment to "(Autosaved)". This approach has some obvious disadvantages: - A lot of minor versions are created during the editing - Cancel does not undo the changes (a revert could be done to the version at the beginning of the editing session, which creates yet another document version) ... but at least it's a start.
For properly implementing this in the future, some important changes are needed. In particular, the support for pseudoversions (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document. These pseudoversions will be memorized in a new table, similar to the document table or the recycle bin.
Along with introducing pseudoversions, several behaviors should be changed, improving the user experience. For instance: - In all editors, "Save & Continue" should become "Save draft" and should create pseudoversions that can be canceled, and "Save and View" should become simply "Save" (these texts are also much easier to understand by the user). - In class editing, properties are added in the pseudoversion, and these changes can be canceled when the user presses the "Cancel" button. (canceling property addition is not possible ATM, unless the document is reverted). - In the object editor, objects can be added in the pseudoversion, and all changes can be saved at once.
These changes are pretty substantial, from the data management and user experience point of view, but I believe it is worth making the step.
Please tell me what you think. Should we try to get this done before 2.0? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Niels Mayer wrote:
Why invest in "pseudoversions" when they're not really needed. It's just more stuff to break, maintain, etc.
I don't agree, pseudoversions are needed not just for autosave, but they will be needed for more advanced collaborative features envisioned for the future. Plus, any change is more stuff to break and maintain, not just new stuff.
Is there any reason why the draft can't be autosaved in a similarly named document ... for example emacs autosaves files with '#' leading and trailing, e.g. #cspanplayer-embed.vm#
Filesystems aren't databases. When you work with a file, you know where to look and you're interested in one item. Plus, filesystems are mostly used privately, without hundreds of users lurking in the same directory. Putting pseudo-documents in the same database means that all queries must work around them, which reduces the performance in many ways: - complex queries - bigger indexes - larger files - more memory needed to store the same amount of real documents + extra pseuodoversions - for a collaborative Doodle storage, there will be several updates per minute per edited document per user, and such an intense traffic means that the actual documents will be much slower to retrieve, if the two don't use different databases And the usage patterns of the two types of entities is different. Documents are more often read than written, while pseudoversions are frequently updated.
When the document is explicitly saved, the autosave is deleted.
On document edit, if modify-time of the autosave file is later than the file it is autosaving for, pop a dialog with the times & sizes & a "diff" which allows the user to choose whether to edit the orignal file or continue editing the autosave file.
If autosaving to a similarly named file isn't considered elegant, how about reusing the existing mechanisms of the recyclebin. Autosaves go into the recycle bin, using its facilities keep track of the original document associated with the auto-save. They can be recovered by deleting the original and restoring the auto-save.
While this is better than storing in the main table, it still isn't nice. We're using things for something they are not meant to handle. This is called a "hack", and hacks are not good. Hack badly solve problems for lazy people, but will later come back and haunt them. And this means that autosave depends on the recycle storage, so it creates an artificial bond between two separate features.
Niels http://nielsmayer.com
On Sat, Apr 25, 2009 at 9:05 AM, Sergiu Dumitriu <[email protected]> wrote:
Hello devs,
Auto-saving the content during long edit sessions, to prevent the complete loss of data in case of browser or OS crashes, (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful feature that people have been asking for.
For 1.9 there will be the possibility to enable autosave. However, the implementation is pretty basic, more of a hack on top of the current architecture: an asynchronous JavaScript calls periodically save & continue, marking the saved versions as minor and setting the version comment to "(Autosaved)". This approach has some obvious disadvantages: - A lot of minor versions are created during the editing - Cancel does not undo the changes (a revert could be done to the version at the beginning of the editing session, which creates yet another document version) ... but at least it's a start.
For properly implementing this in the future, some important changes are needed. In particular, the support for pseudoversions (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document. These pseudoversions will be memorized in a new table, similar to the document table or the recycle bin.
Along with introducing pseudoversions, several behaviors should be changed, improving the user experience. For instance: - In all editors, "Save & Continue" should become "Save draft" and should create pseudoversions that can be canceled, and "Save and View" should become simply "Save" (these texts are also much easier to understand by the user). - In class editing, properties are added in the pseudoversion, and these changes can be canceled when the user presses the "Cancel" button. (canceling property addition is not possible ATM, unless the document is reverted). - In the object editor, objects can be added in the pseudoversion, and all changes can be saved at once.
These changes are pretty substantial, from the data management and user experience point of view, but I believe it is worth making the step.
Please tell me what you think. Should we try to get this done before 2.0?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
+1, sounds good On Sat, Apr 25, 2009 at 18:05, Sergiu Dumitriu <[email protected]> wrote:
Hello devs,
Auto-saving the content during long edit sessions, to prevent the complete loss of data in case of browser or OS crashes, (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful feature that people have been asking for.
For 1.9 there will be the possibility to enable autosave. However, the implementation is pretty basic, more of a hack on top of the current architecture: an asynchronous JavaScript calls periodically save & continue, marking the saved versions as minor and setting the version comment to "(Autosaved)". This approach has some obvious disadvantages: - A lot of minor versions are created during the editing - Cancel does not undo the changes (a revert could be done to the version at the beginning of the editing session, which creates yet another document version) ... but at least it's a start.
For properly implementing this in the future, some important changes are needed. In particular, the support for pseudoversions (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document. These pseudoversions will be memorized in a new table, similar to the document table or the recycle bin.
Along with introducing pseudoversions, several behaviors should be changed, improving the user experience. For instance: - In all editors, "Save & Continue" should become "Save draft" and should create pseudoversions that can be canceled, and "Save and View" should become simply "Save" (these texts are also much easier to understand by the user). - In class editing, properties are added in the pseudoversion, and these changes can be canceled when the user presses the "Cancel" button. (canceling property addition is not possible ATM, unless the document is reverted). - In the object editor, objects can be added in the pseudoversion, and all changes can be saved at once.
These changes are pretty substantial, from the data management and user experience point of view, but I believe it is worth making the step.
Please tell me what you think. Should we try to get this done before 2.0? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Niels Mayer -
Sergiu Dumitriu -
Thomas Mortagne