Re-Engineering Education -

Chapter 20 - Software Design
 

There are four main modules of the software, which is given the preliminary name of OpenSourceLearning.net, pending debate:

• Instruction,

• Homework and evaluation,

• Courseware development and maintenance, and

• Teacher and administrative.

We will first consider how one qualifies for a diploma, how courses will be organized, then nomenclature, and then consider each of the four modules in turn.  At this level of design, we are focusing on math and science courses (including laboratory selections), but with the intention to extend the design to English courses, foreign languages, history, literature, psychology and other more verbally oriented content areas.

All of the student’s and teacher’s interactions with the courseware system are via a browser, so that the particular computer system (Wintel, Linux, MacIntosh, Unix, etc.) is not restricted.

Instruction

The instruction module is relatively straightforward.  The topics are presented in the prescribed sequence according to the courseware. The choices offered to the student are taken from the database of courseware materials available: text, audio/visual lectures, or even experiential modules where the student performs experiments or otherwise interacts with virtual manipulatives of some kind. The student studies from the material taken from the database, so there is no printed text book (though there is nothing to prevent a printed version, either).  Where the material requires a royalty payment, the student will be informed and asked for permission to proceed.  If given, the student’s account will be debited but only once no matter how many times the material is accessed by that student.  The student is free to stop, rewind and re-view any audio/visual presentation, or switch to any other presentation in any modality.

The courseware will be designed to permit as broad a range of creativity on the part of course designers as possible, but the basic presentation is expected to be fairly conservative: a presentation or lecture of some type followed by exercises that extend the lecture, serve as homework, and as continuous evaluation. There are no tests in the traditional sense, because all work is a test in that it has to be mastered in order to move to the next topic. In this manner, the system is similar to errorless learning paradigms, so that all anxiety about tests is eliminated.

Although user authentication is a key component, to prevent deliberate or inadvertent corruption of a user's data, we do not have any concern about someone substituting for another in order to avoid the actual content of the course. Because evaluation is so pervasive and integral to the whole process, including spiraling re-evaluation of prior topics, anyone who attempted to substitute someone else's work for their own would be found out the first time they were forced to do a lesson under supervision.

Coming to each topic in the sequence, the student has a choice of several text expositions of the topic, taught at different levels of abstraction or prepared for different learning styles (e.g., theoretical, concrete, example driven, even experiential if appropriate for the material), or a choice of several audio/visual presentations again at different levels of abstraction or for different learning styles. Material designed for specific learning disabilities such as dyslexia or ADD or indeed any requirement can be provided. These choices may be of different presentation themes within an instance of courseware, or of the same presentation theme from different instances of courseware, or however the student chooses to filter the available material on offer.

The choices will carry a ranking from other students, and links to the recommendations relevant to those choices. The rankings and recommendations are intended to function very much like the user reviews on Amazon.com and other major web sites, as a guide to selecting the most appropriate one. 

After selecting an audio/visual lecture, the student can pause, back up, and listen to the same section as many times as desired.  At any point, the student can select an alternate topic presentation, or indeed as many as he or she might like.  When ready, the student will be taken to the evaluation module, which must be successfully completed in order for the topic to be logged as mastered.  When a topic is complete, the student may progress to the next topic or pursue topics from another course. 

If difficulties are encountered, the student may access online help by returning to the text or the audio/visual lecture, via a collaboration group, from a teaching aide, from the course teacher, or any other source.  Regardless of how much help is provided, the student must still demonstrate mastery of the topic individually.  All work is automatically saved, so that if the student ends the session without demonstrating mastery, he or she can resume at the same point.

All solution attempts are logged to an audit database for review by the course teacher.  If a student gets stuck, he or she may end up in a small group to work on the topic or possibly work one on one with the teacher either in person or via conference connection. Collaborative work is encouraged at all points up to demonstrating mastery, but students be warned to perform only practice homework in collaborative groups. Otherwise, subsequent spiraling re-evaluation may force them to revisit the topic.

Course topics will be marked to indicate required for all students to obtain credit, required only for students who want an “A”, required only for students who want a “B” or higher, or optional for enrichment only. It is an option of the courseware writer whether or not a student may tackle other topics while also working to gain mastery of a required topic.  Optional topics, or optional for A or B only, may obviously be put on hold while the student proceeds to the next required topic.

Continuous Evaluation

When ready, the student will be taken to the evaluation module where problems are presented and solutions evaluated.  Most but not all problems will be drawn from the present topic.  Randomly selected problems from prior topic areas will be presented periodically to ensure that any topic, once mastered, remains mastered.  When the current topic area is completed after mastery is demonstrated, if difficulties with problems from a prior topic indicates that a refresher for that topic is advisable, the student will automatically be taken back to that topic and he or she will have to demonstrate mastery of that topic all over again.  Prior topics may be from the same course or from prior courses in the taxonomy.

When all the course topics have had mastery demonstrated, a period of time must elapse before the course is considered completed, perhaps two or four weeks but at the specification of the courseware designer.  During that period, a certain number of randomly presented topic problems must be evaluated.

By comparison, the evaluation module is far more complex than the instruction module.  There must be a database of problem templates from which the module will generate each unique problem.  (Problems may or may not be royalty bearing as well as the instructional material, or the problems may be tied to specific instruction selections.)  Where possible, the software should capture intermediate results for subsequent review.  An algorithm must be developed that heuristically weights the present topic and past topics in selecting problems to be presented.  Where current topics implicitly subsume older topics, e.g., arithmetic operations during an algebra course, the newer problems must be tagged to indicate that they preclude having to randomly present older, base material.

Note that, although the student can select any instructional presentation of the material, the problem database is standardized and universal.  The student has either mastered the material, or not.  The definition of mastery will be defined by the courseware writer, though optional problems will be allowed if selected by the student.

Courseware Development and Maintenance

The courseware developer will define the course being developed, topics to be presented (required and optional), and contributions to the database of problems or problem templates required to demonstrate mastery.  An external, diploma granting authority will determine whether the course is required or optional, and which topics are required for a specified grade. A peer review mechanism will evaluate the course once finished, and recommend publication or revision.  Publication of the course can be via an open catalog or via a closed catalog subject to approval.

Contributions to the problem database are encouraged, but are an independent, parallel peer review and approval process.  Anyone can suggest problems, not just a courseware developer, but problems must be vetted s acceptable to demonstrating mastery (and presumably not encumbered by copyright). Since the definition of having demonstrated mastery of a topic will not be at the discretion of the courseware developer, this will of necessity be a much more formal process. We anticipate spirited debate regarding the inclusion or exclusion of specific problems.

The courseware developer can include practice problems as part of the presentation, including their solutions on request of the student, but these are not considered part of the continuous evaluation process.

Problems under provisional consideration for inclusion in the problem database may be randomly presented for evaluation of the problem, not the student. Statistics on how often a given problem is solved on the first try, and how long to complete a correct solution, will be maintained for analysis by the approval authority for both provisional and accepted problems.  Problems that are subject to frequent failure in actual use will be reviewed for possible amendment or deletion.

The courseware developer will also define the presentation themes to be part of the course, which may be a single theme or multiple themes targeting different audiences, but the course will not be limited to just those presentations. A courseware developer must present an entry for each defined presentation theme, but could have two or more presentations for an honors theme, or could have alternative presentations outside the defined themes for just one topic.

Courseware development is to be modeled on Sourceforce.net, the primary collaboration site for open source development projects. If a given teacher thinks they have a better presentation  for a given topic, then the software should encourage such individual initiatives.  If the students think they have a better presentation, then they would have equivalent access. The software should encourage as much flexibility and experimentation as possible, all of which can be supported because each student still has to demonstrate mastery to an absolute standard.

Any student can submit their own comments, including recommended alternative presentations, for the consideration of the courseware developer. This database of comments, recommendations and (possibly) student annotations will be available to the courseware developer to foster continuous quality improvement in each instance of courseware. 

The audit database used by teachers for administrative purposes will also be available for researchers and courseware developers. Statistical analysis will show which approaches are the most effective for the rainbow of student abilities and disabilities, all of which will feed back into the continuous quality improvement process.  Any improvement in any course or indeed an individual topic in any course can be updated at any time.  Freed from the lead times, costs, and requirements for uniformity of traditional textbook developers, courses can improve in quality over a matter of months or even days, as compared to years and sometimes decades today.

Teacher and Administrative Capabilities

The role of teachers will both stay the same in many ways, and also radically change in key respects.  The base concept of this approach is to relieve the teachers from the tedious and repetitive aspects of teaching, to free them for the role most aspire to - closely working with students to ensure their progress and their interest.  Students will have to be closely monitored to ensure that they are actually doing the work.  The students who want to zoom ahead will need less monitoring, those with little motivation will need more monitoring. Those who can't or won't learn the topics will require focused intervention, possibly including escalation to the administration.

The system must provide the teachers with the tools to follow the progress, or lack of progress, of all the students in their charge.  This may be many students for a single subject, or a smaller group of students across all subjects.  This is readily done by the system, because the system constantly tracks where each student is with regard to their scheduled progress with the topics in each course.  The system needs to store a planned schedule for each student, so that it can prompt the teachers with those falling behind.

More subtly, the system has the information in the audit database to detect patterns of difficulty and to suggest specific remedies.  This capability may require a great deal of effort to reach a useful stage, so that initially it will be relegated to after the fact investigations of the audit database and the information on scheduling versus performance.

For the administration, a more management view of the same information can be presented.  If a given teacher has more students who are failing to maintain their schedule, then more resources can be shifted to assist.  Conversely, a teacher whose students are making more progress may have time to assist a colleague whose students are falling behind.  Alternatively, the administration may create more of a pooled teacher responsibility for the students.  The system must provide the administration with the information necessary to make these adjustments, while providing the teachers with the capability to balance their loads with respect to the differing requirements of different groups of students.

Not a Silver Bullet

We must also remember that this is not a silver bullet for the issues confronting our educational system.  While this should do a great deal for the math and science courses, it will have less applicability to other disciplines.  For example, the system might lead students through historical material, but discussions still have to occur in order to teach critical thinking skills.  These discussions could take the form of online collaboration groups, or traditional classroom groups, or a combination. 

Furthermore, the grading system proposed above can only apply to the automatically presented and learned factual material. In a history context, this may mean only that the automatic grade selected relates to this material.  A separate, more traditional grade may have to be assigned for written analytical parts of the course.  On the other hand, some creative teachers may devise ways to use the system to that end.  The courseware development capabilities must be flexible enough to allow adaptation to new modalities.

Realistically, this means that the courseware development system will evolve over time.  In the beginning, it may be applicable only to science and math courses, then applicable to some aspects of language, history and psychology courses, and eventually applicable to instruction in ways that we cannot predict at this point.  But the ground will be prepared for continuous quality improvement in the content of the courseware, the scope of the courseware, and the usefulness of the development, teacher support, and administrative management components.  We will all learn together how to use this new tool to improve the lives of students, teachers, administration, and - over time - the general population.