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

[Sean DALY]

In marketing parlance, these would be called "focus groups" and are a
very effective and quick way to get feedback.

The group I did at my kids' school last June
(http://lists.sugarlabs.org/archive/marketing/2009-June/001625.html)
immediately showed for example the problems kids had with quitting
Activities.

Sean


On Wed, Oct 14, 2009 at 6:15 PM, Caroline Meeks <solutiongrove at gmail.com> wrote:
>
>
> On Wed, Oct 14, 2009 at 7:14 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>
>> On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti <bernie at codewiz.org>
>> wrote:
>> > El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió:
>> >> Hello,
>> >>
>> >> Michael just passed by the Acetarium and, since the dinner was late, we
>> >> found the time to test and review his latest prototype^W patch.
>> >>
>> >> I'm loving how the menus suddenly are now snappy and responsive.
>> >> Please,
>> >> test it yourself and report back. If we like this change, I think we
>> >> should go on and also kill the code that this patch makes redundant.
>> >> (please, let's not add another configurable knob!)
>> >
>> > BTW, Michael and I have a "small disagreement" on how a maintainer
>> > should react to the present patch. From a purely functional PoV, this
>> > patch is short, correct and low impact. Yeah, but... who's ever going to
>> > clean up after it if we do not demand the cleanup to be merged
>> > atomically with the patch that opens the need for it? Once the patch is
>> > in, the maintainer would no longer have a stick to brandish while saying
>> > "now eat your veggies!".
>> >
>> > (Michael replies: "This is a flawed position because it leads to absurd
>> > conclusions. More specifically, it actively discourages the current
>> > contributor from submitting more patches by denying the satisfaction of
>> > seeing their existing patch merged, delays the deferral of a correct and
>> > believable patch that introduces behavior you yourself describe as
>> > 'desirable' and, last but not least, misses an opportunity to involve
>> > inexperienced contributors by providing appropriate "on-ramp" bugs like
>> > the proposed refactoring.)
>>
>> 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?
>
> People could take both versions to a group of kids and video how it goes.
>>
>> Thanks,
>>
>> Tomeu
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> Caroline Meeks
> Solution Grove
> Caroline at SolutionGrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>