[IAEP] future of the Sugar user experience

[Jameson Quinn]

In the end, this is one of the dynamic tensions that we're never going to
resolve once and for all. Between power and simplicity of the interface,
there are some win/win choices, but there are also tradeoffs. This also
relates to the tradeoff between speed and quality of development, because
the faster you develop, the less time you spend mapping out the possible
tradeoffs and finding the best option. I'm going to respond by first playing
devil's advocate against Tomeu's position, then suggesting some compromises.

Tomeu says that it would be disasterous if engineers start designing the
user experience. Scott responds that "developers need not be disqualified
from design work, so long as they make an effort to turn off their
implementation brains and/or get their work polished/reviewed by someone who
knows nothing of the implementation." Let me (for a minute) go further than
Scott: developer experimentation may not just be acceptable, it may be the
best solution in some cases. On I think every pressing design issue on
Tomeu's list (and others that I'd add), there is nobody who isn't at least
trying to give some consideration to design issues. In fact, in at least the
case of keyboard shortcut work, the entire focus is on a cleaner user
experience, and very little in the way of new functionality is proposed.
Moreover, as Sugar moves from its heierarchical roots under OLPC to a more
open model, the critical resource is not developer time, but contributor
enthusiasm. In that context it may make sense to have people implement their
crazy ideas, and then figure out if that's what the community wants, rather
than trace out an elaborate consensus roadmap beforehand.

Of course, at either extreme lies madness. Sugar needs coherent versions,
not a pile of poorly-integrated "add feature X" patches (we already have
enough of those, most crucially Rainbow). And yet locking down all new
development until it has a chance to get a Perfect Consensus (or Dictator
Approves) stamp at the next Design Team meeting three months from now is
just as much of a death spiral.

So we're left in the land of compromises. Tomeu is probably right that just
skating along and letting engineers decide will lead to a consistent bias -
say, for featuritis over simplicity. The solution is absolutely not to take
the power from the engineers and give it to someone else; in open source,
power to help decide the project direction is the main wind in our sails.
Yet if you try to share that power, in practice you often get such a rainbow
of bikeshed-color suggestions that the engineer feels that there's no
practical way to take the feedback into account, and so goes back to just
doing it their way.

Here's my proposal. Insofar as we've substituted for Marco's full-time
developer work, we've done it piecemeal. There's not a committee poring over
each line of code; different developers do different parts, with community
quality control mechanisms. I'd say we have to do the same for Eben's
full-time design work. Every developer should be paired up with somebody
wearing their design hat, whose job is explicitly not to worry about
implementation but about design coherence. This person would help facilitate
community discussion, but in the end they'd make a decision if discussion
got stuck for whatever reason. They'd try to formulate a long-term goal. The
developer would have both significant voice in the community debate, and
(more importantly for their motivation) significant autonomy deciding on
their own step-by-step approach to the long-term goal.

Basically, the first person to volunteer on any given issue would be the
design partner for that issue. They

I'm absolutely not trying to find a way to eliminate Eben and the other
respected design voices from the process. Their voices would still carry
serious weight. I'm just trying to find a way to get design input and
attention to the issues that need it, but avoid deadlock and keep some
autonomy.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090603/07ca321e/attachment.htm