The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. To renew call Telephone Center, 333-8400 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN Vs 1711 APR 03 JAN 6 1997 I996 L161— O-1096 >• * ^IUCDCS-R-77-909 f/& I h ft UILU-ENG 77 1760 THE PASCAL SERIES: A PLATO LESSON SEQUENCE by TIMOTHY JON THOMPSON December 1977 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS University of Illinois UIUCDCS-R-77-909 THE PASCAL SERIES: A PLATO LESSON SEQUENCE by TIMOTHY JON THOMPSON December 1977 Submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 1978. Digitized by the Internet Archive in 2013 http://archive.org/details/pascalseriesplat909thom Ill TABLE OF CONTENTS Page 1. PLATO AND CAI AT THE UNIVERSITY OF ILLINOIS .... 1 2. THE DESIGN OF A PLATO LESSON SEQUENCE 3 2.1 What is a Lesson Sequence? 3 2.2 Planning a Lesson Sequence 4 2.3 The Breakdown of Lessons 6 2.4 Describing the Individual Lessons 7 2.5 The Continuity of a Sequence 7 2.6 Implementation of a Sequence 8 3. THE PASCAL LESSON SEQUENCE 10 3.1 Introduction 10 3.2 Initial Planning 10 3.3 The Major Concepts 11 3.4 The Breakdown of PASCAL Lessons 13 3.4.1 Arithmetic 15 3.4.2 Program Structure and Execution .... 16 3.4.3 The IF Statement 17 3.4.4 Basic Input/Output 18 3.4.5 The CASE Statement 19 3.4.6 Looping — WHILE and REPEAT Statements . . 19 3.4.7 Looping — The FOR Statement 20 3.4.8 Arrays 21 3.4.9 Procedures 21 3.4.10 Functions 22 3.4.11 Recursion 23 3.4.12 Data Types 24 3.4.13 Pointers 24 3.4.14 Records 25 3.4.15 Files and Advanced Input/Output .... 26 4. THE DESIGN OF AN INDIVIDUAL PLATO LESSON 27 4.1 The NEXT Syndrome 27 4.2 Questions, Questions, Questions 28 4.3 Animation 29 4.4 Full Screen Erases 29 4.5 Utilities 30 5. THE IMPLEMENTATION OF THE PASCAL SERIES 31 REFERENCES 33 1. PLATO AND CAI AT THE UNIVERSITY OF ILLINOIS The PLATO computer network is a state-of-the-art CAI (Computer Assisted Instruction) system which has been developed at the University of Illinois over the past 17 years. Presently, this system is connected to over 1000 terminals, and is controlled by two large CDC computers. Educational lessons exist for virtually any subject, and are used extensively in courses at this university and else- where. PLATO has a tremendous potential as an educational tool, used either in conjunction with other methods of teach- ing or by itself. CAI in general has many important capa- bilities. Its patience, accuracy and memory are well suited for remedial and repetitive types of instruction. Its com- putational abilities can be used to produce complex simula- tions and displays. It is very flexible, and can utilize any style or logic of teaching that can be defined. It can evaluate a student's performance immediately, and modify itself accordingly. However, all of these capabilities are dependent upon the authors who write the CAI lessons. There- fore, these authors have a tremendous responsibility in pro- ducing a product which will effectively teach a large number of students. The Computer Science Department at this university has a catalog of more than 135 PLATO lessons. Introductory computer science courses, which are required of all engineer- ing and business students and hence have large enrollments, have made excellent use of the lessons on FORTRAN and PL/I. These lessons have been developed and the use of them studied under the ACSES (Automated Computer Science Education System) project [4] . The general reaction of students toward the project has been favorable. A few poorly written lessons were inevitable, due to the lack of experienced authors and insufficient reviewing and evaluation of the lessons prior to their use by a large number of students. Some of the lessons have even had to be completely rewritten. Problems such as these can be expected in what is essentially an un- precedented endeavor. However, it is hoped that a carefully designed and implemented series of lessons can avoid many of these problems, and lead to even more efficient use of PLATO. This paper will discuss the development, design, and imple- mentation of such a sequence: the PASCAL Series. 2. THE DESIGN OF A PLATO LESSON SEQUENCE In this section, we discuss the more general factors which are common (or should be common) to most lesson se- quences. In the subsequent section, we discuss a specific sequence, the PASCAL Series. 2. 1 What is a Lesson Sequence ? The concept of a lesson sequence varies, depending on the subject matter and the way in which it is presented. In this discussion, we define a lesson sequence to be any number of PLATO lessons intended to teach some subject in a sequential fashion. In other words, there is a definite ordering of the lessons, and the student is expected to study them in that order. The subject may be anything from reading skills to differential equations, the level of instruction from basic to advanced, and the scope from a single concept to a college curriculum. The distinguishing feature of a sequence is the ordering of the lessons, enabling each lesson to make assumptions about what the student has already studied. A lesson sequence need not be restricted to a linear sequence. Consider Figure 1, which shows a series of lessons as nodes on a directed graph, indicating the order in which they are to be studied. Node 4 is in essence an optional lesson, which may or may not be studied after the first three, without affecting the remainder of the sequence. An extension of this would be a tree-structured sequence, as in Figure 2. After studying the first three lessons on basic programming the student could go into engineering applications (the right branch) or business applications (the left branch) . The lessons in these examples still have a definite ordering, and hence constitute a sequence. 2 . 2 Planning a Lesson Sequence The design of a lesson sequence is most logically done in a top-down manner, by first defining the purpose and goals of the sequence as a whole, and breaking it down from there. In any CAI lesson sequence, there are many factors to be considered. Who are the intended students? How much do they know (if anything) before they start? How much and how well do you expect them to learn? How will the material be presented? How will you determine what they have learned? These are all questions which must be considered, since proper planning is of vital importance in any CAI environment. The educational objectives and considerations in planning a gen- eral CAI curriculum have been adequately discussed in Hicks [2] . He will consider those aspects pertinent to the develop- ment of a PLATO lesson sequence. The most obvious first step in planning a PLATO lesson sequence is determining the subject matter and scope of the sequence as a whole, taking into account such factors as the intended students and use. If the sequence is intended as FIG. 1 BUSINESS APPLICATIONS \ BASIC PROGRAMMING ENGINEERING APPLICATIONS FIG. 2 the sole means of instruction in a self-study course, care must be taken to assure its completeness. If the sequence is supplemented by other methods of instruction, such as lec- tures, the completeness of the sequence by itself may be sacrificed, but only if its intended use will fill in the intentional gaps. Another factor which should be considered is the communication, if any, which will exist between the lessons in the sequence. Perhaps the student's performance level in one lesson could be passed on to the next lesson to better tailor the presentation of material. A single lesson could be designed to present the same material in two formats, based on parameters set by an instructor, and enabling the lesson to be used in different contexts. The means and ex- tent of any communication between lessons should be specified from the start. 2. 3 The Breakdown of Lesson s The next step is the actual breakdown of the sequence into individual lessons, somewhat like dividing a book into chapters. Each chapter (lesson) is a convenient unit of instruction, small enough to be completed in a reasonable time without becoming tedious, yet large enough to encompass a significant concept. In terms of a PLATO lesson, a reason- able amount of time is anywhere from 20 to 50 minutes, the length of a typical class period. A lesson taking 30 to 40 minutes may be preferred, since this will not fatigue the student, while allowing for review and a possible final quiz. The breakdown of the lessons depends a great deal upon the subject matter of the sequence. Occasionally, the subject itself provides a convenient separation of concepts or information. The sequencing of the lessons can be done in a linear or tree-structured fashion, as discussed pre- viously, taking advantage of the fact that the lessons will be studied in that sequence. In any case, this is the most fundamental step in the design process. 2. 4 Describing the Individual Lessons After a preliminary breakdown has been specified, a more detailed description of the contents of each lesson is made. In the process of describing the major concepts to be covered in a particular lesson, it may be discovered that the lesson will be too short or, more often, too long. Modifications to the sequence as a whole may be necessary to achieve an adequate balance between the lessons. 2. 5 The Continuity of a Sequence When specifying the individual lessons, it is important to maintain a continuity in both the subject material and style of presentation. The lessons must be described in enough detail to eliminate any conceptual gaps or weak links which would disrupt the student's progress in an otherwise smooth flow of information. If the style of presentation 8 varies in a seemingly disjoint manner, the student can like- wise become disoriented. An important factor in continuity is the adoption of conventions for movement within the lessons. For example, if one lesson used SHIFT-DATA to get to the table of con- tents, while the next lesson used SHIFT-LAB, one can imaging the confusion which would result. A standard table of contents and topic structure along with suitable movement conventions should be standard practice in every lesson of the sequence. 2. 6 Implementation of a Sequence Perhaps the single most important factor requiring a detailed description of the individual lessons is the fact that the final implementation of the lesson will almost cer- tainly be done by more than one person. In fact, each lesson may be implemented by a different person. Since each person's style in writing a PLATO lesson is different, the only means of establishing any uniformity and consistency is through the lesson sequence design. Certainly, the variety which results from different styles can add a great deal of interest, but the result of giving total freedom over lesson content to the individual author can be nothing short of chaos. Therefore, the lesson descriptions should include all concepts and the order in which to present them, along with some guidelines on the general format of the lesson, to provide consistency and prevent confusion as students go from lesson to lesson. This discussion brings us to a significant problem in the implementation of any PLATO lesson sequence. Due to a lack of experienced PLATO authors, lessons have often been developed by student volunteers, either for a course project or their own enjoyment. Though these students are seldom lacking in ambition, their lack of experience in using the tremendous capabilities of PLATO is a handicap. It usually requires the writing of at least one lesson (hopefully a practice lesson) before one can hope to be an effective author. Some students may be preoccupied with producing clever animations, while leaving important concepts by the wayside. Other students may just be poor PLATO authors, but this may not be discovered until the student has pro- duced a poorly written lesson, which then must be used for lack of anyone to rewrite it. Given the present conditions, these problems are difficult to avoid, but developers of new lesson material must be aware of them in order to reduce, if not eliminate, poorly written lessons. 10 3. THE PASCAL LESSON SEQUENCE 3 . 1 Introduction The practical experience on which this paper is based was obtained through the design and partial implemen- tation of a PLATO lesson sequence to teach PASCAL/ a pro- gramming language widely used in the teaching of computer science. Since there were no existing lessons on PASCAL, and since a number of computer science courses at this uni- versity use the language, the need for the sequence was readily apparent. The lack of existing lessons was actually an advantage, allowing greater freedom in the sequence design. 3. 2 Initial Planning The first step in constructing the PASCAL Series was the identification of the intended students and use of the sequence. In this case, the students were assumed to be of college level, with no prior experience in programming. The lessons, therefore, are intended to be used in an introductory computer science course, with the intention of teaching the fundamentals of computer programming. Since there are a large number of implementation-dependent features in PASCAL, such as control cards and input/output, the sequence cannot be strictly considered a self-study unit. Instead, the lessons should be used to teach the details and concepts 11 involved specifically with PASCAL, in conjunction with the teaching of general programming concepts, such as searching and sorting, by other means. The next step was to determine the scope of the se- quence. Obviously, it had to start from the very basics, since the students were assumed to have no prior knowledge. However, the upper limit was an open question. Introductory courses in FORTRAN or PL/I usually cover the concepts up to subroutines and functions. Courses which use PASCAL are usually intended for computer science majors, and hence a much more extensive coverage is called for. Therefore, the upper limit of the sequence is essentially undefined, and could go so high as to cover every feature and detail of PASCAL. In the final design, lessons are included to cover advanced topics, but the individual lesson descriptions are not as detailed. Actually, it might be desirable to vary the content of the more advanced lessons according to the course which uses them. Since the course or courses which will use these lessons has not been specified, most of the detailed design work and implementation was directed toward the introductory and intermediate lessons . 3. 3 The Major Concepts As a preliminary to the actual breakdown of lessons, the main concepts to be included in the sequence were listed as shown in Figure 3. Next, these concepts were ordered to 12 1 . Introduction to Computers and Algorithms 2. Numbers, Variables, Assignments, and Expressions 3. Program Structure and Execution 4. Control Structures — GOTO, Conditions, Iteratives 5 . Input/Output 6. Procedures and Functions 7. Types—Scalar, Boolean, Character, Subrange, Arrays, Sets, Records, Files, Pointers 8. Recursion Figure 3. Major Concepts Introduction to Computers and Algorithms Numbers, Variables, Assignments, and Expressions Program Structure and Execution GOTO Basic Input/Output Conditional Control Structures Iterative Control Structures Arrays Procedures and Functions Recursion Types — Scalar, Boolean, Character, Subrange, Sets, Records, Files, Pointers Advanced Input/Output Figure 4 . Ordered Concepts 13 indicate the minimum prerequisite concept necessary for each, illustrated by the directed graph in Figure 4. This ordering is relatively straightforward except for a few cases. Basic input/output uses the eof and eoln functions, which return a boolean value. The usefulness of this value can only be seen through the use of IF statements, hence the dependence of basic input/output on conditional control structures. The placement of the concept of arrays required the most con- sideration. This concept could be placed either before or after the iterative control structures. If arrays were introduced before the iteratives, all examples involving loops would have to be done with IF statements, a clumsy method to say the least. Since PASCAL is designed to encour- age structured and straightforward programming, it was decided that the concept of iterative control structures would more naturally precede arrays. 3. 4 The Breakdown of PASCAL Lessons The actual breakdown of individual lessons was the next step. The final breakdown, along with the relative ordering of the lessons, is shown in Figure 5. (You may notice that the Introduction to Computers and Algorithms is missing from the lessons. It was felt that the need for a lesson of this type was adequately filled by an existing lesson, algolingo. Hence, this lesson was not specifically included in the sequence.) A few revisions were necessary 14 1. Arithmetic V 2. Program Structure and Execution V The IF Statement T 5. Looping- — WHILE and REPEAT Statements Basic Input/ Output 6. 1 The CASE Statement 7. Looping — the FOR Statement 8. Arrays Procedures r 12 Types 10. Functions 11. Recursion 13. Pointers 14. Records 15 Files and Advanced Input/Output Figure, 5. The PASCAL Lessons 15 before this final breakdown was achieved. For example, the iterative control structures WHILE, REPEAT, and FOR were originally intended for a single lesson, but were separated into two smaller, more manageable lessons. A similar separ- ation was made between the IF and CASE statements. All that remained was to specify in much greater detail the contents of each lesson. This was done through the use of outlines, defining the major topics of each lesson, and the concepts to be discussed in each. 3.4.1 Arithmetic I. Variables and Identifiers concepts: variables, identifier naming rules, mnemonic names II. The Assignment Statement concepts: assignments, increments III. Integer and Real Numbers concepts: differences between INTEGER and REAL, forms of REAL numbers , exponential forms IV. Integer and Real Variables concepts: INTEGER and REAL variables V. Expressions and Operations concepts: arithmetic operators, no implied multi- plication, DIV and MOD operators VI. Operator Precedence concepts: normal hierarchy, parenthesis 16 VII. Mixed Types concepts: operations and assignments with mixed types 3.4.2 Program Structure and Execution I. Program Heading concepts: basic format II. Variable Declarations concepts: basic format, REAL and INTEGER declarations, multiple declarations, variables must be declared III. Constant Declarations concepts: purpose of constants, basic format IV. Statement Block concepts: basic format V. A Complete PASCAL Program concepts: contents of a complete program, program heading, declarations, statement block VI. Simple and Compound Statements concepts: use of compound statements, basic format, nested compound statements, difference from statement block VII. The Semicolon concepts: use as statement separator, examples of normal use, use with compound statements VIII. Comments concepts: use ( and basic format 17 IX. Program Execution concepts: sequential execution including compound statements X. The GOTO Statement concepts: basic format and use, branching forward and backward, ordering unimportant XI. Label Declarations concepts: basic format and use, position in declara- tions, use is mandatory 3.4.3 The IF Statement I. Decision-Making concepts: ability of computer to make decisions, practical examples of decisions and cor- responding flowcharts, IF-THEN and IF-THEN- ELSE forms II. The IF Statement concepts: basic format, identify condition and action III. Conditional Expressions concepts: relational operators, trueness and falseness, multiple conditions, AND and OR IV. Compound Statements concepts: basic use and format with IF statements, indentation of code V. The ELSE Clause concepts: basic use and format, use with compound statements 18 VI. Nested IF Statements concepts: simple use and format, extended example VII. Semicolons and IF Statements concepts: no semicolons except for compound state- ments, common errors involving semicolons 3.4.4 Basic Input/Output I . Computer Input and Output concepts: basic forms of I/O, position of data after program II. The READ Procedure concepts: basic use and format (numbers only) III. The EOLN and EOF Functions concepts: value is true or false, basic format and use with READ and IF statements IV. The READLN Procedure concepts: basic format and use V. The WRITE Procedure concepts: basic use and format, literal character strings and unformatted numbers VI. Formatting concepts: minimum field width and fraction length, basic format and use VII. The WRITELN Procedure and EOL concepts: basic format and use, EOL used within WRITE 19 3.4.5 The CASE Statement I. Introduction to Choosing Alternatives concepts: choosing one action out of several alternatives, practical example II. The CASE Statement concepts: basic format, simple example, equivalent IF statements III. More Details concepts: multiple labels, no duplicate labels, no branches from outside, only 1 case selected, use with compound statements, selector can- not be REAL IV. An Extended Example concepts: when to use CASE versus IF's, development of complete program 3.4.6 Looping — WHILE and REPEAT Statements I. Introduction to Looping concepts: controlled looping, practical example II. The WHILE Statement concepts: basic format and use, condition is tested first, possibly done zero times, use with compound statements III. An Example Using WHILE concepts: development of a complete program 20 IV. The REPEAT Statement concepts: basic format and use, condition is tested after loop, loop executed at least once, use of semicolons, common mistakes (unde- fined counters and limits) V. An Example Using REPEAT concepts: development of a complete program 3.4.7 Looping — The FOR Statement I. Introduction to Counted Looping concepts: control counters, counting forward and backward, practical example II. The FOR Statement concepts: basic format, simple example (just using TO) III. More Details concepts: control variable can't be real, can't be altered, final value is undefined, parameters are evaluated only once, loop is possibly executed zero times, use with compounds IV. TO and DOWNTO concepts: basic format and simple examples of forward and backward loops V. An Example Using FOR concepts: development of a complete program \ 21 VI. Nested FOR Loops concepts: simple examples and use 3.4.8 Arrays I. Introduction to Arrays concepts: the need for arrays, practical example II. Arrays in PASCAL concepts: basic format of declarations, simple use and examples III. Using Arrays and Loops concepts: development of program using arrays and FOR statements IV. Common Errors in Using Arrays concepts: going out of bounds, undefined values, show examples V. Two-Dimensional Arrays concepts: basic format of declarations, simple use and examples 3.4.9 Procedures I. Introduction to Procedures concepts: the need for procedures, save space, save time, structured programming II. A Simple PROCEDURE concepts: basic format of a procedure with no parameters, to print a heading 22 III. How to Use Procedures concepts: placement in complete program, basic format of reference and multiple use IV. Local and Global Variables concepts: define local and global, examples, precedence of local variables if names are identical V. Parameters concepts: the need for parameters, passing values back and forth, practical examples VI. Value Parameters concepts: basic format and use, value is copied to procedure but not back VII. Variable Parameters concepts: basic format and use, effect of copying value back to calling procedure, differences from calling by value, ability to combine value and variable parameters VIII. Examples Using Procedures concepts: passing arrays, forward reference, pro- cedures calling procedures 3.4.10 Functions I. Introduction to Functions concepts: built-in functions, need for user-defined functions 23 II. A Simple FUNCTION concepts: basic format and simple example, returns to name of function III. An Extended Example concepts: basic format and use in a complete program, passing arrays as parameters IV. Functions and Procedures as Parameters concepts: basic format and use in parameter list, simple examples V. Using Functions concepts: function should not change global values (side effects) , forward references 3.4.11 Recursion I. Introduction to Recursion concepts: a simple recurrent definition and its evaluation II. A Recurrent Function for Factorials concepts: basic format and use within a complete program III. The Inner Workings concepts: stacks and storage of parameters, illus- trate factorial computation, other types of recursion involving two procedures calling each other IV. An Extended Example concepts: the development of a complete program using recurrent procedures 24 3.4.12 Data Types I. Introduction to Other Types of Data concepts: number, character, boolean, others II. INTEGER and REAL Types concepts: basic declarations and use III. BOOLEAN Types concepts: basic declarations and use with IF statements IV. Character Types concepts: single characters, ORD and CHR functions V. Scalar Types concepts: general scalar types, ordered set of values, PRED and SUCC functions, user- defined types such as color VI. User-Defined Types concepts: basic format and use of TYPE statement, simple uses with assignments, IF ' s , CASE, FOR, arrays with scalar index VII. Subrange Types concepts: basic format of declaration and use, validity checking at run-time 3.4.13 Pointers I. Introduction to Pointers concepts: practical example of use of pointers, static and dynamic variables, storage of these variables 25 II. Simple Pointers concepts: basic format and use of pointer declara- tions, procedure NEW, the NIL pointer III. The Use of Pointers concepts: pointers as part of a record, simple examples IV. Linked Lists and Pointers concepts: linked lists of records, simple examples of adding and deleting nodes V. Tree Structures and Pointers concepts: binary tree of records using pointers, adding and deleting nodes, other pointer structures 3.4.14 Records I. Introduction to Records concepts: data structures consisting of differing types of data II. The Declaration of a Record concepts: basic format of RECORD type, simple example of complex numbers III. Using Records concepts: reference by record and field names, field names must be unique IV. The WITH Statement concepts: basic format and use 26 V. Variant Records concepts: basic format and use, simple examples 3.4.15 Files and Advanced Input/Output I. Introduction to Sequential Files concepts: storage and buffers II. File Types concepts: basic format of FILE declarations, simple examples III. File Input concepts: reset and get procedures, basic format and simple examples IV. File Output concepts: rewrite and put procedures, basic format and simple examples V. Text Piles concepts: readln and writeln procedures, eoln function, standard files input and output 27 4. THE DESIGN OF AN INDIVIDUAL PLATO LESSON Once the concepts to be contained in a particular lesson have been described, as they have been in the previous section, the implementation of that lesson on PLATO can begin. There are many factors which contribute to good lesson development, but without a doubt, the most significant factor is the experience of the author. The capabilities of a PLATO lesson are restricted only by the author's ambition and ability to use those capabilities to their fullest. What follows is a discussion of some of the ingredients that make up a good PLATO lesson, based on this author's own experience. 4.1 The NEXT Syndrome The most difficult tendency to avoid when implementing a lesson on PLATO is what may be called "the NEXT syndrome." This is the tendency to treat this magnificent educational tool as a "page-turner," that is, to display a page of text for the student to read, have him press NEXT when finished, display another page of text, press NEXT, display another page, NEXT, display, NEXT, etc. , etc. Even this author found himself falling into this rut, and it requires a constant effort to avoid. In addition to being a waste of resources, this syndrome quickly becomes tedious and boring to the student, and hence ineffective as a teaching method. 28 There are many ways to keep the student alert, the simplest being to occasionally change the "page-turning" key to some- thing else, say DATA. 4. 2 Questions, Questions, Questions The best way, however, to avoid the NEXT syndrome is to ask questions throughout the lesson. These questions pro- vide a means by which the student and the lesson can verify that the desired concepts are being absorbed. Since they require a "non-automatic" response, as opposed to the auto- matic response of pressing NEXT at the end of a page, ques- tions keep the student alert and require a constant mental review of the material. Trivial or obvious questions, with simple yes and no answers, are actually excellent means of keeping the student awake. Anything that requries a "non- automatic" response, and hence interaction, is useful in this regard. A good example of this is asking the student to pick a number or name which will be used in the explanation of some concept. An important consideration when asking a question is to provide adequate help to the student. A common complaint about existing lessons concerns a student's inability to pro- ceed past a question the student is unable to answer. There- fore, all questions should have mechanisms to prevent this. A common practice is to give increasingly obvious hints with each wrong answer, making sure the last hint is the correct answer. Another possibility is the use of the ANS key to 29 automatically provide the correct answer. Attempts should be made to accept every possible correct answer, and to provide specific help for anticipated wrong answers. The extent to which these capabilities are used should depend on the particular question. If the question involves an impor- tant concept, a complex judging procedure might be appropriate, while other questions might give the correct answer after one attempt. 4 . 3 Animation Another powerful tool is the technique of animation, that of making a concept "come to life" through effective use of PLATO's graphics capability. Because of the incredibly fast response and plotting time, pictures can appear to move by erasing and replotting in quick succession. A car can "drive" across the screen, a computer can "spin" its tape drives, and a number can "hop" its way through calculations. Interaction and animation can be combined by allowing the student to control the movements on the screen. Naturally, it is up to the author to incorporate these techniques into an effective lesson. As usual, this requires experience. 4 . 4 Full Screen Erases A consideration not as obvious as most involves the use of full screen erases. It has been casually observed by this author that the sudden unexpected erasure of the entire PLATO screen (a full screen erase) has a slightly disconcerting 30 effect upon many students. The lesson author knows exactly when these erasures will occur, and hence is unaware of their unexpected effect. A large number of full screen erases, even if expected, tend to make the lesson material seem dis- jointed. A greater sense of continuity is achieved if parts of the display are allowed to remain while doing a line by line erasure and redisplay of new material. Full screen erasures should not be avoided when necessary, however. One way of reducing their unexpectedness is to display some indication that the screen is about to be erased. This author uses the standard of displaying the message "Press NEXT" in the lower right corner immediately before a full screen erase. This convention is not specifically explained to the student, but should become readily apparent. 4.5 Utilities Many techniques used in PLATO lessons depend upon the taste and experience of the individual author. This author prefers to use a lot of pointers and arrows to direct the student's attention, while others may prefer to use flashing boxes. An important concept for any author is the use of utilities: generalized segments of code which may be used, via the -do- command, in many parts of the same lesson. For example, this author uses such utilities to draw and erase pointers, generate ellipses, and draw title blocks. These utilities can save disk space and simplify lesson writing immensely. 31 5. THE IMPLEMENTATION OF THE PASCAL SERIES The implementation of the PASCAL Series was begun as an individual project by this author, in order to gain the experience needed for this paper and to develop the standards and conventions for the rest of the series. PLATO lessons pascarith (Arithmetic) , pascprog (Program Structure and Execution) , and pascif (IF Statements) have been essen- tially completed, pending final review and evaluation. Lesson pascintro provides an index and explanation of the lessons in the PASCAL Series. Lesson pascloop (Looping — WHILE and REPEAT Statements) is nearing completion, and lessons pasccase (The CASE Statement) and pascfor (Looping — the FOR Statement) have just been started by two volunteer authors. The basic table of contents and topic structure, along with movement conventions, were taken from the lesson skeleton in lesson cscode. This structure provides a consistent and easy-to-use basis for any computer science lesson. Various other elements, such as a standard title blcok, an initial help page describing the movement conventions , and a term chars to reload the character set, have been added by this author. A sample lesson skeleton for the PASCAL lessons has been placed in pascintro, with appropriate explanations, and can be copied to provide a starting point for the development of future PASCAL lessons. Any author intending to implement 32 a PASCAL lesson should read this paper, along with the ex- planations and suggestions given in lessons csauthors, cslibrary, cscode, and style. It has been claimed that the weakest point in many CAI projects is simply identifying who will make a good author [1] . Unfortunately, the lack of experienced authors makes the luxury of being able to pick and choose nearly impossible. In order to maintain a high standard of lesson material, close supervision should be given all inexperienced authors, to prevent poorly written lessons from the start. A factor of equal importance is the careful development of the lesson sequence as a whole, which this paper has attempted to illustrate. 33 REFERENCES 1. Hickey, Albert E. Research Guidelines for Computer - Assisted Instruction . Newburyport: A. E. Hickey Associates, 1974. 2. Hicks, Bruce L. and S. Hunka. The Teacher and the Computer . Philadelphia: Saunders, 1972. 3. Jensen, Kathleen and Niklaus Wirth. PASCAL User Manual and Report . New York: Springer-Verlag , 1975. 4. Nievergelt, J. et al. ACSES : The Automated Computer Science Education at the University of Illinois . University of Illinois, Department of Computer Science, Report no. 76-810, August, 1976. HBLIOGRAPHIC DATA HEET 1. Report No. UIUCDCS-R-77-909 2. 3. Recipient's Accession No. , Title and Subt itle THE PASCAL SERIES: A PLATO LESSON SEQUENCE 5. Report Date December 1977 6. . Author(s) Timothy Jon Thompson 8. Performing Organization Rept. No. . Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. 2. Sponsoring Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 13. Type of Report & Period Covered M. S. Thesis 14. 5. Supplementary Notes 6. Abstracts The overall design of a PLATO lesson sequence is discussed in general, and in particular that of the PASCAL Series, a sequence intended for introductory computer science courses. The topics and concepts to be covered in each lesson of the sequence are listed. Also, some general considerations in writing PLATO lessons are discussed, as applicable to this sequence. 17. Key Words and Document Analysis. 17o. Descriptors PLATO PASCAL PLATO lessons 17b. Identifiers/Open-Ended Terms Computer-assisted instruction lesson design lessons sequence design 17c. COSATI Field/Group 18. Availability Statement 19. Security Class (This Report) UNCLASSIFIED 21. No. of Pages 36 20. Security Class (This Page UNCLASSIFIED 22. Price FORM NTIS-35 ( 10-70) USCOMM-DC 40329-P7t FFB 1 5 1978 AUi i m m4