fix sccsid to use keywords and modern initialization syntax

[unix-history] / usr / src / usr.bin / learn / USD.doc / p2

.\"	@(#)p2	6.1 (Berkeley) %G%
.\"
.NH
Educational Assumptions and Design.
.PP
First, the way to teach people how to do something
is to have them do it.  Scripts should
not contain long pieces of explanation; they should
instead frequently ask the student to do some task.
So teaching is always by example: the typical
script fragment shows a small example of some
technique and then asks the
user to either repeat that example or
produce a variation on it.
All are intended to be easy enough that most students will get most questions
right, reinforcing the desired behavior.
.PP
Most lessons fall into one of three types.
The simplest presents a lesson and asks for a yes or no
answer to a question.
The student is given a chance to experiment before replying.
The script checks for the correct reply.
Problems of this form are sparingly used.
.PP
The second type asks for a word or number as an answer.
For example a lesson on files might say
.IP
.I
How many files are there in the current directory?
Type ``answer N'', where N is the number of files.
.R
.LP
The student is expected to respond (perhaps after experimenting) with
.LP
.I
	answer 17
.R
.LP
or whatever.
Surprisingly often, however, the idea of a substitutable argument
(i.e., replacing
.I
N
.R
by
17)
is difficult for non-programmer students,
so the first few such lessons need real care.
.PP
The third type of lesson is open-ended \(em
a task is set for the student,
appropriate parts of the input or output are monitored,
and the student types 
.ul
ready
when the task is done.
Figure 1 shows a sample dialog that illustrates the last of these, using two
lessons about the
.I cat
(concatenate, i.e., print) command taken
from early in the script that teaches
file handling.
Most
.I learn
lessons are of this form.
.KF
.TS
box, center;
c.
T{
Figure 1:  Sample dialog from basic files script
.sp
(Student responses
in italics; `$' is the prompt)
.nf
.sp
A file can be printed on your terminal
by using the "cat" command.  Just say
"cat file" where "file" is the file name.
For example, there is a file named
"food" in this directory.  List it
by saying "cat food"; then type "ready".
$ \fIcat food\fR
  this is the file
  named food.
$ \fIready\fR

Good.  Lesson 3.3a (1)

Of course, you can print any file with "cat".
In particular, it is common to first use
"ls" to find the name of a file and then "cat"
to print it.  Note the difference between
"ls", which tells you the name of the file,
and "cat", which tells you the contents.
One file in the current directory is named for
a President.  Print the file, then type "ready".
$ \fIcat President\fR
cat: can't open President
$ \fIready\fR

Sorry, that's not right.  Do you want to try again? \fIyes\fR
Try the problem again.
$ \fIls\fR
\&.ocopy
X1
roosevelt
$ \fIcat roosevelt\fR
  this file is named roosevelt
  and contains three lines of
  text.
$ \fIready\fR

Good.  Lesson 3.3b (0)

The "cat" command can also print several files
at once.  In fact, it is named "cat" as an abbreviation
for "concatenate"....
.fi
T}
.TE
.sp
.KE
.PP
After each correct response the computer congratulates
the student and indicates the lesson number that
has just been completed, permitting the student
to restart the script after that lesson.
If the answer is wrong, the student
is offered a chance to repeat the lesson.
The ``speed'' rating of the student (explained in
section 5) is given after the lesson number when the lesson is completed successfully; it is
printed only for the aid of script authors checking
out possible errors in the lessons.
.br
.PP
It is assumed that there is no foolproof way
to determine if the student truly ``understands''
what he or she is doing;
accordingly,
the current
.I
learn
.R
scripts
only measure performance, not comprehension.
If the student can perform a given task, that is deemed to be ``learning.''
.[
skinner teaching 1961
.]
.PP
The main point of using the computer is that what the student
does is checked for correctness immediately.
Unlike many CAI scripts, however, these scripts provide
few facilities for dealing with wrong answers.
In practice, if most of the answers are not right the script is
a failure; the universal solution to student error is to provide
a new, easier script.
Anticipating possible wrong answers is an endless job, and it is really
easier as well as better to provide a simpler script.
.PP
Along with this goes the assumption that
anything can be taught to anybody if it can
be broken into sufficiently small pieces.  Anything
not absorbed in a single chunk is just subdivided.
.PP
To avoid boring the faster students,
however,
an effort is made in the files and editor scripts to provide
three tracks of different difficulty.
The fastest sequence of lessons
is aimed at roughly the bulk and speed of a typical tutorial
manual and should be adequate for review and for
well-prepared students.
The next track is intended for most users and is roughly
twice as long.  Typically, for example, the fast track
might present an idea and ask for a variation on the
example shown; the normal track will first
ask the student to repeat the example that was shown
before attempting a variation.
The third and slowest track, which is often
three or four times the length of the fast track,
is intended to be adequate for anyone.
(The lessons of Figure 1 are from the third track.)
The multiple tracks also mean that a student repeating a course is unlikely
to hit the same series of lessons; this makes it profitable for a shaky
user to back up and try again, and many students have done so.
.PP
The tracks are not completely distinct, however.
Depending on the number of correct answers the student has given for the
last few lessons, the program may switch tracks.
The driver is actually capable of following
an arbitrary directed graph of lesson sequences, as discussed in section 5.
Some more structured arrangement, however, is used in all current scripts
to aid the script writer in organizing the material into lessons.
It is sufficiently difficult
to write lessons
that the three-track theory
is not followed very closely
except in
the files and editor scripts.
Accordingly,
in some cases, the fast track is produced merely by skipping
lessons from the slower track.
In others, there is essentially only one track.
.PP
The main reason for using the
.I
learn
.R
program rather than
simply writing the same material as a workbook
is not the selection of tracks, but
actual hands-on experience.
Learning by doing
is much more effective
than pencil and paper exercises.
.PP
.I Learn
also provides a mechanical check on performance.
The first version in fact would not let
the student proceed unless it
received correct answers to the questions
it set and it would not tell a student the right answer.
This somewhat Draconian approach has been moderated
in version 2.
Lessons are sometimes badly worded or even just plain wrong;
in such cases,
the student has no recourse.
But if a student is simply unable to complete one lesson,
that should not prevent access to the rest.
Accordingly, the current version of
.I learn
allows the student to skip
a lesson that he cannot pass;
a ``no'' answer to the ``Do you want to try again?''
question in Figure 1 will pass to the next lesson.
It is still true that 
.I learn
will not tell the student the right answer.
.PP
Of course, there are valid objections to the
assumptions above.
In particular, some students may object to
not understanding
what they are doing;
and the procedure of smashing everything into small pieces may provoke
the retort ``you can't cross a ditch in two jumps.''
Since writing CAI scripts is considerably
more tedious than ordinary manuals, however, it is safe
to assume that there will always be alternatives to the
scripts as a way of learning.
In fact, for a reference manual of 3 or 4 pages it would
not be surprising to have a tutorial manual of 20 pages
and a (multi-track) script of 100 pages.  Thus the reference manual
will exist long before the scripts.