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

[Michael Stone]

Wade wrote:

> I take two points from this exchange:
> 
> #1 User interaction changes are always subjective.  

I agree.

> Patches, requests, suggestions, etc. should not be submitted with "duh" as
> a rationale.  

We reach opposite conclusions from the same data. Subjectivity of user
interaction implies to me that rationale should matter less than the actual
desirability among the people who are able to test the change of the change.

> They should be backed up with a clear rationale; better yet, hard data.

No, they should be submitted first, tentatively merged if not unreasonable,
then data should be collected on the intermediate result, then they should be
reverted if they prove to be faulty. 

Backfilling rationales on top of experiences is a recipe for Bad Decisions
unless you have access to the training and resources needed to design and run
actual sound psychology experiments. I don't think any of us have those
resources (though I'd love to be proven wrong.) Therefore, we shouldn't block
on them for getting things done.

(In other words, my process is a better process because it will find more good
changes than yours will given the current make up of the contributing community
and the current risks associated with merging a bad change.)

> #2 The Sugar UI is not sacred.  There needs to be a process to collect and
> evaluate data, and to design and implement improvements.

Sure.

> 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. 

You're needlessly frontloading the work onto acceptance instead of retention.
Why do you want that filter in place?

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!

But I'd _like to try it_ if you came to me and said that you liked it and
thought that it would be a good addition to Sugar because I want to help you
make Sugar better and because I want to encourage you to keep making more
patches even if some of them turn out to be not quite right.

We should decide whether we like it afterward and should trust people not to
propose things that they think are of questionable utility.

> 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.

What on earth for?

I mean, I understand doing this kind of testing for pharmaceuticals, where
people die if you screw up, but I didn't think that we were in that business.

> 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.

Good suggestion for discoverability, inadequate suggestion for fast access to
the actually rather important information hidden on the secondary palettes
(e.g. disk space availability, battery status, etc.)

Regards, and thanks for the constructive suggestions,

Michael