[IAEP] [SLOBS] Sugar Labs 2010 Goals Review

[Bernie Innocenti]

El Wed, 14-07-2010 a las 15:04 -0400, C. Scott Ananian escribió:
> On Tue, Jul 13, 2010 at 8:05 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> > El Mon, 12-07-2010 a las 22:13 -0400, C. Scott Ananian escribió:
> 
> Bernie, thanks for responding.  I hope you understand that my message
> wasn't meant as a flame on SugarLabs or y'all's work, just as
> "constructive criticism".  My hope is that I drew attention to some of
> the goal points where you could either further document your progress
> towards the goal, or perhaps goals on which to focus additional effort
> in the second half of the year.

Sure, we should promote an attitude of violen^W criticism within our
community. This is why I started this thread in the first place. Without
criticism, there would be no improvement.


> Opinions may vary.  Obviously, as Christoph mentioned, OLPC is
> currently committed to this form factor.  I suggest that other
> hardware manufacturers are investing in the form factor as well.  Thus
> this may be a case study for "incorporating outside ideas" even if you
> don't really believe these will be successful or widespread
> educational devices.

I'm generally in favor of merging optional features that are valuable
for some vendor even when their value for the entire Sugar community
isn't obvious yet.

The small increase in maintenance cost is often counter-balanced by a
wider user/developer base. This is an important ingredient in the recipe
that made the Linux kernel the most active software project on this
planet.


> I think an honest assessment would indicate that OLPC has done some
> initial work on supporting touchscreen devices, but that SugarLabs has
> not (so far).  Maybe some subset of the touchscreen problem can be a
> modest SugarLabs goal for the second half of the year -- just
> reworking the toolbar and/or frame to be touch-friendly, say.

This is the part where SL being a volunteer-driven organization makes
things work very differently from a business.

Apart from the exceptional cases of directed volunteers (GSoC students,
paid interns), we have no way to persuade developers to work on
touchscreen interfaces.

Donating hardware to developers is a common way to get them more
interested in supporting it. OLPC has used this wisely in the past.


> (See http://daringfireball.net/linked/2010/02/22/flash-touch for some
> discussion of the interaction of mouse-based and touch-based UI
> design, and http://ignorethecode.net/blog/2010/05/25/gestures/ for a
> "grad level course" on gesture design.)

Interesting. I was hoping to get most of this ground work done by others
who have used Gtk on hand-held devices before us. I heard some of the
Nokia & Intel work has been merged back into Gtk. (too bad they've now
switched to Qt, which means we won't benefit from their future
investment).


> > Given a choice, many teachers started using Gnome. Some of them messed
> > up their systems, just like children.
> 
> So consider this a mild suggestion that the "dogfooding" goal has some
> way yet to go.  Major developers can't use Sugar for day-to-day work,
> and even teachers who try this have difficulty.  Since Gnome is (in
> your admission) not a good alternative either, it seems like there's
> something left to be done here, if only for the teachers' use case.
> (Perhaps the task is just to refine the Gnome image distributed with
> Sugar to be more appropriate for naive users.)

Dog-fooding Sugar is a hard problem. Even if it were as mature as Gnome
is, it's really designed for a different target user and use-cases in
mind.

The best we could do is work closely with teachers and children.
Deployments can help us on this. Thanks to Paraguay, I could relay
crucial usability info to developers, such as the necessity to display
file sizes so users could effectively cleanup their journals.

It's unbelievable that we couldn't carry on simple observations like
these in over 4 years of Sugar development.


> Again, this isn't meant as a criticism against Sugar Labs, just as an
> effort towards a more accurate assessment of your goals.  Instead of
> just saying, "we've fixed the problem, we're open to critique now", it
> might be better to explore ways in which Sugar Labs (as a community)
> is not as open to critique as (say) a business.  Perhaps these can be
> addressed via existing or additional business partners, like Activity
> Central.  I'm not the expert here =)

Me neither, but this is my belief: service & support businesses such as
Activity Central could play the same role for Sugar that Red Hat and
Canonical are playing for Linux.

Communities are great at brainstorming and fast exploration the
phase-space of a domain, businesses are great at creating finished
products.

The two things combined in the right way can produce a formidable
cocktail. The multi-million dollar Linux vendors could testify this. All
the others that went bankrupt should warn us that it's not always easy.

Sugar Labs should create the conditions for an entire industry to
flourish around Sugar. This point has been in my SL board platform for
two years now, but we're starting to see some action only recently.


>  I'm just suggesting that further
> exploration might make your goal assessment more valuable.  (This
> point already seems to have spawned profitable discussion on this
> thread on ways to engage teachers better.)

I'm not sure what's wrong with how we present Sugar Labs that drives
away teachers. The education team of Paraguay Educa has been
instinctively diffident of us right from the start. Among the negative
comments I heard, we "change software for fun because we don't care of
the difficulties in the classroom". I'm convinced it's solely a problem
of appearance and public image, because I heard such opinions even from
educators who have not yet taken the time to learn how to use Sugar.

My hope is that the Realness Alliance could create a direct
communication channel between us and teachers.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/