Re: [Usability] Merge Open/Save (was "Re: Save Icon")

[Diego Moya <turingt gmail com>]

On 08/02/06, David Christian Berg <david sipsolutions net> wrote:
> On Tue, 2006-02-07 at 17:43 +0300, Alexey Rusakov wrote:
>
> > This is close to what Jef Raskin proposes in his "Humane Interface"
> > book. The idea is that instead of Open/Save there should be exactly one
> > button (he names it "Disk", IIRC), that does all the work. If the
> > document is newer on disk and not changed in the memory, it loads the
> > document. If it is changed in the memory (i.e. it is newer that a copy
> > on disk), this button performs "Save". Well, and if there is a conflict,
> > the button reveals it, and lets the user decide. I think this idea is
> > quite promising.
>
> I strongly object! First of all, one button should not perform two
> totally different things -- and open vs. save is definitely not similar

You'll find that in, user interface design, frequently what is
"similar" or "different" is a very subjective matter. In this example,
I could label that button "Synchronize". Suddenly both the "save" and
"open" operations are the same in that context.


On 08/02/06, Joachim Noreiko <jnoreiko yahoo com> wrote:

> "Save As..." and "Make a Copy..." are different. One
> moves focus to the new filename, the other does not.
>

I disagree. I've seen several applications where "Save As..." also
moves focus to the new file (the previous file is left in the
background, unsaved). (I can't recall specific applications, and maybe
they were Windows-based - not Gnome. But we're talking about mental
models here, not operating systems).


> What about "save because there might be a power cut"?
> Or "save because I'm going to make a coffee and my cat
> might jump on the keyboard"? or just "save because I'm
> paranoid about crashes"?

Of course, an advanced persistence system should take care of that
problem and solve it once and for all. We are trying to build systems
where ideally users *shouldn't* need to worry and be paranoid that
every little mistake in use or system failure could ruin their
precious work.  Jef Raskin called it "treat user work as sacred": the
primary focus of a system should be not allowing those catastrophic
scenarios to happen.

So the first step should be to remove from the user model the
differences between RAM and hard disk (which is an implementation
detail and shouldn't be exposed). Until we assume that problem to be
solved, we can't really begin to experiment with more advanced user
models of data persistence.