Problem: Unsaved changes get lost forever when the browser gets closed (by mistake, browser crash, power-failure etc.).
An example
You write a longer article on a wiki page, but don't want to save the document all the time because it
- bloats up the history
- interrupts your editing
- creates useless diffs
You use the preview function every now and then, but only save once you are finished. If your browser closes before you save, all changes are gone - long face.
My solution
Because of the three reasons I mentioned above I write longer wiki texts in a local editor (where I can quickly save all the time) and paste it back into the edit field once I am done. Does someone know the "Jesus saves" joke? Well, that's why I like saving.
Other people
Have you lost hours or at least countless minutes of work when you lost changes to a document? Well, then support this feature request.
A possible Moin solution
GMail has a very useful "Save Now" button. An email gets saved as a draft when you press it the first time and every time you press it afterwards your changed get saved into that draft. When saving, the page does not get reloaded, only the Save Now buttons gets greyed out and you can continue editing without losing your position in the text. In case of a browser failure you can quickly recover your text from the Drafts folder. I think even some console email clients have a feature similar to that.
I am really missing something like this in Moin. It would be confusing to name the button "Save Now", so let's call it "Save Draft" (GMail used to include the word "Draft" on that button, and it was more obvious then). It could work like this: Moin registers a draft for a document when Save Draft is pressed and writes to this draft every time the user presses Save Draft. Once the user presses "Save Changes" the draft gets deleted. But if the editing lock expires and someone presses "Edit" on a document and a draft with a newer time stamp than the last version of the document is found, the user will be asked "An unsaved version of this document was found. Would you like to restore the changes from this draft or compare the changes?". The user then can press "Discard draft", "Compare changes" or "Restore from draft".
I am aware that this requires quite some Moin hacking, but I think this feature would be a great relief for many people. What do you think?
Discussion
Its already implemented, its called UserName/MoinEditorBackup. This page keeps the last preview you did - if your browser crashed you will loose only the stuff you wrote after the last preview. Anyway this kind of problem is client side problem, if you use a tool that crashes you should replace it or use a safer editor that let you save quickly or automatically. Moin can't save the data on your end unless you preview. --NirSoffer
- Hey, that's great "news"! I just created a homepage in my wiki and it worked. Now there are some problems with this solution:
- only registered users benefit
It's hard to see how to get around this; the draft needs to be saved with some binding to the author's identity, and that registered username is what's available for that. Changing this means changing the notion of user identity. --FredDrake
The draft could be connected to the document, rather then to the user identity. At a similar place where the edit lock resides for example (I don't know the Moin architecture). --BuckRogers
There's clearly a document association as well; by connected I did not mean to imply specific storage locations. Regardless of the storage, there needs to be a connection (of some sort) to the user; I don't want my incomplete changes being available to others. I might want to revise an explanation before publishing, for instance, but have to attend to other matters before time will be available. --FredDrake
- you need to create a homepage before it works
Not sure that's a significant issue, but I could imagine it being automatically created from a template if it didn't already exist. --FredDrake
If a "Save Draft" button is completely out of question, this would be a sensible thing to implement. --BuckRogers
- you still lose your position in the text (you need to scroll up in the preview window, and scroll down in the edit window)
- it is not very usable (you need to know and type the name of the backup file and restore by hand)
It would be nice to have some additional niceness along these lines. But I do think that's all it really is; it isn't necessary. --FredDrake
Sorry, you lost me, I don't get the "nice" part (is it about my tone?) and what is not necessary? --BuckRogers
No, your tone if fine.
I meant that having this feature in the wiki (on the server), while convenient, adds complexity without being necessary to the functioning of the wiki. I'm a big fan of simplicity in software; it has to do with reliability --FredDrake
If I look at this wiki I see a handful of unregistered users and some registered users without a homepage. I expect the situation will be similar in most Moin wikis out there. So only very advanced users of a wiki have access to the backup feature. Don't get me wrong, I can live with the way it works as it is, now that I know about it. But if you are looking at improving Moin usability for every user, the backup feature should be more accessible or at least more obvious. --BuckRogers
It feels more like what you really want is a local application that's really good at working with a wiki, more likely using the XML-RPC interface than the web UI. I wouldn't be too surprised if there's something out there, though I've not looked for it myself. --FredDrake
I am quite happy with the way the wiki works and that I do not need a local application, but can jump from computer to computer and make changes. The only thing that bugs me is that my typed text is at risk if I don't interrupt my editing and press preview. I don't want to preview, I just want to save. From the usability point of view the preview button then does the wrong thing and I use it as a workaround for a missing feature.
I would like to ask some non-advanced wiki users what they think, how safe their text is before they press "Save Changes". A friend told me, when he is under time pressure he copies out the text from the edit field before he submits, just to be on the safe side (we all have seen web forms that timed out and when you went back via the browser button they were empty).
I admit my addiction for saving has to do with how my brain works. Once I write down a thought it's gone from my head and frees space. I use "mv" instead of "cp" if you want. So every loss of a document hits me harder than other people. But that's besides the point. --BuckRogers
I like the way it works as well. But I'm also happy to copy text out if I think I'm going to spend a long time editing. One of the nice aspects of wikis is that the server implementation doesn't have to be terribly complex to be effective. Adding more "desktop" behavior to a web application definately adds complexity beyond what the same features would add to the desktop version of that. While it would be nice to be able to save a draft on a wiki and walk back up to it from another machine, that's doesn't seem like a huge value to me. I'm not trying to imply that it shouldn't be important to you, but I'm trying to explain why it won't be considered a pure win by some. --FredDrake
When I write long and important text that I may need to read and fix few times before I publish it, I use a real text editor. Sometimes I use my private local wiki and save lot of times. Its fast to work on a local wiki, and its easy to remove temporary pages and their backups.
I think the only needed improvement is an easy way to get the backup, could be an entry in the More Actions: menu or maybe a link in the home page or in the editor, or maybe simply get the last preview content when you open the editor after a crash. Other improvements can be considered later after more important problems are solved. -- NirSoffer 2005-09-28 00:06:40
Is there any additional information on how and in which version the feature has been implemented? --BuckRogers
see HelpOnPageCreation -- ReimarBauer 2006-01-30 12:28:21
Design and Implementation
There needs to be a separation of features so the requirements can be defined a bit better. From reviewing the above I can spot at least two features.
A SessionDraft file which is available for a user session, which could support a conditional save, where the file would be named WikiName.Session.${EditCookie} which could happen in the background, even while typing say every 1 minute, or on a dedicated SaveDraft button.
When the user presses SaveChanges the SessionDraft WikiName is written and an atomic move is performed on the file system.
Compare the TimeStamp of the FinalCopy with the TimeStamp of the SessionDraft to check for RaceCondition and to notify the user of a Rollback. When the TimeStamps are sequential then the SessionDraft is deleted.
When the user edits a WikiName the user is shown the FinalCopy with their SessionDraft diffs applied.
A TwoPhaseCommit procedure for publishing where all WikiName SessionDraft files are enumerated and diffed against the FinalCopy. The WikiNameEditor can then see which SessionDrafts were successful unsuccessful aborted etc.
Run a DeadSessionDraftReaper on Login to remove old and obsolete or aborted SessionDraft
Make the Authorization for editing a page, configuration conditional so a Wiki can allow AnonymousUsers to create a SessionDraft and contribute, When a AnonymousUser presses SaveChanges the SessionDraft is updated but the FinalCopy AtomicCopy is not performed.
Can I note that when talking about a SessionDraft I mean Session as in a TopiEditSession not a HTTPServerSession, I propose that the two are abstracted via an EditCookie, which is unique and does not expire. It is important that the EditCookie does not expire as to support editing multiple WikiName at a time.