[Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

[Eben Eliason]

On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan <acahalan at gmail.com> wrote:
> Eben Eliason writes:
>
>> palettes, we aimed to reduce accidental invocation
>> of them without entirely eliminating discovery by increasing the
>> delay.
> ...
>> I'm more worried about immediately revealing of all secondary
>> actions, which pull attention from the more efficient manner in
>> which basic actions can be performed - namely, clicking on the
>> big icons.
>>
>> If we can do this in a manner which doesn't distract from the
>> primary interaction methods and encourage inefficient paths
>> through the UI, that would be great.
>
> I believe this was first solved by Kid Pix, a few decades ago.
> One button bar swaps out another button bar.
>
> Microsoft's ribbon looks like the same thing, though I've never
> used it so I can't say for sure.
>
> Tux Paint certainly uses this model. In that case, it works fine
> for kids **way** below sugar's target age. (smart 2-year-old or
> regular 4-year-old for sure, possibly younger)

Yeah. This is very similar to the now implemented redesign of the
toolbar system for activities, which feedback has indicated is a huge
improvement. However, it doesn't instantly solve the issue for freely
positioned UI elements, such as people and activities within the
various zoom levels. There may be a variation on the technique that
could work in these contexts, of course, and some interesting
possibilities have already been suggested.

>> Another possibility would be to educate children about right click
>> somehow.
>
> On the one hand, I think it's really important to do this. Besides
> the human-compatibility issue and the extra expressive power, I think
> using a second button will help to develop the mind a bit. (you're not
> just grabbing or poking when you click; you're performing an action
> that could be determined by which button you click)
>
> On the other hand, I think both buttons should be the left button
> by default. Kids have trouble hitting the correct button. Button
> mistakes should not be something kids face from the moment go.

Yup. The hardware design was done before a UI team was organized at
OLPC. One of the first suggestions, though it was already too late,
was to limit the hardware to one button.

Since we didn't have the opportunity to change that, we opted to
provide a more traditional right-click functionality both because it
did provide a way to offer more contextual actions in a manner
consistent with other interfaces that already exist, and because we
thought it could actually be perplexing to have two buttons that
always appeared to do the same thing. If that's proving problematic
for children in practice, we could make a change there. I hadn't heard
much on that particular issue, so I don't know how common (or
persistent) it is.

>> Perhaps, as suggested by Wade, we could allude to the availability
>> of more information immediately on hover, and perhaps even try making
>> the right button the only means of invoking the secondary actions.
>> This does work today, but the lack of discoverability is a definite
>> problem.
>
> It's no less discoverable than the left button. Right-click menus

True.

> need to work two ways though:
>
> a. Press and hold down right button, move, release
> b. Click (press and release) right button, move, click either button

Agreed. This would be a good improvement to the behavior.

Eben