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 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. > 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
pgpPIJ1BIjc1B.pgp
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel