Piaget, MacPal and SK8

QotD	"To be or not to be" – Shakespeare

Last updated at 10:08 am UTC on 23 October 2020

Research report by ATG Education Research about earlier research projects before Squeak
http://homepages.cwi.nl/~steven/sigchi/bulletin/1998.2/spohrer.html

The Authoring Tools Thread

Jim Spohrer

Excerpt:

1998

Piaget

Based on the experiences of building MrFixit, Role'm, and other intelligent multimedia simulation-based learning environments, I formulated an authoring tools strategy and then managed the creation of many dozens of authoring tools. The authoring tools strategy came to be known as the `metatool titlewave (Figure 4)' strategy (or initially, the Piaget project), and was based on the idea that many task-specific authoring tools would be needed to empower non-programming instructional designers and subject matter experts to easily create next generation instructional titles. To create the many task-specific authoring tools, a powerful metatool or tool building technology would be required combining some of the best multimedia features of tools like HyperCard and SuperCard with the best artificial intelligence and modeling technology like KEE. In sum, the authoring tools strategy had three steps: first, create a powerful intelligent multimedia metatool; second, programmers would use the metatool to create task-specific authoring tools; and third, non-programmers would use the task-specific authoring tools to build lots of titles (a `titlewave' as Chris DiGiano referred to it).

To build confidence in the metatool titlewave strategy, we undertook an experiment: build task-specific authoring tools and then recreate MrFixit with the new tools. Furthermore, we expected that building the task specific authoring tools would not take longer than building the original MrFixit, and using the task specific tools to rebuild MrFixit would be doable by a non-programmer in an order of magnitude less time than building the original MrFixit. We knew that building the original 30 component MrFixit device simulation had taken about one week of SuperCard programming. Plus, the separate components had taken several days each. The intelligent agent that was able to handle three dozen fault cases had required about two weeks of SuperCard programming. In addition, two weeks of debugging an integration were required. In total, we expected a skilled SuperCard programmer would need between one and two months to create a MrFixit-like coached simulation learning environment.

Three task specific authoring tools were needed to rebuild MrFixIt: PiagetDraw (a tool for building the device components, both finite state machines as well as continuous state machines based on pins, grooves, sockets [5,11, 18] and other graphical constraints, see Figure 4), PiagetDiagram (a tool for assembling components into a complete simulation, see Figure 5), and PiagetTree (a tool for building the decision tree logic for troubleshooting the device's failure modes, see Figure 6). Each of the task specific authoring tools had required about two weeks to design and build, by myself, Dave Vronay, and Alan Peterson. Using these three tools a non-programmer was able to recreate a MrFixIt-like learning environment (with many more components and failure modes modeled) in just under two days (as compared to 1-2 months for a programmer using SuperCard before)!

MacPal

Also at that time, Alan Kay's Vivarium Group had just completed a design, implementation, and test cycle for a kid usable programming environment, called Playground. In preparation for building the next iteration of a kids programming environment and Dynabook-like hardware for it, Alan had created the MacPal working group. The working group attracted over a dozen of the best minds from across Apple who were working in a number of relevant areas, including the area of end-user programming techniques [8]. A guiding principle that Alan Kay instilled in everyone that came to these meetings was the need to embody a set of powerful ideas in the new programming environment that we were all struggling to create. While we wanted to make programming the simple things simple, we wanted the environment to allow for graceful scaling up so that more complex things could and would be created as the programmers became more accomplished in using the environment. A technical report on a variety of end-user programming techniques was produced by the working group. Also, out of the MacPal working group, two key kids programming environment projects emerged: Constructo (general purpose programming) and KidSim (task specific programming).

SK8

Description see The SK8 authoring tool

Squeak

The strategy of creating lots of task-specific authoring tools using a single metatool is not without its problems. As the range of task-specific authoring tools expanded and new `must have' media technologies sprang up, SK8 was continuing to grow in size and complexity. Alan Kay suggested that a more minimalist approach should also be explored, along the lines of the original Smalltalk effort. In response to this suggestion, Dan Ingalls, John Maloney, Ted Kaehler, and Scott Wallace undertook the task of creating Squeak (named for the small sound of a small animal). Squeak is a modern version of Smalltalk 80, using updated technologies and driven by a minimalist philosophy.

Testament to the success of the Squeak simplification and modernization effort was the fact that after it was released to the Web (with sources) it was successfully ported to four other platforms in just five weeks by self selected Smalltalk experts. Squeak (with sources) is available at: http://www.research.apple.com/research/proj/Learning_Concepts/squeak/intro.html [15]. Today, Alan Kay and the Squeak development team are part of Disney's Imagineering group, and a thriving Squeak community has emerged in support of a simple, open authoring environment. Small is truly beautiful.