On 08/02/06, David Christian Berg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
