Chapter 6.
Education Information Systems

"...getting into position to think."
J. C. R. Licklider

This chapter recognizes that an information network paradigm will greatly benefit education. First is a description of the benefits already accruing with current technology. Second, the structure of an Education Information Network is presented. Third, the Virtual Lesson Plan (VLP) is used as an example of Ubiquitous Software (U_S). The idea of VLPs is to enable professional computer developers to implement generic container classes and components that can be used by educators to author course ware. The generic containers and components are reusable, and so is the authored course ware. In the recursive model of U_S, all containers are themselves components usable in other containers. Although chapter 3 surveys component software, containers, and the development environments available, any mention of these in the discussion of VLPs cannot be understood as an endorsement of their adequacy. This caution is needed because of the immaturity of these environments and my inexperience with them.

An Experiment

Documents are the artifacts of communication. An artifact is an object produced or shaped by human craft. Artifacts require technology to be created and maintained. Handwriting, books, movies, video tapes are all based on technology. All can be considered documents. Their technology requires investments of skill and labor to produce.

Once the technology of Internet was easily available and affordable to large numbers of people, no one should be surprised that it was co-opted for public use. Using communications technology to produce documents is a natural human activity. Documents directly support communications and access to information. Viewed as containers, documents represent an ideal environment for building component based software. As explained in Chapter 3, the key technology concepts in compound documents include linking and embedding, nested containment, direct manipulation (drag-and-drop; visual editing) and a control infrastructure.

The pervasive Internet and the Web makes publishing available to everyone. This serves as an example of an information network paradigm. Computer-user interface (CUI) technology involved in programming Web documents continues to improve. Already, it is possible to use the print command of existing applications to output usable Web pages. Increasingly, Web editors employ drag-and-drop and other CUI mechanisms to make layout of Web pages easier. Complex layouts like frames and tables are editable with mouse clicks and drags. Support for JPG, GIF, GIF89 and QuickTime make including graphics, animations, audio and video as easy as entering text. Chapter 5 described this as a new writing space.

This existing authoring environment addresses three of the CUI issues described by Meleis needed to insure the success of an information network: intuitive interfaces, authoring tools, and transport of heterogeneous data. Some vendors already plan to market container-based Web browsers. For example, Apple's Cyberdog project is built using OpenDoc.(7) Cyberdog can be used as both a container and as a component in other containers. Apple and IBM has stated publicly that they are committed to making OpenDoc comply with SunSoft's JavaBeans.(8) These allow developers and users to exploit Information Network opportunities.

In the summer of 1996, I organized an "Electronic Publishing Workshop," a summer project for students in Toyota Families for Learning (TFFL). The participants were adults working toward their GED in New Orleans public schools. Their writing skills varied starting from semi-literate. Participants learned basic skills such as typing and word processing. Using the computer as a writing tool was strongly emphasized. Beginning from the first day, and continuously, the TFFL Web site was used to publish students works. Students were also encouraged to explore the World Wide Web themselves. Using the Netscape browser was an effective way to teach basic computer skills. I located on the Internet and downloaded all the software tools used to create Web pages and also the Web server software itself. All were either available free or via "shareware." All of these tools first became available in 1996. Total investment was $50.00. These student's works can be viewed at our web site http://ss.uno.edu/Toyota/apprenticeship96/epIndex.html.

This experiment in part motivated my further research. First, no words I can write capture the pride and workmanship these people showed during the six weeks of this workshop. Through this workshop, these participants realized that they themselves can write and publish.

Figure C6.1: Electronic Publishing Workshop, Summer - 1996

Second, their work has attracted the world's attention. It is interesting to note that the TFFL site, continuously available for only four months, received 1,000 visits a week during November, 1996. Traffic is increasing 40% monthly. The statistics of TFFL server show that this type of content, once published, can be easily found on the Web. Popular search engines such as Yahoo and AltaVista will link to our site upon searching for "family literacy." It is of general interest. Visits from over twenty-five foreign countries were logged, two hundred megabytes of information transferred.

Third, the workshop and its Web pages have demonstrated how pencil and paper, computer word processing, video and graphics combine in the hyperlinked environment of the World Wide Web to make an Information Network, a new Writing Space. The existing on-the-shelf computer technology is enough to create and publish, program attractive Web pages.

Fourth, the most important, we have observed the lack of a model that guides these kinds of products. In the experiment I applied a dozen different applications(-centric) and crafted this web site in about 200 hours. The real writers, teachers and students and parents cannot be expected to have this skill. We want to define a model that is to be developed once by computer professionals and then to be used many times by end-users. The goal is to enable teachers and parents to author their own eduware.

Education Information Network (1)

Web browsers and Java technology based on open standards offer hope for truly platform-independent software development. "Develop once, deploy anywhere strategy" is now possible. Java Applet style software is marketable using networks. This makes possible an electronic market for software developers.

The basic information technology tools for transforming education in this direction are already available. Access to learning resources has never been as easy as it is via the Internet. And worldwide collaboration is a reality through the Web. Network aware development environments like Java and JavaBeans create flexibility in time, location, content, and form of software. The methods used to deliver educational content will be identical to the methods used to deliver educational software. The document-centric and component-based properties of U_S means that the content and the software are delivered in the same containers.

To benefit daily classroom activities will require schools to be equipped with networkable computers. Using the open standards of Internet will guarantee the maximum use of legacy system already in place. The appearance in the last quarter of NCs means that costs of new systems can be minimized. Buying and supporting NCs costs 10% of typical PCs. Using Internet standard networks also makes it easy to build intranets. Intranets are private networks that still allow for easy access to the worldwide Internet. Intranets allow individual schools and school systems to build private resources while still benefiting from outside sources.

The convergence of computing, communication, and document management technologies and the pervasiveness of the Internet have extraordinary potential for transforming information critical industries, especially education. We can begin to consider customized, on-demand learning, "education on-call". Education on-call simply refers to the potential of information networks to deliver a variety of specialized software tools necessary for customized education products, such as electronic books and online exams, as well as tools that facilitate collaborative interaction. The goal is to create flexibility, a key attribute is customized learning resources at least as easy to use as printed learning aids.

This paradigm shift provides the potential for reducing cost of access to information. It reduces the complexity of tools used for information access. It empowers educators to design and build virtual lesson plans. This is the paradigm of U_S. It moves software engineering into the hands of domain experts, and benefits all information industries equally.

Elements of an education information network are:

1. Virtual lesson plans: the documents of an education information network.
2. Electronic books: customizable textbooks and learning tools available locally or remotely.
3. Study tools: organized collections of virtual lesson plans designed to assist learning.
4. Collaborative tools: enable communications between students and instructors, students and students, students and parents, students and educators outside normal classroom boundaries. Examples; e-mail, Web browsers.
5. Digital library(s): storehouse and distribution center for U_S components, virtual lesson plans, and electronic books. Example; Web servers.
6. Virtual library(s): linkable internal and external information.

Virtual Lesson Plans

Virtual lesson plans (VLPs) can be understood as the documents of an education information system. They are used to contain information resources (IRs). More importantly, VLPs contain IRs and their relevant activities. IRs include all the elements of an education information network mentioned above, and include (but not limited to) plain text, graphics, video, audio, electronic books, links to virtual libraries, U_S components. Together, these are referred to as heterogenous data (HD).

VLPs is an abstract container class used to organize and present IRs--and VLPs are themselves IRs. The object model below reflects this recursive structure.

Figure C6.2: Information Resources, Object Model

This model can be used to construct both an authoring environment for educators and a working environment for learners. The authoring environment benefits from the drag-and-drop user interface of document-centric software to allow building of new VLPs and the reuse of existing or generic VLPs. For learners VLPs provide a "browser" like interface for user interaction.

IRs objects have only two attributes: IRa - "universal resource locator" (URL) like addresses to the Information Network; and HD : heterogeneous data. HD is also an abstract container class and can contain IRs. HD also has the behavior needed to display itself.

VLP generics specify only three operations: SEARCH, USE, and DISPOSE. All additional behavior can be added by including U_S components. These are interdependent operations, meaning that the precondition for one is the post condition of another. This is seen by the relationship:

DISPOSE( USE ( SEARCH ( IRa) ) );
IRa is an Information Resource address

1. SEARCH contains the complexity of the underlying network of computers (Internet and intranet), the location of required software (virtual and digital libraries), and the needed information resources. The pre-condition of SEARCH is a VLP address (IRa). The post-condition is unformatted HD.
2. USE contains all the complexity of the user interface. Pre-condition for USE is unformatted HD. There are two possible post conditions: 1. a valid IRa--starts another VLP; or 2. heterogenous data entered by user is passed to DISPOSE. USE is responsible for assembly of user inputs into HD.
3. DISPOSE is one or more stopping cases, and contains all exchanges of persistent data. Optional pre-conditions and post-conditions are heterogenous data (HD). Stopping cases can also be VLPs. This would initiate a new independent VLPs set that can be processed concurrently. These concurrent VLPs cannot exchange persistent data, but can attempt to exchange messages for synchronization.

A functional diagram for VLPs is provided below. Note the recursive nature which will allow uses to dynamically control behavior.

Figure C6.3: Virtual Lesson Plan, Functional Diagram

The user experience of exploring VLPs is similar to browsing the Web, with one not so subtle difference. In following links imbedded in a Web document, users are not required to return to previous documents. The recursive structure of VLPs ensures that control flow always returns to the originating VLP. This requirement insures execution of DISPOSE, and guarantees that persistent data can be preserved. The Dynamic Model below for VLPs documents this behavior.

Figure C6.4: Virtual Lesson Plan, Dynamic Model

There are two important benefits to the interdependent operations of DISPOSE( USE ( SEARCH ( IRa) ) );
First, clear boundaries are created between the three complex environments, while at most passing one parameter. Changing the behavior of networks, user interface, or persistent store will not affect others. Second, they serve to satisfy the "Service portability and transparency" requirement of CUI issues described by Meleis and mentioned in Chapter 1. Another important point, since HD is itself considered to be a container class which understands how to display itself, GUI issues can mostly be ignored in design and implementation of VLP's. Operation USE need only concern itself with identifying user output as either an IRa or HD and in some cases, supplying default responses.

The opportunity for software developers is the construction of generic VLPs, and the U_S components needed to control behavior, and needed authoring environments. The opportunity for authors is easy and open access to a new market for their educational content. The opportunity for educators is gaining real control of their computer recourses that are rapidly increasing in importance, and customizable content without the enormous duplicated effort that goes into the production and presentation of the same courses in thousands of locations--VLPs support information reuse and sharing of efforts.

Let us consider what is needed to construct a VLP. Tests are documents used repeatedly by educators. Constructing a test will require a minimum of two VLPs, a generic test container and generic question container. Both of these are built by professional developers and many different types can be widely available. A test authoring tool which employs drag-and-drop interface, again from developers, is used.

The experience of taking a VLP test is controlled by the
DISPOSE( USE ( SEARCH ( IRa) ) ); operations. This insures that activities not inside the test container are excluded until testing is complete. Likewise each question visited requires a response, even if it is "no answer." A time-out behavior can enforce completion.

VLP is just one example of a container class to exploit an Information Network. The U_S components used for VLPs can also be used by many other container classes, related to education, or not related. The U_S software paradigm is built to the Information Network, and its potential for software reuse.

Building truly reusable components for architecture-neutral document-centric software is a complex task. The simple examples presented here do not reflect the difficult of this undertaking. Using these components to assemble generic container classes, then building authoring tools to use them is a giant software engineering project. OpenDoc and OLE re[resemt limited success. Building on these achievements will require taking the added steps of open standards and neutral architecture and interface behavior.

Developers will find that these efforts will build markets for their products orders of magnitude larger then any now in existence. Of course, an undertaking of this size will be costly, but so is building current computer architecture costly. $2000 computers and $100 spreadsheet programs accurately reflect the amortized cost of these products over their market size. The only way to lower these unit costs is to grow the market. U_S paradigm is designed to do just that, to include all computing platforms, and to make new platforms possible. "Develop once, deploy anywhere." The global market potential can translate into free, or almost free computers will included a $20 monthly contract with electronic brokerages that supplies all Information Network needs. Developers contracted with these same brokers are paid a prorated percentage of gross--compensation based on who, when and how often products are used.

Remember, VLP is just one instance of U_S--a new writing space made possible by Information Networks.

Using Intranets to create Electronic Brokerages

One striking feature of the current educational model is the enormous duplicated effort that goes into the production and presentation of the same courses in thousands of locations with marginal reuse or sharing of efforts. In the new environment, the first schools and school systems to build substantial electronic resources will soon find that many others can and will want to reuse their works. This is the advantage of the standard, open environment of intranets. Very soon these pioneering schools will find that others not only want their work, but are willing to pay for the rights to reuse it.

Such a scenario is possible, but a crucial prerequisite for this is development of effective electronic payment systems. There have been many electronic markets developing(5). Education brokers and U_S can be one mechanism to solve this problem. Education will be a key application in electronic commerce. New innovative models of production, delivery and presentation are needed to take advantage of the power of information technology. "Education brokerages" (2) is a proposal to use information networks and new technological foundations (U_S) for a new just-in time, on-demand approach to electronic educational products to be offered through intermediaries, brokers. These can be organized around individual schools, school systems, universities, or new institutions like virtual universities. Education brokerage responsibilities range from establishing standards and quality requirements to effective customer/supplier payment and pricing systems.

Education is well suited to lay needed foundations for information brokers. The open standards of Internet and intranet provide easy availability, and flexibility in time, content, and form. The Web provides a standard document format described by HTML. Java adds object-oriented, network aware, component software. These are all architecture-neutral. What is needed is a method educators can use to construct electronic courses. Construction based on small, reusable components. A system that allows, even promotes sharing of components. Components that are at least as effortless to use as printed materials. Components that can be added to containers to build courseware.

The market for affordable, quality, easily reusable education resources will continue to grow. Compared to traditional publishing, education brokers(2) have almost no overhead and zero cost of sales. Their business is housed on the Internet where products are advertised and delivered almost without effort.

Conclusion

This chapter is an attempt to step back and observe, to decide if recent rapid changes provide new ways to look at problem domains. Are there any new patterns or models? Is software engineering experiencing a paradigm shift?

Implementations of Hypertext defined a writing space at least thirty years before the Web gave it global scope. Berners-Lee imagines another possible leap forward as computer software becomes ubiquitous. "We could define general-purpose languages in which assertions could be made. Within these assertions, axiomatic concepts could be defined in human-readable documents. In this case, the language's power to combine concepts from different areas could allow development of a more powerful information space on which we could base machine-reasoning systems. Such knowledge representation (KR) languages have not had a significant impact on computer applications ..."(3) ... yet.

A new paradigm provides another framework for thinking about problems. Berners-Lee suggests that U_S can provide a framework to implement machine-reasoning systems. As Licklider says its "... getting into position to think."

The goal is to create problem-solving environments (PSEs). PSEs are needed to bridge the gap between increasingly complex machines (whose exploitation takes more and more expertise) and the growing community of non-expert users. PSEs describe harnessing computers and interconnected networks, making them powerful resources for education.(4)

Specification: Virtual Lesson Plan
(One instance of an Information Network Writing Space)

Definition: VLP is one implementation of an Information Network document. It is a writing space for a structured program of instruction.

Model: existing lesson plan used by teachers to organize classroom activities.

Requirements: Information network, writing space:

Structured browsing to insure students cover required materials.

Authoring tools for teachers to construct VLPs.

Generic VLP documents and U_S components.

Prototype: none, except the existing pencil and paper writing space versions.

Scenario:
Teacher builds a TEST VLP using JavaBeans

An illustration of how JavaBeans are intended to function. (9)

In this scenario a user uses an application builder to create an applet. The application builder generates various pieces of source code. This is an example of what is already possible today, but is more complex then what is required if teachers are to be programmers.

1. Needed tools.

1.a) TestBuilder Java application builder.
1.b) Java Bean components ... beans in a JAR file. This includes a "Button" component and a "DatabaseViewer" component.
1.c) TestBuilder and Bean components are already configured to work together by a certified Education Broker.

2. Laying out the applet.

2.a) The user starts to create a new custom applet called "FooFinalExam" in TestBuilder. Initially they start with a blank applet template. TestBuilder creates a FooFinalExam.java file to represent the state of this applet.
2.b) The user selects a "button" from the TestBuilder beans menu and drops it onto the applet template. TestBuilder uses "new Button()" to allocate a new Button instance. TestBuilder then adds the new button as a member field to the FooFinalExam class.
2.c) The user selects a "database viewer" from the TestBuilder beans menu and drops it onto the applet template. Because the database viewer is a fairly complex bean it comes with some serialized state to pre-initialize itself. The TestBuilder tool therefore uses the Beans.instantiate utility method to read in a serialized object instance. TestBuilder then adds this new database viewer object as a member field to the FooFinalExam class.

3. Customizing the beans.

3.a) The user selects the button to edit it. TestBuilder uses an introspector to obtain a BeanInfo object describing the bean. The user then interacts with button properties to customize the button's appearance. The updates are applied back to the bean as they happen.
3.b) The user selects the database viewer and asks TestBuilder to edit it. Using an Introspector, TestBuilder discovers that the database viewer comes with its own bean Customizer class. The database viewer customizer uses a set of package private methods to setup the state of the database viewer bean.

4. Connecting up the beans.

4.a) The user now decides that they want to hook-up the button to prod the database viewer. They select the button on the screen and pull-down menu to select the "action" event desired. A text editor lets the user can type in needed text.
4.b) Automatically generated FooFinalExam.
4.c) In addition, behind the scenes, TestBuilder creates an adaptor class to connect the button to the FooFinalExam.
4.d) TestBuilder creates a new instance of the needed object named FooFinalExam and registers its methods.

5. Packaging up the applet.

5.a) The user decides they, soTestBuilder uses Java serialization to store away the FooFinalExam object in a FooFinalExam.ser pickle file. As part of storing away the FooFinalExam object, the two beans instances (the button) and databaseViewerl members) also get stored away. The TestBuilder also generates some initialization code to reconstruct the event hookup.
5.b) TestBuilder creates a FooFinalExam jar file holding the pickle and the .class files needed by the applet including the hookup class file and the .class files for the beans themselves.
5.c) TestBuilder also generates a sample HTML page that uses the applet tag to load the pickled FooFinalExam.ser from the FooFinalExam.jar file.

6. Trying it out.