[LON-CAPA-dev] Suggested Terminology Change

Jeremy Bowers lon-capa-dev@mail.lon-capa.org
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 
upset me.