Forum archive 2000-2006

Gavin LaRose - webwork uses/san diego discuss topic

Gavin LaRose - webwork uses/san diego discuss topic

by Arnold Pizer -
Number of replies: 0
inactiveTopicwebwork uses/san diego discuss topic topic started 12/20/2001; 1:31:03 PM
last post 1/4/2002; 4:05:27 PM
userGavin LaRose - webwork uses/san diego discuss topic  blueArrow
12/20/2001; 1:31:03 PM (reads: 951, responses: 1)
Hi all,

I'd like to propose a discussion topic for any in San Diego and interested in it. I believe that Indiana is alrady doing some of what I'm suggesting below. I believe that the following is also quite long enough. My apologies for its length.

As background, we are at Michigan using WeBWorK for on-line homework, and are also doing on-line gateway testing and developing on-line diagnostic tests and associated tutorial materials. Each of these demands a somewhat different feature sets of an on-line assessment system. The requirements for an on-line homework system are reasonably well summarized by WeBWorK's capabilities. For an on-line gateway testing system, we want the ability to generate a random test every time a student logs in to take it, to have an easy mechanism to include proctored testing mode, and it is almost essential to be able to easily recover the test and answers submitted by a student on every test login. For a diagnostic system, we need to be able to use the results of a testing instance to route students to other, possibly static, materials.

These are similar in that they all need some type of authentication, all require some capability to store data of varying types about the students' success at the test or homework, and all require some mechanism by which to grade mathematical problems.

They differ, however, in the data that needs to be stored, how the problems in the "assignments" are generated and displayed, and how the student should be "routed" after completing the assignment. (For gateway testing, grading the test completes the testing instance, while for homework it returns the student to the point of being able to continue working on the problem or problem set, and for a diagnostic/tutorial system it sends the student to a pre-programmed module of some sort.)

It seems that the logical (and, probably, already considered or in progress) step is to make the different parts of WeBWorK into separate systems which can talk to one another, thereby allowing the use of one or the other with different front ends that do different things with the data.

Thanks to anyone who has bothered to read all the way down to here. I hope to see you all in San Diego.

Happy Holidays,

<| Post or View Comments |>

userMichael Gage - Re: webwork uses/san diego discuss topic  blueArrow
1/4/2002; 4:05:27 PM (reads: 1221, responses: 0)
Hi Gavin,

I agree that separating the components of WeBWorK is an important next step in its development. Here is what I have done for separating out the component that renders the problem (and also grades it). I have set this component up as a stand alone server which responds to an XML-RPC request. The request sends the essential data for the problem and the response is an XML form, the majority of which is the HTML text for presenting the problem, plus information on the correctness of the answers submitted (if any), the grade on the problem, and the current problem_state.

Using XML, over HTTP protocol is not the fastest way to communicate between subprograms, but it is very flexible, and demonstrates that the programs really are operating independently. If speed becomes important the communication protocol could be modified to speed things up.

Actually I have a couple of versions of the server -- some work through apache, some are stand alone, some cache certain kinds of data, etc. They are all in alpha stages and the communication protocol is not fixed in stone. There is also still alot of work to do in testing which of the server designs is most useful in terms of flexibility and speed.

I have also built several client front ends for this server. One of them is illustrated by the library problem page: which also uses a few other routines provided by the server.

This is an HTML client for the server. To include access to one of the library problems in the webpage you could write:

<A href="http:\//" TARGET="problem_page">AlgebraProblem</a>

If the browser supports includes, you could even include the problem in the webpage itself.

I've also designed a plug-in tool for Radio Userland which runs on PC's and MAC's and has the most flexible interface so far for dealing with the server. It is also alpha software, but let me know if you want a copy. (You'll need to download Radio Userland, which is currently free.) I haven't yet had time to build clients for other platforms and languages, but once one of these clients is properly designed, the rest should not be too hard.

I'll post more details of the current version of the XML interface in a separate posting to the discussion bulletin board.

See you in San Diego.

-- Mike

<| Post or View Comments |>