twk

twk is a program designed to aid the production and grading of numerical on-line quizzes. A URL of:

http://www.physics.csbsju.edu/cgi-bin/twk/path/file.html

launches program which reads the (mostly) HTML file:

/var/www/httpd/twk/path/file.html

file.html would typically begin:

*set show=1
*echo
<title>My Title</title>
<h2>
etc...

Lines that start with "*" are not displayed on the browser; instead these are commands for the program to take some actions. Here are a list of these commands:

Commands

ECHO
Enables echo-to-browser of non-command lines

NOECHO
Disables echo-to-browser of non-command lines

SET vname1=value1    vname2=value2 etc.
Assigns values to variables. Variables that did not previously exist are created.

LET vname=expression
Evaluates the expression and puts result in vname. Variables that did not previously exist are created.

USE variable-list
The list of variables in variable-list are created with value zero. The "variable" F(X) is a special case: USE F(X) initializes F(X) with an expression previously supplied by the common gateway interface (CGI). Similarly USE FUNCTn compiles the string FUNCTn as the expression for F(X).

WRITE expression format
Evaluates the expression and prints-to-browser the result using the fortran format format. The program uses the format the guess if expression is intended to be real, integer or byte (ascii) data. Note the extension of fortran formats to include "web.sig" which is similar to fortran g format except the result is web friendly: i.e., 6.02 × 1023 rather than 0.602E24.

LOG expression format
Evaluates the expression and prints-to-access_log the result using the fortran format format. The program uses the format to guess if expression is intended to be real, integer or byte (ascii) data. (web-format is not available.) Note that a variety of POSTed form data is automatically written to the access_log

SHOW
Prints-to-browser a variety of information about the state of the program. This is mostly for debugging.

HELP
Prints-to-browser a summary of commands. This is mostly for debugging.

IF (condition) THEN
The logical expression: condition is evaluated. If the expression is .true. the block of lines to the corresponding ENDIF, ELSEIF, or ELSE are read; if the expression is .false. the block of lines are not read. The condition must consists of atoms which are simple comparisons using exactly one of .eq. .ne. gt. .ge. lt. .le.. For example

b**2.gt.4*a*c .

These atoms may be connected with boolean binary operations: .AND. and .OR. and the boolean function: .NOT.(). For example:

((x.gt.4).and.(x.lt.10)).or..not.(answer(1).eq.116.or.answer(1).eq.84)

IFELSE (condition) THEN

ELSE

ENDIF
See above.

HIDE vname format
Writes-to-browser

<input type=hidden name=vname value=XXX>

This is used to send values to following pages via CGI.

STOP
Discontinue output-to-browser and process no additional lines of the file.

The first line of our example:

*set show=1

requires an explanation. show is a variable that controls the display of calculated results. The default (show=0) disables all calculated output (e.g., the results of WRITE).

Example A

Click here to see a command-listing for example A; click here to see the results. I you hit Netscape's "Reload" key, the numbers used in the problem will change. Note that the list of "random" numbers used is determined by the seed, which, in this example, is set by the time-of-use and process id. One could just as easily make the seed determined by user data like a social security number.

Now this problem needs to be graded. If you looked closely at the command-listing or the document source, you should have noticed the FORM:

<form METHOD="POST" action="/cgi-bin/twk/examples/A.jr">

This statement says that the form inputs will be POSTed to the program twk which will use the file:

/var/www/httpd/twk/examples/A.jr

to do the grading.

Click here to see a command-listing for A.jr; click the "Grade Me" button on the above form to see how the quiz is graded. The raw data is automatically logged to access_log, I've appended the total graded score and the correct answer to that log. Click here to see the tail of the access_log. For all the below examples you can return here to see the log produced.

Notice that user-entered data makes grading difficult. Judgment is required, e.g., is the entered number close enough to count? What happens if nothing is entered or simple character data (e.g., "five gs") is entered. Try it and see! With character data the variable ends up with a value equal to the length of the string. Thus "five gs" would produce g=7 (however you are disallowed from entering that many characters).

Example B

Click here to see some options for restricting user data entry. click here to see the results. You may want to hit the "Grade Me" button to see the results, look at B.jr file that grades the problem, and view the log


Example C

Because of the problems of user entered numbers, twk was designed to handle multiple guess questions, including whole tests of multiple guess questions.

Here is an example. Note that this is a straight HTML file; twk is doing no rewriting, so you can View the Document Source in Netscpae. Here is a summary statement as to how the SHOW variable works:

SHOW - amount of help displayed; 0:nothing 1:writes 2:wrong 3:wrong+help1
       4:wrong+help 5:wrong+notsure 6:wrong+notsure+help1  
       7:wrong+notsure+help 8:all 9:all+help1 10:all+help
Questions with character answers (i.e., multiple guess questions) should be named as numbers in the range 1-1024. The characters selected in the form will be compared to answers in the .jr file, the results tabulated in variables like NRIGHT, and finally logged in the access_log. Take a look at the access_log. See how the results are summarized in a line where a lower case letter indicates a correct answer and an uppercase letter indicates a wrong answer. The "not sures" are indicated below the right/WRONG line. Note the use of the underscore variables (e.g., 66_ ) as "not sure" flags. If you were taking a survey rather than grading answers you would record a non-occurring correct answer (say X) in the .jr file so everything would be wrong and use SHOW to turn off displayed grading (e.g., SHOW=1). Non-responses would be tabulated in the variable NBLANK.

The structure of the .jr file is similar to the previous examples except that non-command lines not subject to echo are to have the form:

question_number correct_answer
line 1 of "help"
additional lines of help

question_number correct_answer
line 1 of "help"
additional lines of help

etc...

the line between questions must be totally blank: no white space like tab or space. While the function ANSWER() is filled in as soon as you hit the Submit button, the functions NQUEST, NRIGHT, NBLANK, and RIGHT are updated as each line of the answer from the .jr file is read. Thus you can insert code to evaluate question:

1 A
Stupid: A is obviously the right answer!

*if (right.eq.1) then
*elseif (nblank.gt.0) then
*echo
why did you leave this equation blank?
*noecho
*let nblank=0
*else
*echo
why did you answer
*write answer(1) 'a1,1H?'
clearly A is the right answer!
*noecho
*endif
2 B
another easy question

Example D

I've described how you can make the numbers in a question vary from hit to hit. You may also want to vary the entire question. Alternative questions have names like: 1_, 2_, ..., 1024_. twk can choose question 1 or 1_ at random. (Note that in Example C, I used those alternative questions for the "not sure" button.)

Here is the .html file; Here is what it looks like; Here is the .jr file; you may want to view the log.

Note that instead of using the intrinsic grading options encoded by SHOW you can provide you own grading text. The .jr program can know each "random" question selection if it is passed the initial value of SEED.

Example E

Random selection of one question between more than two alternatives is also quite possible: just use a different question number for each alternative. Since you probably want to show the user sequential question numbers, there will be a disconnect between the question number as known by the user and the question number used by jr. Again you can either use the intrinsic grading options in SHOW (e.g., the total NRIGHT) or provide your own grading dialog.

Here is the .html file; Here is what it looks like; Here is the .jr file which uses its own grading dialog rather than SHOW; you may want to view the log.


Example F

Our multiple guess questions (e.g., in Example B) are constructed with varying input (e.g., planet mass) and varying options which are adjusted according to the inputs. In this way we hope to test if students know how to develop and apply a formula for the answer in terms of the inputs. In physics we try to stress this ability to work formally with "letters" rather than concretely with "numbers" (e.g., dealing generally with a mass of "m" rather than a specific mass of 5 kg). Since science is exactly seeing the general case in specific cases, I believe that learning to think in "letters" is a key outcome for science classes. So why not directly test if students know the formula? The response that students prefer to deal with numbers and if they can solve many particular cases they really know the general case is, of course, incorrect and not to the point. (This argument can be dressed up to say that problems with "letters" are developmentally inappropriate.) We, of course, want to avoid the false generality of formula memorization such as that that produces the famous "Three Laws of Electricity" (V=IR, I=V/R, R=V/I) situation. Whatever its pedagogical merits, there are many problems implementing computer formula checking. The "Three Laws of Electricity" are in fact one law, but it takes a fairly sophisticated symbol manipulating program like Mathematica to detect this equivalence. (This is one small example demonstrating the need for human grading.) In addition formula entry involves special skills for encoding formulas in computer-readable form (e.g., what is the exponentiation symbol? Is juxtaposition enough to denote multiplication or is a special symbol required? Is A/B*C, A/(B*C) or (A/B)*C? etc...) The formula-entry options in twk are not up to solving these general problems. The formula-checking option available in twk is basically the reverse of the multiple choice situation: put random values in the entered formula and see if the results match the correct formula. The required twk-readable formula format is basically that of fortran; naive users will certainly fail without help. With these provisos, here is an example: .html file and what it looks like and the grading .jr file.

Example G

This .html file and what it looks like and the grading .jr file are more like a traditional quiz stressing equations rather than numbers.


Security

Instructors commonly accept unvalidated user-supplied data (e.g., student name) on classwork. On special exams at large universities I have seen picture ids used to validate user-supplied data (e.g., is this guy claiming to be "John Smith" a ringer?). The low cost of multiple submission (not even a nickel for the Xerox machine!) can entice students to do what they would not usually do on hardcopy classwork. This is particularly true if grading is instantaneous: students have been taught from computer games that "Game Over" comes at no cost, one just hits the "Try Again" button. If grading is done on-line you will want to publish a policy on the value (if any) of the second draft of submitted quizzes. Clearly with on-line graded multiple-guess quizzes, anyone can score 100 percent simply by repeated submission. The policy may even entice students to submit initial drafts under pseudonyms. It is surprisingly easy to detect this behavior by looking at the access_log, however prevention is quite easy. The solution is to require username/password access to your documents. This can be done simply by putting the twk program in a directory that has an ".htaccess" file like:
AuthUserFile /var/www/httpd/passwords/file
AuthGroupFile /dev/null
AuthName twkUsers
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>
where the file contains the usernames and encrypted passwords. Validated usernames are logged to the access_log. Although hardly fool-proof, that last four digits of the students social security number provides a password that the instructor typically knows prior to the start of class. (In fact agreeing on a username can be more difficult. Here at CSB/SJU students use first initial, middle initial, lastname (e.g., jfkennedy), but students may lack a middle initial and the definition of "lastname", etc. may be culturally dependent.) Since usernames and passwords can be confused and forgotten it is wise to post a help page. Here is an example.