[Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)
martin at martindengler.com
Fri Oct 29 05:02:57 EDT 2010
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.
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
> 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.
> 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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: not available
More information about the Sugar-devel