October 2000 || Volume 01, Issue 03

In my last column I continued to look at the relationships in my Online Testing System with a focus on the Test Database and the Student Test Results Database. I also explained the role that Lasso played in the Cache file system which helped to speed up the process of taking a test. In the article to follow I will explain the automatic grading that the system does and I will introduce some Lasso code to show how to get data back from the database.

Test Grading and a Lasso Example

One of the essential features of my Online Testing System is the ability to grade the questions automatically. There are five types of questions that it supports, four of which are graded automatically by the system. The graded question types are: True/False, Single Answer (or often called Multiple Choice), Multiple Answer, and Short Answer. One limitation that makes the Short Answer much harder to use is that it only matches one answer and it must be an exact match.

As expected though, the vast majority of the questions that the faculty have written for the system are Multiple choice. In order to be able to grade these, the system stores the correct answer in the question database. When a student takes a test a record is created in the Online Test Student Database. This record includes the unique test number that refers to the test that the student is taking. By comparing the submitted answer by the student to the correct answer, points are given for the question (0 if wrong, and 100/# of questions by default if correct). For a graphical representation of this take a look at the graphic below.

As I stated at the end of the last paragraph, the system defaults to giving each question equal weight. I also offer the ability for the professor to give a custom weighting to each question. This value will override the system setting and applies to every student who takes the test. Another situation available to the professor is to give a particular student answer any number of points (this can be even more than the system weighting for the question). Essentially this point value overrides the automatic grading point value that the system generates.

Now I will move to focusing on the interfaces offered by the system to a professor. This is particularly important because I have found that different professors use the system in dramatically different ways.

The first interface I will describe is the "Individual Test" interface. It is centered around offering full control of the grading procedure to the professor. The first example link we have is one that very quickly shows what every student did for every question on a particular test. If the students were allowed multiple attempts at a test this link will show their best score.

Along the right column we have the usernames of each of the students who took the test, and along the top we have a number corresponding to the number of the question in the test. If there is a linked number in the corresponding row-column combination than that student missed that question. This page offers access to two different ways to look at more detail from the test. If we click on a username then we get all of the test questions and answers for that one student on the test.

If however we click on the numbers at the top of the columns or any of the row-column link combinations than we are taken to a page that has that one question but for every student who took the test.

The obvious benefit is that I can grade all of the students on the same page for a question that possibly the system didn't grade (if it was an essay) or if I wanted to give everyone more or less points in one fell swoop.

Other professors have a different focus though. They leave all the grading to the system and are actually concerned about grades over a series of tests. For them I added the ability to group tests together, and consider them a sort of best of. An example of this is that one professor uses 5 different versions of a weekly quiz that students must get an 80 or better to move on to the next week's quizzes. He doesn't care which of the 5 they get their 80 or better on, but it just must be one of that group.

In order to implement this I created a field on the test level called Test Order. It uses a simple principle that if two tests are of the same Test Order than they are in a group together. If you get the passing score in one test group than you are allowed to go to the next Test Order/group. In this way a professor can have a number of tests all serve the same purpose and yet still not care which one a student actually gets the grade on.

Along with this is the ability to display the grades in a fashion that only displays one value regardless of the test taken in the report that he gets from the system. This was a custom report I created that has served very well. In a very condensed space it displays the scores for every student on over 120 tests.

Jack's Test report link

Survey interface

As I stated in my first column the initial motivation for this system was to reduce the cost of surveying distance learning students. Since surveying is really the same as testing only we don't track individual users and we don't care what an individual survey says. We are more concerned about the collection of all of the survey results into one nice report.

My system basically breaks these up into two different reports. The first is for the multiple choice questions. The system gives back the number of times a particular answer was given and a percentage of the total number of responses.

The second case which is used quite often in surveys is the essay question. In this case if we click on the link for an essay question for the first report we are given the question followed by all of the responses for that question.

In these two simple reports we are able to convey the information needed for almost every survey analysis and the best part is that it essentially required no more work than the test system. In fact they work seamlessly together, and I have been commended on several occasions on how easy it is to setup and get what a survey organizer wants from it.

Now we will switch gears and look at a little bit more detail with Lasso. Lasso is the glue, or more correctly the brains, in the operation. It provides the critical filtering on the incoming data (from the forms submitted by the user) and takes the result from the databases and makes them useable to the user. It does this in a very simple manner, using a tag-like metaphor that will be familiar to anyone who has hand-coded or even looked at HTML

In the following example I will show the actual code for a database search and some simple conditional code to show different things on the screen.

[inline: search, database="OnlineTestFaculty", 
layout="question_detail", clientusername=var:"username", 
clientpassword=var:"password", -recid=var:"Questionrecid"]

[records]
Question:  
[field: "QuestionQuestion", encodenone]




Question Type:                 [if: field: "QuestionType"=="Multiple"]        One Answer
        True/False
        Multiple Answer
        Short
        Math
        Essay

        [/if]


[/records]
[/inline]

So let's now dissect this on a piece-by-piece basis. The first statement to tackle is the database access or search.

[inline: search, database="OnlineTestFaculty", 
layout="question_detail", clientusername=var:"username", 
clientpassword=var:"password", -recid=var:"Questionrecid", search]

The inline keyword indicates a database action inside the page. This is one of the most powerful things about Lasso. It is very possible to string a number of these together in each page in order to gather data from multiple sources.

The second word, search, indicates the action that is to be performed. The database that this action is acting on is OnlineTest Faculty which is the database that holds all of the questions for each professor. FileMaker Pro uses a system called layouts which are a sort of table in the database which has certain fields in it. A field must be in the table to search on it or to return data from it. In this case the layout that we are searching on is "question_detail".

The next two items, "clientusername" and "clientpassword" are two keywords used by lasso to login into a database that requires a login for access. In this case we have already set the variables "username" and "password", which are used with their respective fields to gain access to the database.

The last item in the inline is a special FileMaker Pro field. It refers to a unique name for a particular record in the database. By keeping track of this number we can make sure that we are updating the same question even if we change every field in the database that corresponds to it.

[records]
....
[/records]

This opening and closing tag pair bear a very close resemblance to HTML. They encompass all the actions that should be repeated for each record that is returned from the database. This makes the code much more compact and useful because we usually want to do the same thing with every record being returned from the database anyway.

[field: "QuestionQuestion", encodenone]

The next important item to describe is the reference that returns data from the database to us. Since we have already indicated the layout/table in the inline above this line simply refers to a field in the database called "QuestionQuestion". This is the question itself and the "encodenone" keyword tells Lasso to display it exactly the same as it is in the database. The reason for this extra precaution is because Lasso usually changes characters that conflict with the set of reserved HTML characters, which is typically a good thing, but in this case we do not want it changed.

   [if: field: "QuestionType"=="Multiple"]
            ....
            [/if]

The last unique thing in this example is the conditional. As in most other computer languages the "if/elseif" plays a pivotal role in delivering dynamic data to the user. In this case we simply have an extension of the previous example to comparing the value of the field "QuestionType" to Multiple. If they match than the code between the if and /if is executed.

So that is it for my first example of Lasso code. Pretty simple eh?

Now I need some help from you. What would you like to see in my next column? I could elaborate more on Lasso or I could explain some more of the problems and solutions with the overall system. Your feedback is welcome and greatly appreciated.

Randy Overbeck - randy@macosjournal.com
Randy's Page - Feedback Form