Background of the Exploratories Project

Exploratories are the latest development in an ongoing effort of Brown University's Computer Graphics Research Group to leverage the computer's potential for use in education. This 30-plus year effort has included several hypertext projects led by Andries van Dam and others in the Graphics Group and the IRIS project. This work included HES (Hypertext Editing System) developed with Ted Nelson in the 1960s, FRESS (File Retrieval and Editing System), developed in the 1970s and the first hypertext system used to teach a liberal arts course, and IRIS Intermedia in the 1980s, a UNIX-based networked hypertext system with advanced features used for teaching undergraduate and graduate courses

These efforts led to the notion of an electronic book with interactive illustrations, a new form of textbook that took advantage of the power of hypertext and the power of 2D and 3D interactive computer graphics. We currently call our efforts "Exploratories" to better convey our goal of interactive microworlds in which objects have behaviors and users can interact with concepts and phenomena.

There are three main prongs of the Exploratories research project:

• content generation
• tools creation
• and the writing of a Design Strategy Handbook

Issues Under Exploration

Our work over the last half a dozen years has focused in particular on several areas (described in alphabetical order below):

• Applet and Component Levels of Granularity
• Interface Design for Effective Pedagogy
• Logistical Issues of Creating Exploratories in a University Lab
• Proto-Patterns for Exploratory Usage in Existing Curricula
• Re-usable Software Components
• Reusable Hypertext Structure Components (HTSCs)

At first, in 1997 and 1998, our exploratories resembled multimedia software: each had several modes and taught a whole sequence of ideas. For example, an applet for exploring different filters for scaling an image, created in 1997, offers many features for varying the filter shape (including directly drawing a custom profile), uniform and nonuniform scaling, preset examples to explain important filter facts, and several images to choose from. Its interface is structured for different types of interaction and display. A text box brings up both explanations of the concepts and context-sensitive help when the user rolls over different parts of the UI.

The programmer was an exceptional student and he still spent over three months (working part-time) creating the applet and working by himself and with others to add text. Other applets took entire summers of full-time student work! The large scale of the projects also meant that the code was difficult to read and reuse, and that a substantial amount of text would have to be written to accompany a online version. While such an approach can be ideal in some circumstances (of both development and use), for most, including for development in a university setting for use by varied audiences, it obviously was not.

In their 1999 SIGSCE paper, "Granularity in the Design of Interactive Illustrations", Exploratory members Gould and Simpson detailed this problem and demonstrated the advantages of a fine-grained approach to interactive illustration/ exploratory creation. The fine-grained approach breaks the subject matter up into a series of small programs, each of which teaches a single main concept, and embeds them in text. They define granularity as "the conceptual scope covered." Smaller-grained or fine-grained applets take on "small, atomic concepts." For instance, an applet from a set created in 1998 and 1999 teaches just the concept of sampling, with two options, point and unweighted area sampling. The reader is led through a whole series of such applets to learn about the Nyquist limit, weighted area sampling, filter shapes. There are seven separate applets for presenting convolution.

We are still experimenting with issues of granularity and the creation of guidelines for finding the right levels for different applet usages. A fine-grained approach can be more flexible, for example, but can become boring if the individual applets are too simple.

We have experimented with a number of different approaches to interface design:

• direct interaction: we try to let the user directly manipulate the representation of data or ideas rather than use more remote sliders or controls. For example, in the filtering applets discussed above, users can directly draw their own filter shapes.
• aesthetic appeal: while all interfaces should look good, sometimes the appeal of the interface is particularly important. We have found this to be especially true for applets that present seemingly simple ideas. In our additive and subtractive mixing applets, for example, the eye-catching graphics help draw students in and encourage them to use the applets. (Consider, as an opposing example, the image processing applets, which have reductive interfaces designed to be unobtrusive as students face ideas they know to be difficult.)
• Consistency across related applets: for applets that we plan to use in a series context, we have designed and reused the same or similar graphics elements and layouts to give the feeling of related activities and to ease any learning curve associate with their use.
• incorporating the graphics group's 3D interaction research: For our 3D applets, we have incorporated camera controls designed as part of another research project. Although they are not standard, once learned they are powerful and are easy to use and remember.
• experimentation: to date, the most prevalent approach has been experimentation. Now that we have a number of examples, we may follow more guidelines within our group to enforce some standards for interaction as well as look and feel.

The project has tried different approaches to the challenges of creating educational software in a university lab. The forces at work are smart and creative but sometimes unreliable student labor that turns over frequently, varied levels of programming ability and experience, and programming needs of related courses (namely our introductory graphics course), limited faculty and staff time, and the need to focus on different aspects of the project at different times (e.g., creating applets, creating tools to create applets, and writing parts of the handbook).

We are moving away from having beginning programmers make entire final applets and more toward the use of software components (discussed below),m nay of which are designed by a full time staff member.

We have tried several methods for integrating our applets into Brown's introductory graphics programming course. Some were more successful than others. Our efforts are summarized in the ITiSCE2000 paper "x" by Anne Morgan Spalter and Rosemary Michelle Simpson. Our conclusions were that some type of required use was essential. We found integrating applets into homeworks assignments particularly effective.

The need to repeat certain interface elements, mathematical calculations, and interaction techniques throughout a set of applets has inspired us to think about modularizing our efforts. Each applet can be thought of as a flexible component of a larger effort, and many of the features of the applets could, we felt, in turn, be recombined to create new versions of existing applets or entirely new ones. In particular, a staff member or upperclassman could program particularly complex portions, such as the math behind some of the filtering methods, and undergraduates (or educators accessing material remotely) could design their own applets. This approach requires software components, pieces of code that can be plugged into different applications and used without modification. A component architecture is achieved by instituting an expected set of named entry points into the code and enforcing a set of naming conventions and introspection capabilities.

Other researchers working on the problem of educational software development have also moved to component architectures and some envision their prime usefulness as suppliers of components rather than authors of complete applications or systems. In their paper "Developing Educational Software Components" Roschelle et al. discuss the challenges of creating components with useful cognitive characteristic for educators, such as those furthering the type of constructivist pedagogy that has inspired Exploratories.

In addition to software components, we have created reusable hypertext templates that encapsulate common hypertext usage. These help developers remove text from within applets (making them more flexible for use by others) and make it easier for teachers to integrate applets in a meaningful pedagogical context. See our paper for Hypertext2000, "x", by Anne Morgan Spalter and Rosemary Michelle Simpson.

In essence, our concept of reusable hypertext structure components (HTSC) abstracts out structure and pedagogy from the code and places it in the text. The result is that the software components are more easily reused, the programming is easier because different aspects of the experience are associated in a hypertext structure rather than within a piece of code, the text is supportive of, but separate from the software at hand, and different pedagogical aspects of teaching are more easily adapted to the online world. Just as viewing a set of software components can help teachers think of new interactive scenarios, so, we believe, perusing a set of HTSCs and seeing examples will not only relieve a design burden, but also inspire thinking about the way that interactive works are used in class, at home, or over the Web.

We are continuing to work in all these areas and are beginning to introduce formal user testing to better assess our results.