[Sugar-devel] RFC: Kill the delayed menus for good

[C. Scott Ananian]

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/ )