[Sugar-devel] How to Make Activity Designers Happy , Parts I and II

[Walter Bender]

Bryan, I appreciate you raising this discussion thread. Unequivocally,
We need to make it easier for everyone to contribute.

In regard to your essay, I think it is important in this discussion to
make a clearer distinction between (1) the constraints on FLOSS
development in the developing world (i.e., the need to get paid); (2)
the tools one uses for that work (e.g., Flash vs Javascript/HTML vs
Python); (3) the role that "educational content" providers might play
in development (i.e., who are they and are they primarily writing
software?); and (4) the pedagogy we are espousing (e.g., is
constructionism the only game in town?).

1. While others have also observed that there is a need for profit in
the developing world for software developers, this by no means
disqualifies FLOSS development. It just means that the profit comes
not from selling a license to a closed package, but getting paid, for
example, by providing a service. There is not necessarily new money to
be had and it will take time to redirect money in the system that is
directed towards FLOSS developers. But that doesn't suggest that FLOSS
should be abandoned. It is clear that at least for education (and
voting), FLOSS is *the* right way.

2. Low-cost/moderately powered hardware platforms do present some
constraints on what tools and solutions are suitable. Other
constraints include what skills are locally available and what rising
tides should be exploited. HTML/Javascript is probably the
lowest-hanging fruit, although Javascript performance on the OLPC-XO-1
hardware can be sluggish. But not as sluggish as Flash. It may be
worth someone making a concerted effort to help Rob fine-tune Gnash
(only Adobe can tune Flash) for the XO. The Sugar team will continue
to try to lower the barriers to developing native Sugar Activities and
putting Sugar wrappers around existing applications, be they written
in Javascript (e.g., SocialCalc) or Python or any other environment.
The foci are to provide ready access to the Journal and the
collaboration mechanisms ("convention over configuration"). (Wade's
note that arrived while I was composing this one is an example of what
we can do as a community to help individual development efforts.

3. While I am thrilled that some classroom teachers are beginning to
participate directly in the software development process (e.g.,
TurtleArt and Labyrinth), I am convinced that their major contribution
will be more at the level of integration. There is a wonderful
"curriculum" developed in Peru on community publishing that leverages
Record, Write, Browse, and Chat. It didn't involve any Javascript or
Flash, just thoughtful synthesis of the available tools. There are
holes in our repertoire that preclude certain types of curriculum
development: I am working on some presentation/portfolio tools, for
example. What other holes need filling? And I am curious as to your
experience working with teachers within the Etoys framework. Was that
too difficult for them to master? How could we make it more
accessible? And what are the roadblocks to developing web content for
Sugar and/or OLPC-XOs?

4. Constructionism is not the only way. Our strategy at Sugar Labs is
to make a platform that encourages more constructionism in the
learning process, but that it would be a matter of lowering the
barriers to entry, not closing doors to other approaches. To repeat a
well-wore analogy: you can read a book in either PDF or Wiki format,
but the chances that the reader will make annotations, add to a
discussion, and even add to the content are all much greater with a
Wiki because it has the proper affordances for such interventions.
Providing such affordances to the learning experience might be
motivated by a specific pedagogy, but it does not preclude other
approaches.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org