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

[Eben Eliason]

On Thu, Oct 15, 2009 at 10:09 PM, Avi <fiendishx at gmail.com> wrote:
> Tomeu wrote:
>
>> I'm more concerned about developers proposing big user experience
>> changes because they feel it's better. Before I look at the patch I
>> would like to know if there's agreement from people close to our users
>> that this behavior change is desired. How can we get that?
>
> How about users (me) proposing big user experience changes by asking a
> developer (Michael) "why the fuck does this UI take so goddamned long to
> react?" Also, define "our users". Is it people using Sugar? Is it people
> using XOs? Is it people other than you? I'll gladly put myself into any of
> these categories if it makes you happy.

I think we'd all agree that the primary audience for Sugar is children
of varied age groups and levels of education, and that audience should
be considered first in terms of the user experience. I'm not
suggesting, of course, that the rest of us aren't also users with
valid input and experiences, or that this proposed patch was submitted
without the best interests of that audience, or at least a reasonable
portion of that audience, in mind.

I also don't believe that Tomeu was stating a challenge of any kind,
or insinuating that no one other than Michael was likely to have a
positive response to the proposed change. The suggestion was that we
collect feedback from many people, yourself included, and also from
children in our primary audience and the teachers and instructors who
work with them daily. In that regard, thank you for your feedback; it
would be more constructive, of course, if you could provide it without
the profanity and apparent disgust.

> Eben wrote:
>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all.
>
> 1) For whom? What about people who know how to recognize English letters and
> words better than they remember what an obscure picture means? Because
> you've failed on that front.

For children! And actually, I agree with you. In many cases text is
minimized more than I would like it to be. Clearly it's beneficial for
those learning to read to see associations of words and icons, and
words are naturally useful to those who already can.

> 2) Good luck. Sincerely. I hope that if that's still your goal that it's
> actually possible. I'm personally not convinced, but only because I haven't
> yet seen a demonstration that shows progress on that front.

Honestly, I think we've come relatively close. Would you strongly
disagree? It's possible to create new activities, resume past
activities, join collaborative activities, connect to networks,
participate in activities, copy, paste, and stop activities with the
use of primary actions only. I'm not suggesting that the full power of
the UI is available without the need for seeing any text, but I am
suggesting that there are a great many things you can do with Sugar
without needing to use the secondary actions and tools available in
palettes.

If there are basic functions or actions that are frequently needed
that aren't exposed as primary actions, it would be useful to identify
those areas in order to make improvements. Do you have any
suggestions?

>> 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.
>
> Jesus, why? Think about what you just said for a moment. Why might someone
> wait for the palette to appear before clicking? Probably because they want
> to see what's on the palette! The situation of the palette is that all it

I was not precise enough in my statement. Upon observation, many
children were waiting for the palette exclusively to select the first
option within it, which is the primary action that a click on the
object itself would also invoke. They were NOT attempting to access
the secondary functionality, but instead, due to the appearance of the
palette, assumed that this was the only means of interaction.

As Michael correctly points out, the contextual menus are indeed an
inferior solution to direct interactions, since they require finer
motor skills (and are difficult with poor trackpads, such as those on
XOs) and movement away from the object they wish to interact to a
secondary target within the menu. The icons are larger targets, easy
to click without delay, and would have saved children both time and
aggravation had they learned to act upon them directly.

> takes is one accident to discover that hovering shows useful information.
> And with the knowledge that the palette shows useful information, and that
> hovering shows the palette, it is reasonable that one might just engage in
> the described behavior. Either make the useful information available without
> the contextual menu or make the current expected behavior more responsive.

I think it may be useful to show the primary palette (which provides
this useful information and text to elucidate the meaning and identity
of various icons throughout the UI) immediately, though my (again,
merely personal) preference would be to keep the secondary menu, which
is needed less often, on some delay (or at least determine a manner of
exposing it that does not obscure the primary target — the object
itself — and encourage kids to take the long route via the context
menu).

>> 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?
>
> So what you're saying is that you want to force children to use the system
> in a way that you just said is contrary to what THEY actually want to do.

As mentioned above, I wanted to encourage (not force) children to use
the system more efficiently to accomplish what they wanted to do, with
less delay, and with less movement of their finger upon a trackpad.

>> 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.
>
> Many kids have motor skills, and the ones that don't initially are
> remarkably good (being kids) at developing motor skills that they don't yet
> have. Many kids also read. In fact, let's cut into some real deep philosophy
> stuff here...

Even adults with great motor skills had trouble with the trackpads on
XOs. And, regardless of motor skills, I still wouldn't want to
encourage a less direct means of interaction when a direct one is
available. The problem seems to be balancing the exposure of the
secondary actions (which clearly will require additional movement of
the cursor to at least some degree, which should be minimized) with
the exposure of the more basic and efficient methods of direct
interaction.

> The idea that the XO laptop is mainly for kids who can't read is completely
> bogus. Now, maybe you're thinking of other children when you say this, but I

Fair enough. They are certainly not *the* audience, but I do consider
them to be among the audience.

> prefer to first consider the main existing userbase. Laptops which have

Agreed.

> Sugar installed on them are primarily located in schools and are used for
> education. It is kind of ridiculous to say "Well, you don't actually need to
> know how to read to use the laptops, so we should make the interface not
> require reading." when the truth is that, for most activities that have any
> educational merit, you DO need to read and you need to read things
> significantly more complicated than activity names. Most of the people who
> use Sugar for most of the time WILL know how to read.

Agreed. As mentioned before, cutting text from the first layer of the
UI was a controversial decision at the time, and something I didn't
fully agree with myself. Also, I think it would be useful to have the
associated text (primary palette) appear quickly. 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. Another possibility would be to educate children
about right click somehow. 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.

Also, for what it's worth, the initial design goal was to expand the
secondary palette over the duration of the currently imposed delay.
That is, it was meant to feel "snappy" by providing quick indication
that "more stuff is here", without immediately expanding completely to
show information that may not be needed or desired and without
immediately obscuring a substantial portion of the screen. A sample of
this idea can be seen here:
http://www.sugarlabs.org/index.php?template=gallery&page=media_01

> Daniel Drake wrote:
>
>> It makes all menus that currently have a delay appear instantly?
>
> Not even close. On the XO sitting next to me it still feels like over a
> second. There appears to actually be ANOTHER delay somewhere that was not
> modified at all, because the UI takes the same amount of time to respond
> with the change on both an XO and on a significantly more powerful laptop.
> What is noticable, however, is that it just doesn't feel like things are
> craaaaaaaaaaw-awwwwww-aawwwwwww----aaaaaaawwwwwww-ling (ling) after the
> change, because before the user was met with a multi-stage, phased delay,
> whereas now the delay is brief and only up front.
>
> If you haven't yet, you really need to at least try it. All of this "I don't
> like it, but I haven't actually tried it" stuff is just unhelpful.

That's true. I'll give it a shot. Thanks for all the feedback!

Eben