[wp-hackers] Autosave

[Roy Schestowitz]

___/ On Mon 02 Jan 2006 06:14:44 GMT, [Robert Deaton] wrote : \___

> On 1/2/06, Andy Skelton <skeltoac at gmail.com> wrote:
>> As long as it's a hot topic, let's give it a proper subject and proper
>> treatment.
>>
>> The big idea is to keep a copy of the textarea on the server without
>> the user having to click Save.


In principle, you could also make use of the memory (e.g. the clipboard). As
Amit pointed out, any attempts to write to disk should be avoided. JavaScript
does not permit this and it would be the bad choice on alien computers.

Dumping copies to volatile memory wouldn't enable recovery from reboots. It
will, however, compensate for browser crashes, editting 'hiccup' and so forth.


> Let's settle on some details before
>> somebody jumps in to write the code. (It's a new feature anyway,
>> something that won't be put in the core at this point in the dev
>> cycle.)
>>
>> I like Matt's idea of sending the content to a user option. I'd keep
>> it to one bucket per user so there is no extra UI required.


I initially thought about a reserved post slug, which only serves as an
emergency copy, a last resort. This doesn't have to be anything
mission-critical. Users would happy enough be restore /any/ bit of lost work.


>> Here's a possible scenario:
>> 1. User starts typing masterpiece in New Post/Page screen
>> 2. At intervals of seconds or keystrokes, content is silently sent to server
>> 3. Server saves it in that user's autosave bucket
>> 4. Cat chews through PC power cord (any catastrophe will do here)
>> 5. User switches computers, goes to Write Post/Page screen
>> 6. Server sees autosave populated, gives user the option to recover
>> 7. User clicks "Yes, please recover my typing!"
>> 8. Server responds with New Post/Page screen with textarea populated
>> 9. User dedicates masterpiece to dead cat and WP Autosave, clicks Publish
>> 10. Server clears the user's autosave bucket on Publish or Save
>>
>> The interval in Step 2 is a design decision or user option.


I wonder if mouse motion can somehow be detected without JavaScript obtrusion.
It might be useful here.


> I do love the way that gmail does this. If I remember correctly, at
> one minute intervals, gmail saves a copy of what you are writing as a
> draft. There is a small, unobtrusive button, that lets you "Save Now"
> if you just wrote something you really don't want to lose. You can
> then close your browser, or browse elsewhere, come back, and pick up
> where you left off.
>
>> In Step 3, the content should be filtered (KSES, etc.) before saving.
>
> agreed.


Yes, it simplifies matters.


>> Step 5 demonstrates how this is better than using cookies. (One of
>> many reasons.)
>
> Agreed entirely.
>
>> Step 6 can be via a JS confirm dialog but it might be more accessible
>> and less obtrusive as a message box such as we use for published
>> posts, saved options, etc.
>>
>
> I think that this would be the one major downfall, and is the thing
> that I've hated about OpenOffice 2 since release, (although its not
> quite fair, they're a desktop app). Instead of having some sort of
> message that we detected an autosaved post, stick it as a draft, put
> it up in the drafts area, and leave it be. Users will be able to see
> that their post is there when they return, and the autosave feature
> becomes useful for not only emergency saving.


I can't say I agree. Users expect that message to come up. They know they have
lost work, so assuming a crash can be detected, a prompt would be a top
priority. Office suites do it and also a LaTeX editor that I use. It is
relieving to see that prompt rather than having to explore.

It's important never to suggest recovery under the wrong circumstances. 
If that
happens, it can result in data /loss/ rather than recovery. How to actually
detect crahes is a whole different matter which is equally important.