[LON-CAPA-dev] Suggested Terminology Change
Fri, 22 Nov 2002 15:51:35 -0500
As I've been writing the nav maps, I've always been bothered by the
terminology of the "multi-part problems", and the corresponding
dichotomy between "parts" and "problems". As I've been writing
lonquickgrades the problem has come into sharp focus.
The distinction between "parts" and "problems" is a real problem when it
comes time to tell the students how they are doing. We'd like to say
"You have 2 problems right out of 6", but what if they have a multipart
problem with 5 parts, 3 of which are correct? Are we going to tell the
students "You have 2.6 problems of 6 correct"? And what exactly does it
mean to total a 3/6 parts correct, a 1/7 parts correct, and a 1/2 parts
correct? Is that really the same as "1.14 problems correct"?
This is especially silly in light of the fact that a part effectively
*is* a problem; it can be independently assigned, gotten correct, wrong,
excused, etc. just as a fully-independent problem can.
I propose that we stop refering to problem "parts", and "multipart
problems", and instead refer to "subproblems" and "multiproblems", where
"multiproblems" are problems that have bundled several "subproblems"
In this case, I can write clearly on the nav maps and the quickgrades
that you have 4/7 "problems" (what we currently call "parts") correct,
with no confusion. The problem with figuring out how to think about a
problem with several partial statuses (one part completed, one part
excused, one part wrong, etc.) goes away.
On the technical end, this requires minor tweaking of some screens to
get the output to match this new terminology. For consistency, it would
probably be good to alias the current problem "part" tag to
"subproblem", so people can use "part" who are used to it and for
backwards compatibility. I am not proposing a massive code change; it is
perfectly acceptable to call them "parts" under the hood and always
refer to "subproblems" on the human interface level. (Interface need not
be equal to implementation... in fact that's usually a *bad* thing.)
The driving motivation of this change is the fact that from a student's
point of view, a "3-part multipart problem" and "3 problems" have no
real distinction. (Even the fact that the three parts appear on one
screen can be simulated with 3 seperate problems bound together with a
.page.) Maintaining the distinction will only confuse the student.
I am not necessarily proposing this go into .6, though it would not