[Sugar-devel] Testing changes (was Re: RFC: Kill the delayed menus for good)

[Edward Cherlin]

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.

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/