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

[Eben Eliason]

I wanted to include Christian on this thread since he may also wish to
try it out and have some valuable feedback.

It seems like this thread is somewhat split between design discussions
and process issues. Should it be exclusive to the sugar-devel list? If
we want feedback from people other than developers it seems we should
have a broader scope.

Eben


On Thu, Oct 15, 2009 at 11:19 PM, Eben Eliason <eben at laptop.org> wrote:
> 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
>