In my last post, I wrote about why we need an easy way to create compelling courses for the XO in order to scale constructionism to the national level here in Nepal. In this article, I will talk about what I think those courses should look like and how they should function.
Now it is time for dynamic digital coursebooks, individual modules that contain lesson plans, supplementary readings, illustrations, and learning activities. These coursebooks must be usable offline and able to synchronize important data with the School Server. Some say the XO was inspired Alan Kay's visionary Dynabook. Sadly, OLPC did not choose the excellent name "Dynabook" for their groundbreaking laptop. I am happy to shamelessly re-appropriate the term dynabook to refer to the type of course I have described. Alan Kay still thinks the Dynabook hasn't been invented yet. The key software and educational curriculum are the missing pieces. Let's try to fill in the gaps to make these new dynabooks reach their full potential. We can create perfectly functional dynabooks with existing technology. We don't need anything cutting-edge.
We need to consider the needs of both the creators of dynabooks and the users. Creators need an easy-to-use, collaborative environment to link, embed, and even create different types of content into a coherent learning narrative. This environment already exists in Moodle. There is no need to reinvent the wheel or latch onto to some sexy new technology like Ruby on Rails or Django.
Our users are both kids and teachers, particularly in the developing world. They need to be able to access dynabooks at school when they have access to the School Server and when they are completely offline at home. The teachers need to an easy way monitor individual student progress and achievement. For example, most teachers in Nepal don't have the time to grade homework for their 50+ pupils. Monitoring individual student progress is an essential aspect of constructionism. Students understand new concepts by building on what they already know. This process is commonly known as scaffolding. Teachers need a easy way to view how individual students are progressing and where they need the most help. Moodle's Gradebook is an excellent tool for this purpose. In general, I think the gradebook should not be used to spur on competition but to identify students that need the most help and which subject areas warrant more attention.
Characteristics of the Dynabook
- Link and embed different kinds of content into a coherent learning narrative for a particular subject.
- Available offline but can synchronize information such as student work and student progress when online
- Intuitive transition between different objects in the dynabook, such as a pdf, Etoys or python activities, and different content bundles.
- Easy for education experts and local teachers to create and modify dynabooks.
An Example Dynabook
Let's design a Dynabook for Class 6 Mathematics. All of the materials for Class 6 would exceed the storage capacity of the XO if packed into a single activity bundle. Let's break this dynabook into individual modules for modules covering 4 weeks of class. Each module is an .xo bundle which includes all readings and exercises needed to complete it. The final bundle should be a course review that summarizes the entire dynabook.
The main dynabook page
When the child clicks download the dynabook module gets installed on her local machine. The student can then launch the module. A particular lesson might look like this:
Lesson on Negative Numbers, this is getting exciting
From Oswego City School District
From within lesson the child could launch an Etoys activity to work with the ideas from the lesson. The activity launches in a separate activity, not within the browser. This is a crucial point as we don't want to create a monolithic application.
Working with Negative Numbers by driving a car in Etoys, Very Exciting!
The students' progress and personal projects would synchronize with the School Server when they are next online.
Technical Architecture of the Dynabook
We need to keep the common presentation layer of the dynabook as simple as possible and hide technical complexity in the individual activities.
The Dynabook I envisioned here is essentially an offline version of Moodle. While the core engine exists in the main Moodle distribution much work remains to make it fully satisfy the 4 requirements of the Dynabook. David Van Assche has already succeeded in running Moodle locally on the XO using a minimalist stack of Apache, Mysql, and PHP. This is a working interim solution but a less resource-intensive approach is needed. There is an Adobe AIR-based off-line Moodle client called Jolongo but it is currently unusable on the XO and Adobe's licensing makes it difficult to ship AIR on the XO. OLPC School Server Architect Martin Langhoff believes that Google Gears is the right toolset to make a fully functional off-line Moodle. OLPC School Server Architect Martin Langhoff has even volunteered to mentor anyone interested in seriously working on offline Moodle.
Some of the earlier comments to this post have pointed out that my vision of the Dynabook is a Rube Goldbergesque contraption and I concede that in many ways it is. The actual dynabook application is merely glue that links and embeds different content. There unfortunately and will likely never be one true educational platform, as much as I would personally like Squeak to be it.
If you're a talented programmer and have some free time on your hands, I can't think of a single software development project where you could have more global impact than the Dynabook.
I admire the enthusiasm here, but I have to point out how ahistorical this post is. Kay's Dynabook ideas in concrete, published form date back to at least 1972, and the software to create them has arguably existed in some form for nearly as long. The "sexy new technologies" referred to are directly derivative of precisely that line of development, now 30+ years old. An "offline Moodle" with eToys plugged in seems to me a bit a Rube Goldberg contraption: an awfully circuitous route to the original, relatively simple goal of allowing learners to explore systems interactively. Have a good look at what Squeak/eToys can do.
What's needed to create a real Dynabook isn't any particular software or hardware development (since they do already exist) but a fundamental shift in the culture of education (and, for that matter, computing). OLPC at least *began* with such lofty goals; Alan Kay's work certainly continues in this line.
Some closer attention to history is needed here. I can recommend nothing better than Kay's own eloquent and by now voluminous reflections on the project, available on the Squeakland.org website.
Hi, John, (how are you?)
Bryan has been givin a closer look on Etoys. I understand his desire for better web interface integration. Etoys could run as a browser plugin, but there are bunch of side conditions that prevents it from going smoothly.
If the timing is right in the world (which never is), I'd think a version of Etoys like system on top of Dan's Lively Kernel would be pretty useful in this setting (integrated with Moodle for example).
(Bryan, John is a historian who did a research on the Dynabook concept and other work by Alan and his group.)
@Jon, first I am reappropriating Alan's term to refer to something different than he originally envisioned. You should know that I am quite familiar w/ Etoys and the NGO I work for develops learning activities for the XO using Etoys.
Squeak is a monolithic environment that just isn't all that well suited to embedding and/or linking different types of content together. The tools kids and teachers need to explore interactively are pdfs, flash animations, squeak projects, and python activities. I would like Squeak to be THE ONE TRUE EDUCATIONAL PROGRAM, but for better or worse there will be no one true educational program.
Squeak is an intellectually and technically consistent application. The world of learning materials is not intellectually nor technically consistent. Moodle can handle this much better than Squeak.
@Yoshiki
Etoys would not launch w/in the browser but w/in its own separate activity. Python-based activities would also launch as separate activities.
> Squeak is an intellectually and technically consistent
> application. The world of learning materials is not
> intellectually nor technically consistent. Moodle can
> handle this much better than Squeak.
OK, I get the first two sentences here, but the last one leaves me wondering... why?
What is it about Moodle that makes it better in this context? Is it simply that Moodle is much closer to the contemporary web/net/software zeitgeist? Or is there something more that you're alluding to?
The first approach would be to try to integrate the missing elements into etoys - like browsing, pdf-viewing, CMS with standardised exchangeable learning packages because etoys is dynamic and interactive. Moodle content is mostly electronic paper like text, picuteres, multiple choice tests. Starting and stopping prepared animations and videos in Moodle is not really dynamic.
The second approach would be to port etoys to python and embed it into a larger environment of more loosely connected applications (including a CMS) and SW-libraries. The inherent consistency of the original etoys based on squeak smalltalk would hamper its embedding. If etoys would be written in python this would be considerably easier at the cost of somewhat less strict consistency. Patapata (http://patapata.sourceforge.net/) was an experimental project to port etoys to python. It was stopped in 2006 but the source code is still available for extension.
@roleic,
but ideas you suggest could conceivably work but it will take years of effort and significant funding to make either happen. Sophie http://sophieproject.org is an attempt to make Squeak handle the kind of dynamic content we are talking about but it has struggled to generate developer enthusiasm or get funding despite having a great concept and technical foundation.
Moodle is here and it works. Further, we shouldn't isolate learning environments from the general direction of the software industry, which increasingly focusses on web-related technologies.
Moodle works now and does the basics of what a dynabook should do. Let's use it and move forward. We can debate forever how an idealized solution would function and operate.
> The first approach would be to try to integrate the missing elements into etoys - like browsing, pdf-viewing, CMS ...
Since Squeak can be just a window manager for the X window system, the integration may not take that long. Just open FireFox within Etoys/Squeak, and possibly we can communicate with various messaging mechanisms.
@Yoshiki
>Since Squeak can be just a window manager for the X window system, the integration >may not take that long. Just open FireFox within Etoys/Squeak, and possibly we can >communicate with various messaging mechanisms.
You could do everything in Squeak w/ enough smart people and time. I have immense respect for Squeak hackers such as yourself, Bertf, and the folks at VPRI. Unfortunately, there are too few of you and you are too busy to accomplish the above in the short run.
Moodle is here and it works. I would be happy to use a different technology when it is ready.
@John
>What is it about Moodle that makes it better in this context? Is it simply that >Moodle is much closer to the contemporary web/net/software zeitgeist?
Yes.
There just aren't enough people working on Squeak right now to make it support the linking and embedding of different types of content. Moodle, html, and the browser are continually updated and developed. Further, software developers take pains to make sure their new technologies work together w/ the browser as much as possible.
I was just responding to releic to point out there is a less labor extensive way. Of course that doesn't mean it simply happens automatically.
While I understand your frustration, I also understand John's point as well; if you take the liberty of using a term defined in the past, you would rather want to respect the original idea. If you just want to express your opinion (which I do see a point), dispowering the bigger idea doesn't go friction free.
There were a series of commercial laptops in the late 1990s called "Dynabook". Probably from Toshiba or NEC, I can't remember. So that name is probably somebody's trademark currently. That doesn't mean it can't be used for other projects, but it wouldn't be a good idea for OLPC to call their laptops that.
Given that I design Smalltalk-only machines for kids, you might think I would be against the Moodle idea. But I support it - real work can't wait for stuff that is still in development. That said, I hope Bryan is aware of how much web development is being done with Squeak (based both on Seaside and Aida).
Let's do this, Bryan.
Where should we set up the workshop? What tools do we need? Wiki, mailing lists, forums, repository...? I and others have plenty of ideas for textbook replacements using Etoys, Measure, and other Sugar Activities in pretty much every subject. What we need is a place and a process, not only to write, program, and otherwise create learning materials, but to get them tested in classrooms, refined, and put into new curricula.