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

[Eduardo H. Silva]

2009/10/16 Eben Eliason <eben at laptop.org>:
> 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

The effect is pretty cool, will sugar developers make palete open up
like this? I like it a lot.
>
>> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>