[Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

On Wed, Oct 14, 2009 at 1:41 PM, Edward Cherlin <echerlin at gmail.com> wrote:
> I'm extracting some of the for [[The Undiscoverable]].
>
> On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason <eben at laptop.org> wrote:
>> On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer <simon at schampijer.de> wrote:
>>> On 10/13/2009 04:36 AM, Bernie Innocenti wrote:
>>>> Hello,
>>>>
>>>> Michael just passed by the Acetarium and, since the dinner was late, we
>>>> found the time to test and review his latest prototype^W patch.
>>>>
>>>> I'm loving how the menus suddenly are now snappy and responsive. Please,
>>>> test it yourself and report back. If we like this change, I think we
>>>> should go on and also kill the code that this patch makes redundant.
>>>> (please, let's not add another configurable knob!)
>
> Works for me. I hate hover menus.
>
>>>>> From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001
>>>> From: Michael Stone<michael at laptop.org>
>>>> Date: Mon, 14 Sep 2009 22:33:12 -0400
>>>> Subject: Make various palette animations happen more quickly.
>>>
>>> Can you describe what the patch will change from the user point of view?
>>> Is this to get rid of the delayed build up of palettes when hovering
>>> over icons?
>>>
>>> You can use right click to get the menu immediately. The delay is on
>>> purpose.
>
> Yes, that's in [[The Undiscoverable]]
>
>> We should definitely get feedback. I wouldn't be entirely opposed to a
>> change, but I do want to make sure that we make such a change for the
>> right reasons, and that it's actually the right change to make.
>>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all. Kids
>> should be able to start activities, resume activities, join
>> activities, write, paint, stop, etc. without ever seeing a palette at
>> all. [1]
>
> That's fine, if
>
> 1) Everything is discoverable.

Yes, we could use some work there. The hover was meant to increase
discoverability, not decrease it, but perhaps it's not working
effectively.

> or
> 2) Teachers have guidance on what is not discoverable and how to
> introduce it, and on children's use cases and on how to handle those
> use cases efficiently.

Agreed.

> We have neither. I'm working on 2. Anything that improves 1 gets +1 from me.
>
>> This is the "low floor". For kids with more experience or
>> curiosity, we decided to provide contextual palettes which grouped
>> related actions and provided more complex interactions with the
>> system. This is "no ceiling". Furthermore, we wanted to help introduce
>> kids to the availability of additional options in a discoverable way,
>> which is why the hover effect was chosen to provide increasing levels
>> of detail and interaction for a given object.
>
> Was the discoverability of hover menus tested with children? I didn't
> discover it, and I'm a born lever puller and button clicker.

Almost nothing was tested with children until the first release of
Sugar on the XO-1, unfortunately; we would have liked to test more.

>> Finding that many kids were actually waiting for the palette to appear
>> always, instead of, for instance, simply clicking on an activity icon
>> to join it, encouraged us to INcrease the delay on the palettes to
>> help emphasize this as a secondary mechanism for interaction.
>
> A case of treating the symptom rather than the ailment.

Perhaps. What would you define as the ailment, yourself? The primary
intent was to encourage use of a direct interaction model, in which
palettes we're supposed to play a big role. When it turned out that
young kids, who didn't read, and who didn't have motor skills for
selecting form the palettes, we aimed to reduce accidental invocation
of them without entirely eliminating discovery by increasing the
delay.

Perhaps (assuming, of course, the rules you laid out above already) we
should remove the hover activation altogether! (Not, of course,
without testing!)

>> A agree
>> that hovering in one place to click in another isn't great; but that's
>> also not the intended primary means of interaction, and should only
>> really be done when one of the secondary actions is desired.
>>
>> Removing the delay pushes us, I fear, even farther away from an
>> interface in which nice friendly large clickable icons can be directly
>> manipulated and encourages every action to be done through a
>> contextual menu with a bunch of text in it. Is that really what we
>> want kids to face?
>
> I don't see the problem. The nice friendly large clickable icons will
> remain where they are. You either have to create and *demonstrate* a
> path to *equal* discoverability, or you have to think about helping
> teachers help children with what they don't discover.

The problem is that the appearance of the palette seems to encourage
kids to take the longer (and harder) route to their desired
interaction. The reveal of the alternate option could distract from
the more direct path to their intended goal. Again, observation with
kids indicated that, even without revealing palettes immediately, they
tended to wait for them instead of clicking directly on objects. The
paths, in a sense, were not in fact equal in discoverability.

>> Just for fun, I might suggest an alternate possibility which actually
>> decreases the discoverability of the secondary palette.
>
> Not my kind of fun.

Well, let's not call it fun then. =) I'm merely suggesting that, when
presented with a problem, we should brainstorm a number of potential
solutions in the problem space so that we can be reasonably confident
that the chosen solution is adequate, or at least the best among the
possibilities presented. (How we determine adequacy is a separate
issue).

>> We could
>> reveal the primary palette (label) on a delay as we do now, with some
>> indication of "more options" that can be clicked to expand the menu to
>> reveal the secondary items. This would provide the (essential) primary
>> palette as a label and introduce kids to the existence of more
>> controls without encouraging them to use this as a primary method of
>> interaction. Advanced users, of course, could still right-click to
>> invoke the full menu in one shot.
>
> I don't like to hear children divided into advanced and non-advanced
> that way. If we get a series of lesson plans together on all of the
> known non-discoverable elements of Sugar, we should be able to get
> this difference down to two or three weeks max. Then we can talk about
> advanced children being the ones who have developed skill in what an
> Activity is for, not in knobs and blinkenlights.

Sounds good! My apologies for incorrect phrasing: "advanced" wasn't
the right term. Perhaps "kids with the desire to explore Sugar more
deeply" would have been better.

>> Eben
>>
>> [1] Incidentally, one of my major complaints with the "resume by
>> default" behavior is that it makes starting new activities hard to do,
>> and virtually impossible to do without using a secondary action, which
>> is the wrong approach in my mind.
>
> I want to know what is in the children's minds.

Me too! I'm stating my own opinion merely because I don't have kids of
my own to experience Sugar with. In either case, observation of kids
has indicated, as I've seen mentioned on the list, that the current
behaviors of Home view don't always work as hoped. We could blame this
on the kids, or on their instructors, but I'd ultimately blame it on
the software.

No one has to listen to my opinion, but I do think we need to be aware
of the problems that kids are experiencing, evaluate them based on
observation, and offer suggestions for improvements based on those
observations. I brought up this point specifically because it relates
to your first point above, about everything being discoverable. The
ability to start a new activity form scratch, it seems, may not be
discoverable enough.

>> I think starting from home, with the
>> option to resume, while encouraging one-click resume from the Journal
>> is still the correct approach.  I think offering the option to enter
>> "resume by default" mode is great, but I'm not sure it should be,
>> itself, the default for Home view.
>
> I have some experience with options. The entire APL community agrees
> that there should not be an option for where to start counting, but
> the business users all want to start at 1, and the scientific users at
> 0. Again, what I think doesn't matter, and what you think doesn't
> matter. What the children think matters. Perhaps there is a clear
> preference for one way or the other, but perhaps there is a clear
> preference to have an option. We don't know yet.
>
>> In practice, it seems it has worked too "well". It used to be that
>> kids never resumed activities. Now, it seems, they never start new
>> ones. The solution seems to be in encouraging use of the Journal and
>> the Home view for these different default actions, and in clarifying
>> the UI such that kids understand and desire to do so.
>
> I believe that the solution lies in Education.

I think education will go a long way. That said, I also don't want to
fall back on education as a solution for a UI that lacks clarity or
discoverability if we could find ways to improve it.

In the early days of word processing software, secretaries were taught
the difference between enter and return. One would submit text input,
and the other would have some unwanted action which destroyed all of
their input and required re-entering lost information. No one realized
it was a usability problem because the secretaries never spoke up
about how frequently it happened, or how frustrating it was when it
did. When asked later why this was, they responded that they had been
told exactly how to operate the software, and felt it was therefore
their fault for not using the software as intended.

I never want to blame those using software for software that could be
better designed.

Eben

>
> Albert Einstein is widely believed to have said, "Everything should be
> as simple as possible, but _no simpler_."
>
>> Eben
>>
>>
>>
>>> Regards,
>>>    Simon
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin
> Silent Thunder is my name, and Children are my nation.
> The Cosmos is my dwelling place, the Truth my destination.
> http://earthtreasury.org/
>