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

[Bryan Berry]

On Fri, 2009-01-02 at 12:46 -0500, Walter Bender wrote:
> Bryan, I appreciate you raising this discussion thread. Unequivocally,
> We need to make it easier for everyone to contribute.

Thanks for your support!

> 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.

I am suggesting Flash because FLOSS should not exclusively be the domain
of linux programmers. 

Certainly, some programmers need to get paid but the point of my article
is that there are many developers in the developing world more than
happy to volunteer their time. Unfortunately, that time is constrained
and we need to empower them to use tools they are familiar w/ rather
than forcing them to become linux programmers.

I agree that FLOSS is absolutely the right way. However that doesn't
mean that XYZ developer uses Photoshop and Adobe Illustrator to create a
flash activity, their resulting work can't be open-source too.

> 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.

I find that Flash runs plenty fast using the proprietary flash player.
It is only slightly slower than a pygtk app. Unfortunately, flash is
quite sluggish using Gnash by a factor of 2 or 3 if it runs at all.

I hope that my article's appearance in olpcnews.com will spur more
developers to assist Rob on gnash.

There is nothing in Adobe's Flash player licensing that restricts me
from installing it Nepal's default XO image. Their licensing does
restrict me from posting a software image that include the flash plugin
on the Internet.

> 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?

It takes a long time to train teachers to use Etoys who have never used
a computer before. Etoys _requires_ mastery of the touchpad and that was
more than we could teach in 2 weeks of training. Dragging and dropping
is a non-trivial skill. 

I think we can train teachers familiar w/ computers how to use Etoys.
Unfortunately, 95% of the teachers we deal and will deal w/ are not very
familiar w/ computers.

This is one of the major differences b/w Nepal's deployments and those
of more developed countries like Uruguay.

> 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

I love constructionism but too often we focus exclusively high-level
math and science and not "foundational" skills or art, literature,
grammar, health, etc. By foundational skills I mean basic literacy and
numeracy. Kids can't create an Etoys game until they can count properly.
They can't read the dialogues until they understand phonics properly.

Some vocabulary has to be memorized and kids have to be able to add #'s
quickly in their head. When was the last time you reached for a
calculator to compute 5 + 5? If you did, you would work much more
slowly.

I find that Sugar contributors from developed countries are focused more
on high-level thinking because that is a deficiency in their local
school systems. Their kids can do basic math and _usually_ know basic
grammar. Poorer countries are focused on basic numeracy and literacy.
You can't program until you can add and read.

Countries like Peru and Brazil have schools where kids are ready to
focus on high level problems. They also probably have schools struggling
to impart basic literacy and numeracy.

-- 
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org