[IAEP] future of the Sugar user experience

Tomeu Vizoso tomeu at sugarlabs.org
Fri Jun 5 06:17:09 EDT 2009

On Wed, Jun 3, 2009 at 19:23, C. Scott Ananian<cscott at cscott.net> wrote:
> Seems reasonable: "Design review" in addition to "code review" for new
> patches.  Like code review, make a reasonable effort to have an
> experienced designer or someone who knows the design for the
> particular area, but if the patch stalls, any designer or developer's
> review will do.  If you care about coherent design, spent time doing
> design review!
> I'd just extend this to allow "initial design review" even absent a
> patch, so that people can get initial review before they sink too much
> time in an implementation.  If you're confident of the basic
> direction, you can skip this step (your work still gets reviewed
> before the patch is committed upstream), but if you're uncertain you
> might want to post screenshots or sketches or a text description of
> what you want to do and have someone say, "sure, that seems mostly
> reasonable" before you start implementation.  The initial review
> doesn't have to be nitpicky, because there are inevitably going to be
> things learned during the actual implementation, but it should serve
> to keep people from wasting too much time on ideas which are far from
> the desired design direction.

I agree with both of Jameson and Scott, those are very interesting
point of view(s) and see the value of that proposal. To complement
that, we discussed at Paris the convenience of each reasonable-sized
feature to have a champion that makes sure that the development of
this feature keeps moving forward with the participation of all the
needed people.

As an example, let's say that someone named Greg Smith realizes the
importance of having good tools in Sugar for discovering people to
communicate with. What we currently have doesn't scale for more than a
couple of dozen of people. That person doesn't need to be an engineer
or an expert in HCI, but will need to have excellent communication
skills, enthusiasm and the ability to transmit that enthusiasm and
make other people want to work together.

In this ideal scenario, the ball would start rolling by asking people
already using Sugar about their opinions on that matter. Would ask to
these and to other people for improvement proposals, will make a list
of people that have shown interest on this issue and would
periodically ping them so they feel in the loop, would see which
engineers would be interested in the implementation, etc

Other people that I think would make excellent feature champions are
Karlie Robinson, Greg DeKoenigsberg (currently doing that for the 4th
grade math project), Walter Bender (doing that for Turtle Art and
other stuff), Tony Forster, Caroline Meeks (SoaS), Mel Chua, etc.

Would make sense to formalize the role of feature champion and write
down some guidelines to make these people even more effective?



>  --scott
> [off-topic, by maybe relevant to people reading this thread:
> http://ignorethecode.net/blog/2009/05/31/creating-new-documents/ and
> http://daringfireball.net/2009/02/untitled_document_syndrome on
> "untitled document syndrome" address a Sugar design issue that's been
> much batted about.]
> --
>                         ( http://cscott.net/ )

More information about the IAEP mailing list