[Sugar-devel] Sugar Digest 2010-07-29

Walter Bender walter.bender at gmail.com
Thu Jul 29 16:33:14 EDT 2010


== Sugar ==

1. Squeakfest Part II: The final day of Squeakfest as was uplifting as
my first day at the conference. There were reports from the field
using Etoys and many "oh-the-things-you-can-do" presentations by
teachers who use Etoys in the classroom. There was a nice mix of
projects built by learners – an amazing physics model built by
high-school students in North Carolina was a highlight – as well as
projects intended to let a learner explore a powerful idea – a
beautiful-in-its-simplicity model for estimating the area of a circle;
these small projects – "Etoy-lets" – are being shared on line along
with an extensive collection of simple guides to using Etoys. Again I
was impressed by the extensive use of flaps and books that are created
as part of the project generation process and the use of versioning to
monitor a learner's progress. These facilities represent a major
usability improvement in Etoys in support of pedagogical goals. Etoys
is great stuff, well worth the initial investment in time and effort
to learn.

2. I contrast this with the sad state of the computer industry's
attempts to sell computers to schools: "[] says teachers need high-end
laptops but students will just be accessing content and communication
so need basic functionality." While there is nothing fundamentally
wrong with giving children access to content, does that really
constitute the basic functionality needed by the learner? The good
news is that Sugar (and Etoys) can run on these "basic" platforms. We
should stop selling teachers and learning short by dumbing down the
opportunities to use computation as a thing to think with.

3. Christoph Derndorfer, who is on another of his world-wide tours of
OLPC deployments – this time to Latin America – just reposted a link
to Michael Trucano's restating-the-obvious article on 1-to-1 laptop
deployment pitfalls on the World Bank's website. (Most of Trucano's
well-worn advise applies to any learning initiative; alas, he does not
provide much insight for those of us trying to actually solve real
problems on the ground.) I will give Christoph the benefit of doubt
that with the coincidence of his post that he is not deliberately
making a backhanded disparagement of the deployments in Uruguay and
Paraguay he has visited. While these deployments have not yet reached
the status perfection, the deployment teams at Ceibal and Paraguay
Educa have never strayed into the dangerous waters described by
Trucano:

   1. Dump hardware in schools, hope for magic to happen
   Far from it, there have been extensive support mechanisms in place
in .ur and .py from Day One

   2. Design for OECD learning environments, implement elsewhere
   While there is some sharing of content and best practice, it is the
local pedagogical team that calls the shots in both deployments.

   3. Think about educational content only after you have rolled out
your hardware
   Again, pedagogy has driven the pace of deployment. At the same
time, the entire deployment has been thought of within the context of
a learning platform, which includes laptops, connectivity, servers,
training, content development, documentation, support, community
outreach, etc.

   4. Assume you can just import content from somewhere else
   The key here is "just". Both .uy and .py think deeply about
content, but they are also opportunistic – taking advantage of great
content developed elsewhere, for example, by the Etoys community.

   5. Don't monitor, don't evaluate
   At Ceibal, they have an extensive operation for monitoring the
state of the network, servers, and laptops within their deployment.
There are numerous ongoing evaluations of the program, both internal
and external. Paraguay Educa was the subject of an external evaluation
by the IADB, which issued a very positive report.

   6. Make a big bet on an unproven technology (especially one based
on a  closed/proprietary standard) or single vendor, don't plan for
how to avoid 'lock-in
   Both programs have used a open bidding process and have some
percentage of hardware from multiple vendors. Both programs use Free
Software.

   7. Don't think about (or acknowledge) total cost of
ownership/operation issues or calculations
   .uy has been diligent in publishing their total-cost-of-ownership
numbers – these numbers, based upon the costs measured in the field
happen to be much less than the inflated numbers fabricated by
naysayers.

   8. Assume away equity issues
   While no one is claiming that equity issues are no longer a
concern, the fact that the per-household penetration of computing in
.uy is inversely proportional to household income says a lot. And in
every one of these households, the children have free Internet access.
Wow.

   9. Don't train your teachers (nor your school headmasters, for that matter)
   The biggest investment in the .py program has been in teacher
training. As the project scales, finding ways to make this process
more efficient will be key. But no one has every suggested that it was
not a vital part of the process.

===In the community===

4. I have some passes for Sugar community members to attend LinuxCon
2010  [http://events.linuxfoundation.org/events/linuxcon] in Boston on
August 10–12 (thanks to the Linux Foundation). Please let me know if
you are interested.

-walter

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


More information about the Sugar-devel mailing list