[sugar] Control Panel Buttons ?

[Eben Eliason]

On Sun, Jul 13, 2008 at 8:29 PM, Mikus Grinbergs <mikus at bga.com> wrote:
> Whatever else,   when dealing with non-computer-literate persons, I
> believe that EACH visual icon __must__ universally convey only a
> __single__ meaning.

Agreed.  In some case it's tricky to balance the simplicity of a few
concise symbols with a set of tasks which have subtler semantic
differences, but some of the examples you bring up should certainly be
addressed.

> Within the sub-functions, the 'X' button (labeled 'Cancel') appears
> to convey the concept:  "Throw away whatever it is that you have
> done."  I personally would wish this button to be modal - and have
> it be 'grayed out' in the header until the kid makes a change. [I
> would expect a kid to understand (for 'X'):  "I'm through.  Let me
> out of here, but wipe clean all materials that I worked with".]

I agree with the semantics for the icon expressed here.

> Within the sub-functions, slightly more problematic is the 'check'
> button (I would label it 'Apply') which appears to convey the
> concept:  "I approve.".  I personally would wish this button to be
> modal - and have it be 'grayed out' in the header until the kid
> makes a change.  [I would expect a kid to understand (for 'check'):
>  "I'm done.  Let me out of here, as soon as you have changed the
> settings within the system to what I've specified here".]

Likewise here.

> That leaves the situation where the subfunction was called to look
> at the values, not to change them.  I personally would want the
> sub-functions to have a (third) 'left-pointing triangle' button
> (labeled 'Back') in the header, active to begin with.  This button
> would be modal - when any change gets made using the facilities of
> the sub-function, the 'Back' button gets 'grayed out', but the 'X'
> and 'check' buttons get activated.  [I would expect a kid to
> understand (for 'left-pointing triangle'):  "I didn't do anything.
> Let me out of here." ]

While you're reasoning is sound, and I agree with the semantics above,
I wonder if this actually confuses things a bit more than it needs to.
 To keep the language and the choices simple, I'd suggest making only
the 'check' button modal.  The 'X' button, then, would always be
clickable, and would actually mean in the weak sense "I'm through.
Let me out of here," and in the strong sense also mean "and wipe clean
all materials that I worked with". The 'check' button would remain
insensitive until a change is made, to illustrate the idea that you
can only "accept/confirm" changes once they've been made.

I think this makes the choice binary, which is simpler (either I want
to make changes, or I don't, regardless of the fact that I've /viewed/
the settings).  It also makes the use of the 'X' button acceptable for
things like closing dialogs which don't expose a choice, and similar
actions which close/dismiss.

> All uses of an 'X' button should convey the same concept:  "Forget
> it".  Turns out the Journal 'details view' pane employs the special
> interpretation that its buttons apply to the Journal_entry [instead
> of to the pane in which that 'X' is shown].  Thus the 'X' button in
> the 'details view' pane header is used to 'Erase' the Journal_entry

This is going away. To prevent confusion, we're going to continue to
use the '-' symbol to indicate erasure/deletion, and reserve the 'x'
for cancel/close.

> itself, whereas all exiting (in the current Joyride implementation)
> from the 'details view' pane [whether or not the kid made changes to
> the (text) content of that pane] is handled by an "active line"
> located below the pane header [that active line is "identified" by a
> 'left-pointing triangle' icon ('Back') drawn within that line].

Based on this, we /could/ actually use a small 'x' button in the
'back' bar to mean 'dismiss this detail view'.

>
> In 'Develop', the functions of the 'X' button and the 'check' button
> seem to be reversed -- 'check' throws away what was done, and exits.

That doesn't make any sense to me; I wonder if that's a mistake.  That
probably deserves a specific ticket.

> I would say:  "NO No no -- visual symbolism __must__ be consistent".

Agreed.  Please create tickets for specific items mentioned here
(preferred), or at least one high level ticket siting some of these
examples, so that we don't lose sight of it.  Thanks!

- Eben