QZB
design thoughts v.1
(some things from below were rethinked. I leave it here so the
evolution of thought could be seen)
Hi!
As I promised, I prepared some more specifications for the
QuiZ-Browser I plan to write (with the help of other
co-developers). (In fact, its quiz server/client...)
What you find below I started formally, but then it was too
complex to write formally, so I used examples wherever
possible.
(By the nature I am an idea-generator, so it is sometimes hard
to me concentrate on some other type of activity ;-) But I'll
try hard.)
I wish interested people could look into it and tell me where
things could be made better.
I even thought about new protocol. Something like DDTP
(didactic data transfer protocol), which could add security
features to the scene. (You known, test contents are to remain
CLOSED otherwise they will not be tests any more!)
I easily agree, that the project I code-named QZB
(quiz-browser), seem banal and the easiest thing to do!
However, its a most widely used type of software! And most
needed too. (I know, there are lots of ways to it on Mac/Win. I
even imagine some software already exists for the purpose on
Unix. But we are making example open source project and nobody
knows if it just fails in 4 weeks or will be a De-facto standard
two years from now!!! And also this is not usual for OSS
project to start from ground zero.)
After I specified some examples on .qzb file (with data), I
thought I must add some editor to help those teachers who don't
think (like myself) that writing text files is great idea.
The syntax of the .qzb file is far from final. Probably I
should made it XML or SGML and use some editor for its
creation. However, I am not closely familiar with these and I
think it will not be a problem to add this feature in the
future.
I plan all coding to be done with, as I think, best language in
this case - Perl, and Perl/Tk for the graphical interface.
As an initiator, I will be in charge of development process and
make final decisions. (this way we avoid unnecessary disputes.)
I do not give any release dates this early, but later we will
probably add some synchronization.
Please, also keep in mind that most (if not all) of us have
other duties and hobbies, so our pace will be not so
predictable.
ANY IDEAS AND HELP-OFFERS (WITH EXPLICIT MENTIONING OF WHAT
PART YOU CAN HELP TO IMPLEMENT) ARE WELCOME!
I myself will try server-side and Perl/Tk interface first. (I
need to learn Tk in the process, BTW)
Now I will wait for your response and think it over again
before actual code appear.
(Some parts can be done already. For example, I will be glad
for the example how to insert different widgets into text-flow
in Perl/Tk... I have seen the 'widget' progie examples, but
can't figure out how to receive values back when user fills
them).
Another problem is where to keep the code online. I don't have
any Unix ox on the net, so I can't organize CVS (even if I new
how I can do it ;-) - I am familiar only with rcs).
So, ./configure is something I am not great at... (if st all).
I am familiar with RPM-packaging, so, it will be no problem for
me to create one.
Please, look if I something is missing from my specification.
(I am too old to be ruthless hacker. Only 5 years ago I could
just do it myself, but now its a lot more fun to do it together
and put GPL on it.)
(If you write to me privately on the topic, add QZB to the
Subject - this way I will not miss. If you have something worth
public to hear, I ask Douglas if we can use seul-edu. QZB sign
will help too.)
Hope to hear from you! Thank you for your attention!
Sincerely yours,
Roman A. Suzi
-- Petrozavodsk -- Karelia -- Russia --
-- powered by Linux RedHat 5.1 --
------------- Specification / README /TODO ---------------------
(code name = qzb)
Description
Description
The program is intended to be used as a
trainer/quiz/exam program, specializing on languages. It can be
used as a browser of the didactic material, containing set of
problems students are expected to solve or train on. Program
can be run in different modes and with different front-ends. To
facilitate usage of the program on client computers, CGI is
provided as well.
Platform
Server-side:
UNIX/Linux/Perl/web-server
Client-side:
UNIX/Linux/Perl/Tk, ncurses, or anything with decent WWW
browser via CGI.
Copying
Author
Roman A.Suzi (the initiator)
Where to get?
Extended description (for co-developers)
( == qzb == QuizBrowser )
The basic idea of the program is quite simple: it must
be able to read problem set file specified and provide students
with exercises from the file via one of the front-ends:
ncurses-based, Perk/Tk (X)-based and web-based.
Accordingly, we have different parts (* - not in the first
release):
qzb
qzb.text
qzb.X
qzb.cgi
* qzb.ed
* qzb2ps
* qzb2latex
The three client parts run core part -- qzb -- to get the
individual problem from the specified problem set file:
sample_problems/*.qzb
In this respect, qzb acts like well-known 'fortune' program
with the exception that qzb is provided with some additional
keys to arrange exercises in desirable manner and some special
markup is used for additional information.
As I see, these command-line switches of qzb are:
-s #, --seed # -- random seed to be used (it is needed
so different instances of training
processes will be consistent)
-t #, --req # -- task request number
-r, --rnd -- retrieve random task which have not
occurred in the instance (requires
--seed)
-f -- file with problem set
-o -- output file (or standard if missing)
Client-side have no switches, only qzb file specified.
What it looks like?
As this program is not very complicated, it is appropriate to
provide some informal description (a scenario) of what users
will see.
First of all, a teacher prepares his own problem set file or
chooses one of sample files. The teacher must have rw access to
appropriate qzb directory or make his directory visible to
special qzb user. (It is needed for task set security reasons).
Students run a qzb (in one of the front-end variants) and choose
which course they want to work, or the tutor prestarts programs
for the exam.
In case of www-frontend, it will look like going to some
web-page with optional password. Web-interface course
consistence is controlled by hidden values in the tag.
All other information is provided in .qzb file.
Now what each student will see at the screen. First of all,
there will be some a (customized by a teacher) instruction,
which is telling how to work with the qzb. Then student starts
to work with the material.
According to the data in .qzb file, the student will be faced
with a series of 'cards'. Each card will contain a problem,
which a student will be able to solve, inserting some text in
the places of special icons with question marks OR choosing
some values from multiple-choice widgets. There could be
several places on one card, where student choice must be done.
A student make through all the cards and gets a screen, which
prints his scoring and/or exam results.
Now, lets look into more details of the process.
First of all, there could be several modes in which cards are
presented:
TM. Training mode. In this mode we tell our student he had
some errors on the card, so
TM.1. he must correct wrong places by continuing on
the same card
TM.2. right answers are presented to him and he proceeds
to the next card
CM. Control mode. In this mode we don't show a student
his errors after each card, but give him detailed
report later, so he can analyze his errors.
*AM. Adaptive mode. It is like TM or CM mode, but the sequence
of cards depends on the answers, given by the student.
EM. Exam mode. It is like CM, but we aren't obliged to give out
detailed error information
EM.1. We show him the topics and number of errors he did in
each topic
EM.2. We just tell the student his score/exam result
The adaptive behavior will not be implemented in the first
release of the program. However, we must have its possibility
in mind by allowing more flexible
task-acquisition/classification scheme in the qzb server-end.
N.B. Client-end of qzb is not processing rightness/wrongness of
student answers. It is essentially a "browser", which is
controlled by the "packets" it acquires from qzb server. This
makes server-end more complicated, and clients more easy to
implement. Client side is identified by the unique seed, which
is also an ID of the client-instance.
Now, to the types of quiz-widgets:
- multiple (closed) choice list
- placeholder to type-in correct answer.
- checkbox
* order-me widget: the student must sort entries in it by
dragging
* build-correspondence: the student is expected to make
correspondence between entries of two lists. The correspondence
doesn't need to be 1:1, it could be 1:M, M:1 or M:M.
(* - these will not be present in release 1.0, just something
we must have in mind, designing the qzb)
(*)The qzb client must be able to show text (letters) as well
as pictures. This will enable to make tests with some unusual
characters.
However, this is not the goal of release 1.0. As we plan to use
full Unicode, many characters (math or transcription signs
among them) will be possible to draw without any problems.
Now, about how a teacher will prepare his own material.
First of all, the material must be plain full Unicode text file
with special convenient to humans mark-up in it.
The possible example of sample file is given below. (It is not
final and needs some polishing and critique! The final format
must be easily extensible and have intuitive structure.)
(Do we need a visual editor to it or internationalise
"command=" things or both???)
--- sample.qzb --------------------------------------------------------
[global]
mode=CM # control mode
timer=20m,"You have $timer to complete this test"
select=5 # only 5 questions from
random=y # shuffle
[1]
title=Instruction
body=
This is sample quiz file. And this is it's start card.
Please read carefully the instructions below to
answer correctly to the questions...
==
[2]
title=Question 1
topic=anatomy
body=
Healthy human being has _1_ legs and _2_ head_3_.
==
[.1]
choice="2","4","6"
right="2"
score=2
[.2]
fill=7 letters
right="1","one"
score=1
[.3]
fill=1 letter
right=""
score=1
[3]
title=Question 2
topic=zoology
timer=3m,"You have $timer to answer this question"
body=
Who lives in the sea (mark checkboxes)?
_1_ salmon
_2_ elephant
_3_ whale
_4_ dolphin
==
[.1]
right=n
score=1
[.2]
right=y,n
score=0
[.3]
right=y
score=1
[.4]
right=y
score=1
...............
[12]
title=Results
body=
Thank you for your answers!
You have earned $score points.
It means, that $result
==
criteria=0,7,"you failed. Sorry..."
criteria=8,10,"you passed! Congratulations!"
# criteria=0%,69%,"you failed. Sorry..."
# criteria=70%,100%,"you passed! Congratulations!"
----------------------------------------------------------------------
This format is raw yet. For example, how to provide more
interactive diagnostics for a student's step/error?
Computer replies must be smart, they are to give additional
information, so the student could think again and fill the form
right way. Probably, the may be specified as additional
property to the "command=" lines of the questions.
* Not to forget:
- Font size and family/type must be in the preferences for the
qzb-clients somehow... I don't want people complain that font
is too large or too small...
- The same with bg/fg colors...
- Have i18n in mind. Anything user meets must be language
independent. Even the last error dialog! (I don't yet know
how to do it right: locales seem to change too fast in Linux...)
*** MY NEW IDEAS on QZB ***
I want QZB to be more flexible in scenarios so the questioning
could be made more complex.
After fiddling with different kinds of scenarios I came to the
conclusion that there is a need to have at least two layers of
control files:
1) question/task database ("content")
2) scenario file which will specify a certain quiz
scenario, using questions from the database
This way quiz questions could be accumulated and exchanged
freely between educators while quiz procedure will be
independent of problem content.
Any ideas for the format of the taskbase file?
What about scenario file?
Example of _task file_ (task000):
---------------------------------------------------------------
Subject: math
Difficulty: 3
Comment: just an example of something simple
1.) How much is 2x2
( ) 1
( ) 2
( ) 3
(x) 4
( ) 5
( ) 22
...
---------------------------------------------------------------
Example of _scenario file_ (mathquiz):
---------------------------------------------------------------
Use: task000
Questions: 5
Order: shuffled
Scoring: "+=1"
Criteria: 0-2 : "2" : "bad!",
3 : "3" : "satisfactory." ,
4 : "4" : "good!",
5 : "5" : "excelent!!!"
Comment: this is an example (grades are 2-5, as in Russia or Sweden)
---------------------------------------------------------------
It will be some markup language, as I see it now. And it need
to be something like sdf (simple document format) or even more
easy for enduser...
*
My definition of flexible was not developer-side flexibility
but ability to organize questions in different ways. Its not so
easy as it leads to enumerating possible types of ordering,
counting scores, changing ordering on the fly (repetition,
etc.), different kinds of statistics at the end...
This is why it is not trivial.
When I am __programming__ a quiz in, say, HyperCard, I can add
as many features as I want because HyperCard is pogrammable and
I can implement almost any type of (closed form)
questionaire-type program...
End-user is not to be faced with "if you want this, do it
youself in language X"...
So, I am going to continue compiling the list of features to
include.
They are from these categories:
- type of question
- question selection and ordering
- reactions to student answers
- collecting and presenting statistics
(Don't forget some teachers do NOT like closed-form quizzes.
They prefer to receive textual answers and analyse them
themselves).
*
For example, for QZB may need
control.html + ques*.html
in order to generate a quiz from them!
control.html will describe the discipline for question order,
grading, repeating, etc. And ques-pages will do what they
are supposed to do.
So, the picture now is:
{control,ques*}.txt ---\
{control,ques*}.html ---> *.qzb ---> http://...cgi-bin/qzb?somefile.qzb...
\ + right answers file
\--> qzb somefile.qzb
\--> xqzb somefile.qzb
with central line being first to implement.