[IAEP] [Sugar-devel] How to Make Activity Designers Happy , Parts I and II
bryan at olenepal.org
Fri Jan 2 14:53:28 EST 2009
On Fri, 2009-01-02 at 14:41 -0500, Walter Bender wrote:
> >> 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
> >> 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
> >> 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
> >> 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.
> drag and drop?
It is does if you require a lot of dragging-and-dropping together w/
right-clicking. For example, our teachers got the hang of Draw during
training but they struggled w/ Etoys. They could do
point-click-activities like GCompris, E-Paath, Maze, etc. w/out a
> >> 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?
It has to do w/ this thread because it is easy to create simple
animations using Flash but hard to add collaboration and "View Source."
I am trying to make the point that a lot of activities don't need those
features in order to be very effective.
> > --
> > Bryan W. Berry
> > Technology Director
> > OLE Nepal, http://www.olenepal.org
Bryan W. Berry
OLE Nepal, http://www.olenepal.org
More information about the IAEP