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

[Eduardo H. Silva]

For us noobs in patching, could someone make a screencast of Sugar
running with this patch?

Eduardo

2009/10/16 Eben Eliason <eben at laptop.org>:
> 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
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>