[IxDA Discuss] Should closing a window save changes?

[Jim Drew]

>From: Sebi Tauciuc <stauciuc at gmail.com>
>
>> I have great respect for Raskin's work and writing, but in this case
>> he's just flat wrong.  By automating Save, we take away the security
>> of a 'sandbox' in which a person can doodle, write drafts, project
>> possible futures, or whatever sort of data processing the application
>> permits.  It's like going around and taking the erasers off of
>> everyone's pencils.
>
>I disagree. The erasers on everyone's pencils should be the Undo mechanism.
>Writing on a paper should mean(or should have meant) that the pencil
>actually leaves a mark on the surface, not that the mark is recorded
>somewhere in mid-air and will only get written on paper when we say "Save".

Sure it should.  Think of the added power and flexibility that would from such an intermediary, not-yet-committed state.  Just think of the savings on paper and ink.

Don't confuse the fact that "pen on paper leaves mark" is so ingrained into us that it's hard to conceive of some other mechanism with the current situation actually being *better*.

There are definite benefits to not having to do an explicit save.  There are also problem scenarios that it raises.  The question isn't whether those scenarios are detriments which are fatal to automatic save, but whether we can design suitable ways to mitigate things such that the scenarios are not (as) problematic.

The value of a "sandbox" is one such scenario; how can we provide a sandbox that ties easily and seamlessly to the automatic save?  Can we, for example, have an "Open as Sandbox" command which creates an automatically-saving duplicate of the original which can be committed at some  point to merge its stream back onto the original, or be dismissed without harming the original?  Can we (singly or as multiple users) open multiple such sandbox variants, including sandboxes of sandboxes, and be easily able to prune, merge, and even graft the tree of sandboxes?

-- Jim