[Dextrose] [Sugar-devel] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)

[Gary Martin]

On 29 Oct 2010, at 10:02, Martin Dengler <martin at martindengler.com> wrote:

> On Thu, Oct 28, 2010 at 10:19:37PM -0400, Bernie Innocenti wrote:
>> [cc += fgrose,m_stone]
>> 
>> On Wed, 2010-10-27 at 06:19 +0100, Martin Dengler wrote: 
>>> On Wed, Oct 27, 2010 at 06:05:58AM +0530, Manusheel Gupta wrote:
>>>> Are we ready to commit this patch?
>>> 
>>> Well, it's only a year after there were some quite significant
>>> discussions about it:
>>> http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html
>>> 
>>> There were many concerns.  Have they all been addressed?  Perhaps just
>>> nobody can be bothered to object again?
>> 
>> Well, a big change since last year is that now we've actually tested
>> this UI change for several months with a large number of real users.
>> The last adjustments proposed by Frederick Grose weren't actually
>> tested in a classroom, but it was well justified and lays somewhere
>> between the old and the new timings.

Bernie, apologies for paraphrasing but I'm sure the feedback I read (by you) from this was that none of the kids noticed the change in timing and even when specifically shown and asked to comment it was too subtle of a change for them to give an opinion.

It's one thing to say no one has complained**, but to say that getting no complaints means it's a worthwhile change to land is something else.

** pretty sure I did see at least one complaint filed as a SL trac ticket, some issue with a Dextrose build where buddy palettes in the neighbourhood view appear too quick and obscure other icons while trying to quickly browse/hover for buddy names.

> I agree this is the best we can do with the resources we have, and
> that it's enough to justify applying the patch (not that it's my
> decision).
> 
>> In order to test this change, we had to actually apply the patch to a
>> release build before we knew whether or not it was an improvement.
>> There's no other way! Very few developers have this luxury, so the
>> requirement to test each UI change beforehand should be dropped unless
>> we want to halt development.
> 
> There is no such requirement - that's a straw man.  Based on the
> amount of debate last year, I think it's justified to ask how the
> concerns raised have been addressed.  "We tried it for a year in a
> deployment" seems a very good answer.  It's not the answer that I
> guess would justify inclusion, but I don't think we should thus move
> too close to the other extremem, which is accepting very little
> justification for contentious, significant UI changes.
> 
> IMO a decent justification and a willingness to update the affected
> wiki pages - including the HIG - to a similar or better standard as
> what existed before should almost be enough for me.
> 
> What I'm worried about is the HIG that exists - incomplete as it is -
> is being chipped away and we're left with UI that's justified by
> nothing but a patchwork of ad-hoc decisions made by very different
> people with very different users in mind.

+1 I think the HIG is a major part of the Sugar vision and road map, I often feel we're in death by 1000 cuts, heading for the grey beveled goo of UI that is unfortunately prevalent else where. I have no objections to improving/updating the HIG to move us forward on the design, but let's be up front about such changes.

To be frank, as we move towards a touch UI Sugar, most of this left click vs. right click, mouse hover pop-up timing will go out the window any way. ;)

Regards,
--Gary

> 
>> For the future, I'd like to propose that we review UI changes using the
>> same criteria of any other code change. That is, by applying the
>> maintainer's best judgment upfront and testing the best we can
>> afterwards.
> 
> I don't disagree with this wording, but hope that the "maintainer's
> best judgement" will apply different standards for a UI change that
> would break documentation and training everywhere than for a PEP008
> patch.
> 
>> Establishing a tighter feedback loop with users is a problem that can be
>> solved separately with the help of deployments.
> 
> Making UI changes without feedback and that break documentation /
> training should be done very carefully, if at all.
> 
> Martin
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel