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

[Walter Bender]

On Fri, Jan 2, 2009 at 2:17 PM, Bryan Berry <bryan at olenepal.org> wrote:
> 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.
>

There are many FLOSS programs that run on Windows, so I guess I am not
understanding your point. You mention some of them yourself: Gimp, for
example.


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

I don't think anyone is arguing that we should preclude people from
using whatever tools they have at hand.

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

And there is nothing preventing you from using Adobe Flash if that is
what you want to do, at least for the time being.

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

I presume the same thing applies to Javascript and Flash that uses
drag and drop?

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

I don't understand the construing of constructionism with "exclusively
high-level math and science" and I don't quite what you mean by
"foundational skills". I don't think anyone would argue that we don't
want numeracy and literacy to be "low shelf" tools in every child's
repertoire, but what does this have to do with the other topics in
this thread?

-walter

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



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