[Sugar-devel] Testing changes (was Re: RFC: Kill the delayed menus for good)
Tomeu Vizoso
tomeu at sugarlabs.org
Wed Nov 18 13:14:24 EST 2009
2009/11/5 Edward Cherlin <echerlin at gmail.com>:
> We need at least one more hat (in addition to those described below),
> which I am willing to put on. Somebody needs to coordinate field
> testing and feedback, so that we have data to make decisions from, or
> we can get appropriate data when they are not yet available.
>
> It is not enough to have a coordinator, of course. We must have
> populations of users (various ages, various countries, in some cases
> various disabilities) approved for testing (at least by themselves, by
> their teachers, and by any administrators with responsibility for
> them). We must have people willing and able to install, de-install,
> and monitor changes. We must have a place to put raw data and results.
> We may occasionally need a tool built. We seem to have no shortage of
> ideas, or even patches, but I am willing to hear more on that point.
> There is more, but that would be sufficient for getting started.
>
> If the developers are willing to get their part organized, I will take
> this question to iaep and grassroots, and to management, and see
> whether we can get covered at the user end or anything else that
> people think of. Oh, yes. Experiment designers and the like from Ed
> schools.
Having someone coordinating this area would be of great help, but I'm
worried about forgetting that perfect is the enemy of good. As
starters, I think we just need to get some opinions from deployers,
developers, testers and UI designers and make sure that any technical
decision (such as pushing code) is made after taking into account that
feedback.
Once we have this working, we can start thinking about how to make the
feedback we get from those groups more relevant and of more quality.
Regards,
Tomeu
> I'm delighted to see these discussions making progress. I have long
> detested the unfolding hover menus. Keep it up, but please don't take
> any of it personally.
>
> On Sat, Oct 17, 2009 at 10:44, C. Scott Ananian <cscott at laptop.org> wrote:
>> On Sat, Oct 17, 2009 at 2:15 PM, Michael Stone <michael at laptop.org> wrote:
>>>> ps. I've found the discussion of ideas here much more interesting than
>>>> the finger-pointing.
>>>
>>> Understandable; thanks for providing this feedback. Are there specific
>>> ideas that have come up in this thread other than the one that Wade
>>> supplied that you have found particularly thought-provoking?
>>
>> In general, revisiting the "why" and attempts to discover different
>> solutions which achieve the original goals. Like Martin Dengler, I
>> find myself convinced all over again when I revisit the original
>> motivation. Real world feedback indicates, however, that the current
>> behavior frustrates some users, despite "best laid plans". It's
>> obviously time to return to the "why" and come up with different ways
>> to accomplish those goals. (Discussion which is simply "I want X"
>> without a consideration of how this relates to the design goals is
>> much less interesting -- I won't say useless, but it begs for someone
>> to contextualize it and provide the missing rationale before it fits
>> well into the conversation I would like to be having.)
>>
>>>> Attempts to shift responsibility (it's my patch,
>>>> YOU have to prove that it's wrong -vs- it's my design, YOU have to
>>>> prove that it's wrong) are productive/necessary to some degree, but a
>>>> family matter you guys should take out back somewhere to hash out.
>>>
>>> Do you have a recommendation on where "out back" would be? Some other
>>> mailing list? Private conversation?
>>
>> If it's a truely personal matter, private email (or some physical
>> location where you can sit down together for a beer). If it's about
>> hashing out a philosophy of participation, then mixing it together
>> with discussion of UI changes is not helping either conversation
>> progress. Sometimes you can't do two things at once, but you can do
>> them separately.
>>
>>> I understand you to be saying that we should be listening to people with
>>> the experience necessary to have informed opinions. Is this a fair
>>> summary of your position?
>>
>> Not necessarily. My position is that there's an interesting UI
>> discussion largely buried in this thread. There's also a
>> community/contribution/patch-approval conversation which I don't have
>> any strong opinion on. Finally, there's a meta-topic revealing some
>> splits within the community which I do have some thoughts on.
>>
>> I am currently working on a(nother) strongly design-oriented
>> "bottom-up" UI, and it has reminded me that such development *can*
>> work. Having a strongly coherent "user story" and regular feedback
>> from those users *is* really important. That said, unfiltered user
>> opinions are often short-sighted. You really do need a "designer"
>> role: some group of people who can keep the overall goals in mind and
>> maintain overall direction. Some problems need evangelism, some
>> problems need design fixes, some problems are unexpected/unresolved,
>> some problems are "won't fix" (proposed feature out of scope, not
>> relevant to target users, impossible with given resources, workaround
>> pending further user feedback/maturity of proper fix), and some
>> problems are just bugs.
>>
>> I don't think that treating all proposed code changes uniformly as
>> "bugs" is the right solution. I also don't think that developers
>> cannot put on designer hats, or vice versa. But the necessary
>> organizational discipline seems to be missing in this thread.
>> Separate your concerns and have separate, focused, conversations: have
>> everyone put on designer hats and discuss the problem (some users are
>> frustrated by context menus/some users are not as efficient as they
>> could be/some users perceive the interface as sluggish because of
>> intentionally-added delays), goal, and possible solutions. In another
>> thread, put on your manager hats and figure out how to nuture
>> contributions, organize designer roles, maintain coherence (both in
>> code and design/vision), and maintainability (again, you should be
>> spending as much time on design "janitor work" as you seem to be
>> willing to spend on code janitorial duties). In yet another context,
>> put on coder hats and look at the purely technical issues (in this
>> case, how to treat patch sets which essentially orphan other blocks of
>> code, patches which demonstrate an idea pending designer feedback, and
>> possibly how to enable more efficient A/B testing with actual users).
>> Finally, you can hash out whatever personal issues, grudges, or
>> misgivings in some other context -- I've always considered actual
>> face-to-face conferences the best way to enable reconciliation and
>> team building, but you could also consider personal mail which says,
>> "I feel this response of yours was overly personal..." or "I apologize
>> if my response seemed sharp, I thought about this more after I hit
>> send and realized that not everyone knew XYZ which I was assuming was
>> obvious..." or whatever.
>>
>> I'm not helping the situation at all by opening yet another topic on
>> this thread: the meta topic of how I feel this conversation is going.
>> Clearly I'm not part of the solution, but you (dear readers) may be.
>> --scott
>>
>> --
>> ( http://cscott.net/ )
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin
> Silent Thunder is my name, and Children are my nation.
> The Cosmos is my dwelling place, the Truth my destination.
> http://www.earthtreasury.org/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
More information about the Sugar-devel
mailing list