On 29 Oct 2010, at 10:02, Martin Dengler <mar...@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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel