Apply, Close... (Re: gnome-stock pixmaps)



>> So you are saying that I must Apply+Undo+Close if a change something but I
>> do not like it.
>> 
>No -- two clicks: Undo+Close
>(Sequence like so: change=>Apply|Undo=>[Undo]=>Close)

Two?
Change Apply Undo Close    4 things
Change Close               2 things

And why you write Apply|Undo?
Changes must be applied, no autoapply (I think).

>If Close means (Apply+Close) then Close should be available always.  However,

I do not say Apply+Close, I dislike it.

>this means that people who don't want changes to be applied must hit a Cancel
>button which is notorious for doing something different in every app that it
>appears: Cancel can equal (undo to initial state+Close) (undo to last
>Apply+close)  and others less enticing.

No Cancel please. If a buttons says one word it should has *one* clear
meaning (or dictionary writers should then change their books so when you
look for a word you get a response with two parts: X=Y+Z).

>Russell Nelson proposed Close, apply, undo instead of close, apply, cancel
>and proposed that close mean (Close) without apply [and therefore, should not
>be available unless the state of the dialog is known via Apply, undo, or no
>change.]

Changes until Apply means no real change. The change is in the panel, not in
the target. And Apply button is now avaliable to show that you have changed
something and can be applied.

>Undo should be available as soon as a change is made; but should undo to the
>previous Apply level.  This is the last time apply was hit, or the initial
>state of the dialog. (And the states can be stacked).

Aaaahhh, so you can undo a change in the panel but that it is not applied to
the target. Now I understand you better. Maybe you have reason, I have to
think deeply now that I understand you.

Lets do a example to test that I really understand it:
I have a window to configure desktop. I do a change (ie, colors). I can undo
(colors in the window rectangles) or apply (colors of the desktop) it. To
close I must be after a undo or apply action. In other words what the window
says is what I see for example as desktop colors.

Is the example OK?

If yes, Undo has two meanings: undo previously applied things *and* undo
last changed things (applied or not).

>I agree more with the terror, actually :-)  2 clicks isn't bad and it is all
>internally consistent.  However, it is not like other system's dialog boxes
>[where close means (close+apply) and therefore is always available].  However,
>because it is unlit when there's changed state, they will adjust to the
>difference very quickly.

Other systems... sometimes you must forget all you know to start learning.

>OTOH, we could make Close mean (Close+Apply) and leave it always available --
>this isn't as elegant, but it does what most users expect from a close button
>and allows you to close on a "wanted change" with one click.

I disagree on that. The button says "Close" not "Apply+Close".
So delete that "common" (and wrong) way from solutions list.

>You are going to need to clarify this.  Because anyone who has used a dialog
>box in a program has come to expect that Close means (Close+Apply).  Simple

If the other system is wrong but used a lot I will not do the same (humans
kill each other, should I?). Close is a verb that means one thing. I have
not find a dictionary where Close is explained as Apply+Close. Maybe I have
to search in a "computer dictionary"...

>(Close) functionality is usually applied to the Cancel button.  Although it is
>not clear what state to leave the app in when simple (Close) is used [reset
>dialog to last apply or initial state?)

Cancel is a bad button. The GUI designer of that button have a twisted mind,
Cancel is cancel, not cancel and close the window (I speak of a real window
that must stay alive, not the "Do this? Yes-No").

>Russell's use of Close to mean (Close) without apply initially made me feel
>that it was breaking with convention too much -- but his idea to have the
>Close button unlit until either Apply or Undo is hit marries nicely with it:
>the user must specify whether to keep or remove changes rather than having to
>guess what the programmer decided the button should do.  This is an elegant
>solution.

Convention != Right
Law != Justice

>Right: target audience is people who not only can, but do use a computer
>already.  And therefore, people who already see Close as (Close+Apply) [The
>damage is done; the word is already redefined]  If we are going to un-redefine
>the word to mean (Close) then we are going to have to give the user visual
>clues so they don't do something they don't expect; disable Close unless the
>changes have been synced (either Applied or Undone).

We must redefine the word. Cos the actual definition is wrong. "The Earth is
in the center of the Solar system", do you remember? ;]

That you must give clues, yes, true... but I do not think users will notice
a lot... last week my sister complained about that she must learn where are
menu functions in every app of Windoze. And had problems with keybindings
too. If all Gnome has the same behaviour (Gnome behaviour != Windoze
madness) the problem is little, maybe zero.

Users will have to adapt to new system. The important thing is consistency,
specially with normal world, not computer world. All things have a learning
curve, just make it easy but not by copying other curves (Windoze is a
zigzag ;] ).

GSR
 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]