Re: gnome-stock pixmaps

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Tue, 05 May, 1998 at 06:30:16PM +0200, Guillermo S. Romero / unnamed / Familia Romero set free these words:
> >> initial_state.
> >> change1
> >> Apply
> >> change2 change3 Apply
> >> Undo [reverts to initial+change1]
> >> Undo [reverts to initial_state]
> >> 
> >> Close would be active after either an Apply or an
> >Undo (only inactive after a
> >> change.)
> 
> 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)

> Close and help should be avaliable always. The function is immediate, so you
> can close after change anything without appling (for example you change a
> number by error, with you system you must apply and undo before close).
> 
If Close means (Apply+Close) then Close should be available always.  However,
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.

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.]

> Apply only avaliable when a change is made.
> Undo when a change is 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).

> >Are you trying to drive your users away in absolute
> >terror, or merely confuse them into a docile stupor?
> 
> 3 clicks to close a unwanted change. Long. Dunno if terror, but users will
> become tired.
> 
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.

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.

> >Seriously, to resolve these recurring problems, we
> >will eventually have to come to terms with our target
> >audience.  Until we do, many otherwise excellent
> >programmers will continue to make themselves their
> >target user.  
> 
> I asked my sister and mother, both think close should be always avaliable
> and inmediate, no "Unapplied changes. Close anyway?" window. They are smart,
> no computer gurus, but smart, they understand perfectly words like Close and
> Apply (two words, two buttons, no "Close+Apply" button). [This last phrase
> about "smart" may sound offensive... ;] not intended]
> 
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
(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?)

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.

> Thats the public we target, ppl who use a computer and can understand
> things, not vegetables with communication problems. And the less a user as
> to learn, the happier he is (so why redefining/extending the meaning of
> words?). ;]
> 
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).

-Toshio
> GSR
>  
> 
> 
> -- 
>          To unsubscribe: mail gnome-gui-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.

-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature