Archive/Current Events/2010-08-10

Sugar Digest

1. Twitter-style: Hello from Squeakfest in Wilmington, North Carolina. We just had a demonstration of some Etoys projects done by 7th graders; pretty amazing. One student, when asked what she does to keep from getting frustrated said: "Damn computer." But she is an accomplished problem solver.

This is the first conference I have been to in years where the majority of presenters are not using PowerPoint. Naturally, by-in-large, they are using Etoys for their talks.

It is great to see how teachers have incorporated the tool into their curriculum and the realities of school: even the kids built "quizzes" into their projects. But most of the learning is guided discovery.

In many cases, kids use Etoys from a USB drive, so they could take their work home and turn in their homework.

Bert Freudenberg showed an eloquent way to make animations in Etoys. I am inspired to finally add animation to my sprite library (the one I use for all of my activities: Turtle Art, Abacus, Visual Match, etc.) "Simply" a matter of adding paths and a timer. Yeah right.

Avigail Snir, a teacher from Illinois, showed a great example of exploring the modeling of gravity based on a simple basketball simulation. A remarkable thing was her use of a "book" to show the progress of her thinking along the path to discovery – the closest to a "lab notebook" as I have seen with Etoys (or any other learning program, for that matter). Lots more at [1].

Mahnaz Moallem talked about the challenges of making a transition from a well-defined, one best answer, discourage making mistakes classroom into an ill-defined, many answers, making mistakes and developing problem-solving skills classroom. She and her colleagues make extensive use of scaffolding and guiding to help kids stay motivated. Etoys "Flaps" are used for documenting what the kids have done. The consensus among North Carolina teachers at the conference is that there is a terrible constraint in the schools in terms of tightly-scheduled problem-based requirements imposed on the teachers.

Chandra Roughton posed a tough question: "Is this a model or is it [just] a visualization?" Etoys teachers think and do and demand a lot of each other and their students. What a breath of fresh air.

---

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

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

4. 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 of 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 ever suggested that it was not a vital part of the process.

Trucano leaves #10 as an open exercise for the reader. I'll add:

10.Don't involve the community

In both .uy and .py community involvement is part of the project by design.

In the community

5. There is a new and improved website describing teacher resources (in Spanish) here: http://wiki.laptop.org/go/Recursos_en_espanol

6. There will be a Turtle Art Day at the Arlington Career Center in Arlington Virginia on 7 August.

7. I have some passes for Sugar community members to attend LinuxCon 2010 in Boston on August 10–12 thanks to the Linux Foundation. Please let me know if you are interested.

Sugar Labs

Gary Martin has generated SOMs from the past few weeks of discussion on the IAEP mailing list.

• 

  2010 July 10th-16th (66 emails)

• 

  2010 July 17th-23rd (36 emails)

Visit our planet for more updates about Sugar and Sugar deployments.