QotD    "The more I dig, the deeper I go, the more I realize how little I know" – Mayuresh A Kathe
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Piaget, MacPal and SK8
Last updated at 10:30 am UTC on 28 March 2017
Research report by ATG Education Research about earlier research projects before Squeak

The Authoring Tools Thread

Jim Spohrer




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)!


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, a metatool or tool building technology, can best be described as HyperCard on steroids. SK8 [6, 10, 13, 14] was designed to be appealing simultaneously to HyperCard programmers who wanted a more complete and powerful programming environment to grow into, as well as for novice programmers looking for a first object oriented programming environment. SK8 users program in SK8Script, a natural language like programming environment that unlike HyperTalk has a full prototype-instance object model as well as standard programming data structures conveniently accessible. The graphics model allows any object to contain any other object, so containment becomes a powerful way to build up new objects out of many component objects. In addition, SK8 includes an extensive library of predefined objects that were carefully constructed to make building task specific authoring tools straightforward. For example, connector objects and a port wiring mode make it easy to build authoring tools based on a wiring metaphor; a two dimensional picker object makes spreadsheet and grid-based authoring tools straightforward to construct. Finally, the SK8 Project Builder allows sophisticated projects to be built entirely by direct manipulation. SK8 has hundreds of subtle, but important, productivity features built into it. Over one hundred research project tools were built or first prototypes in SK8 [23].

SK8 is a large programming environment, requiring a minimum of 25MB to operate comfortably. SK8's size is not a problem for professional multimedia developers, since they typically use high end machines with a lot of RAM. However, deployment of large projects is a problem. SK8 projects can be delivered in under 16MB on a Macintosh Common Lisp runtime. In addition, several investigations have explored delivering SK8 projects on Kaleida's ScriptX as well as Java runtimes targeting machines with about 8MB of RAM.

SK8 and its complete set of source code (implemented in Macintosh Common Lisp) can be freely downloaded at http://sk8.research.apple.com/ [19]. Ruben Kleiman was the chief architect and implementor of SK8, though many others including Brian Roddy, Hernan Epelman-Wang, Sidney Markowitz, Chris Flick, Ken Dickey, Philip McBride, John Ulrich, Michael Evins, and others too numerous to mention made contributions large and small.
From: https://github.com/KenDickey/Cuis-Smalltalk-BabySteps/blob/master/IdeaMine/SK8.jpg or http://opendylan.org/_static/images/sk8.jpg



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.