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

Tomeu Vizoso tomeu at sugarlabs.org
Thu Oct 15 10:17:02 EDT 2009


On Thu, Oct 15, 2009 at 14:47, Wade Brainerd <wadetb at gmail.com> wrote:
> I take two points from this exchange:
> #1 User interaction changes are always subjective.  Patches, requests,
> suggestions, etc. should not be submitted with "duh" as a rationale.  They
> should be backed up with a clear rationale; better yet, hard data.
> #2 The Sugar UI is not sacred.  There needs to be a process to collect and
> evaluate data, and to design and implement improvements.

Agreed.

> With changes to the user experience, writing the code is expected to be the
> simplest part of the process so the patch may be trivial, but acceptance may
> not.  I could submit a patch changing the Home background color to a lovely
> blue; it would be trivial to apply and motivating for me, but not
> necessarily a good idea!
>
> The correct way to submit this patch is to file an enhancement bug, post the
> patch to the bug, and create a wiki page under
> http://wiki.sugarlabs.org/go/Features using the provided template.
> An improvement to this patch that would increase its likelihood of
> acceptance would be to make it a toggle.  Even better would be to report
> delayed menu item clicks to a usability log server.  Work with a deployment
> to distribute both versions randomly, analyze the results, and include that
> in the feature request.

This may be a bit too heavy process for practical purposes, I think
there exists a veeeery wide space between what Michael asks and what
you have written above. I think we would go to such a extreme only
when we have already made a big change to the UI and some people
wanted to revert it (for example move back the activity icons to the
frame).

A good middle point may be to have people who are in contact with
Sugar-using children (both in the classroom and on their own) to
explain how the change would affect the usage they have observed. Even
better if the design team is available to explain the rationale and
suggest alternatives.

> I'd like to put my designer hat on for a minute and offer an alternative to
> Bernie/Michael's patch and the current behavior:  Any time the mouse hovers
> over a part of the screen with a delayed action, that part must immediately
> highlight itself.  With the frame, that would be a 1px rectangle around the
> screen.  With icons, this could be a border rectangle.

I think this one would have a big impact on usability and may not be
hard at all.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning


More information about the Sugar-devel mailing list