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

[Tomeu Vizoso]

On Wed, Oct 14, 2009 at 16:57, Michael Stone <michael at laptop.org> wrote:
> A word of initial warning: please turn on your sense of the absurd
> before reading. This response is written with a deep sense of amusement,
> rather than angst.
>
> Tomeu wrote:
>
>> I'm more concerned about developers proposing big user experience
>> changes because they feel it's better.
>
> Yay, more roadblocks and stereotyping! :)

You shouldn't take this personal, most of Sugar contributors including
me have done this in the past. I'm just saying that now might not be
such a good idea any more to accept changes in the user experience
without user feedback.

> Are you actually saying that you'd prefer either
>
>  a) no patches or,
>  b) patches that I think make the system worse?

Yup, this is certainly absurd. If, say, Gary comes later and proposes
a patch to revert yours, should I accept it in fear that I may
discourage him otherwise?

C'mon, I'm just asking that when substantial changes to the user
experience are proposed, that we have some discussion that involves
the design team and the deployments. Is this really so off?

>> 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?
>
> Well, trying it might be one good way to start. :)
>
> After that, shipping it in an explicit beta is another more heavyweight
> but nevertheless time-tested approach.

You know how easy is making a spin of SoaS with such changes for
people to try out, or are you saying that you want me to do this work
for you?

> Failing that option, you likely need to find some product specialists.
>
> ...
>
> For what it's worth, I do view this patch as a UI bandaid to the
> underlying problem that hover-to-click-somewhere-else is the wrong UI
> affordance for the home screen to use in supporting discovery of and
> access to variant or associated behaviors. The patch is, however, still
> a big improvement that is available today.
>
> Now, as for what "better" look like: treat each view has having a
> primary layout algorithm for Sugar-level UI actions. This algorithm
> should effectively arrange logically related groups of capabilities as
> determined by metadata attached to the capabilities and as determined by
> the current filtering criteria for the view.
>
> In actual activities, this layout algorithm is the "new toolbar
> approach". The filtering criteria are "hover-or-click on an expandable
> toolbar item."
>
> In the circle view, I'd like to see the layout algorithm expanded to lay
> out arcs of smaller option icons each with the same prelighting and
> saturation behavior as partial halos around the exterior perimeter of
> the activity icons. Naturally, there are some obvious interesting
> extensions involving zoom effects and more subtle saturation behaviors.
>
> Lastly, it seems to me that a similar approach might also be effective
> in the mesh view and around the central XO-figure.

I'm having trouble getting your proposal, maybe some mockups would help.

Regards,

Tomeu

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