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

[Michael Stone]

Tomeu wrote:
>On Wed, Oct 14, 2009 at 16:57, Michael Stone <michael at laptop.org> wrote:
>> 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. 

<humor>I don't take it personally; I take it on behalf of oppressed
contributors everywhere...!</humor> 

(In other words, judging the patch by its author rather than by its text
and its effects does seem to me to be a rather risky business. Your
choice, though.)

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

Far better to accept the changes, get the user feedback on the changed
versions, then revert the changes if they turn out to be inappropriate.
Everyone will be happier. (That's my opinion, anyway.)

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

I'm glad that we agree.

> If, say, Gary comes later and proposes a patch to revert yours, should
> I accept it in fear that I may discourage him otherwise?

Yes, but in awareness rather than in fear, (though only unless you have
an overriding reason not to.)

Being "concerned about developers proposing big user experience changes"
does not seem to me to meet that criterion. To my mind, "overriding
reasons not to" include "the patch is..."

   * incorrect
   * illegal
   * an obviously bad idea
   * a subtly bad idea
   * more trouble than it's worth

At best, it has been argued so far that merging the patch I showed to
Bernie is a subtly bad idea because it leaves the obvious possible of
refactoring of the context menu code to remove the use of the animation
code unimplemented.

In the middle, Eben expressed uncertainty on the basis of a specific
vision and private memories. This shouldn't impede merging the patch; it
should just encourage more testing and thought based on his experiences,
vision, and thought experiment so that we get more data.

At worst, it has been argued that merging the patch is an obviously bad
idea because it was developed by a developer (me; who else was supposed
to develop it?) engaged in critical dialogue with and reflection on the
Sugar user experience (I do feel that it's better) via methods that I
find congenial as opposed to by methods that I find prohibitively
expensive. 

Did I miss any other positions in the debate?

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

I'd call it more "timid" than "off". Or at least "inappropriately
deferential to the wishes of the design team and the deployments who
talk to you at the expense of receiving more contribution by making
contribution more dynamic and fulfilling and therefore at the expense of
exploring more possible Sugar experiences".

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

I'm saying three things; namely, that:

   1. I trust that you and the other people on this list are empowered
      and able to make reasonable UI decisions when presented with clear
      alternatives,

   2. Patches are an appropriate way of exchanging proposals for software
      modification and a good medium for discussion of those proposals, and

   3. Applying a 6-line patch to a jhbuild root, to a Sugar chroot
      produced with my scripts, or to a live Sugar install is a hell
      of a lot easier (and more valuable to know how to do) than my
      cooking up a SoaS image just for interested people to try out said
      patch.
   
(For the record, I'm more sympathetic to the SoaS argument with rainbow
stuff but the rainbowish work that I'm doing at the moment lies in the
area of network isolation and community-building [c.f. my new playground
at sandboxing.org] rather than in Sugar integration.)

>> Now, as for what "better" look like: ...
>
>I'm having trouble getting your proposal, maybe some mockups would help.

A fair request, but one that is probably doomed to wait until someone
with graphics and/or animation skills comes along to help me transform
my words into pictures and movies. 

(Interested folks should please contact me; I'd be very happy to work
with you on obtaining such visual materials.)

Regards,

Michael

P.S. - For even more humor, count how many words have gone into this
thread so far in comparison to the number of words in the patch!