Shortanswer question development

Following discussion about regular expressions question types in Moodle Tim Hunt suggested a development of short answer question that allows the teacher to use a number of rules with different types (matches string, not matches string, contains the words, matches regexp an so on). The idea is good, though it needs further discussion.

Abilities

Initial list of types for rules

Feel free to place suggestions there:

• Exact match string
• Partial match string (can be implemented via next option)
• Contains the all/one/several substrings
• Exact match regular expression
• Partial match regular expression

Logical operators

Many teachers would want to combine several conditions in one answer condition using logical operators (for example contains some words and not contains another). We definitely should allow NOT and AND operators. The OR can be omitted as several blanks effectively work as OR (this would simplify interface greatly).

Interface

The actual problem is to get clever interface there, so the question creation would not be too cumbersome in simple cases.

Considering using logical operation to group complex expressions in one answer I think that using simple formal language (as in embedded question now) is better alternative than having many fields for each graded subasnwers.--Oleg Sychev 10:02, 12 November 2008 (CST)

I think that a text analysis shortanswer question type should be a new question type because any additional syntax than the * character will interfere potentially with already created shortanswer questions.

Moodle need to be upward compatible.

We could even create more than one text analysis shortanswer question type in relation to the code or computer code (regexp, basic ) used to analyse the student responses.

Let the user choose the code ( or text analysis shortanswer question type) that he knows best.

I.e. regexp is the kind of code created to limit the typing in those days where code was enter on a teletype.

Efficient for a computer but not the kind of computer I have in my head...

I cannot use it without a verification program. Pierre Pichet 11:50, 12 November 2008 (CST)

Pierre, I hate incompatibily a lot as you can know already. I thought of kind of system, that will be compatible with most of existing questions (and the rest can be automatically upgraded). I'm not fond of having a lot of question types - even with standard questiontypes adding question dropdown is somewhat crowded. Also, there is nothing exceptional in wanting to use several 'codes' in one question (one to catch right answers, another to catch typical error for example - Joseph Rezeau actually tring to do this with his regexes).

Dropping OR allows us create a very simple interface. We replace text field with textarea, every string in it is a rule (fortunately shortanswer doesn't allows line breaks in answers), the rules in one answer are connected with AND. Each rule starts with short (or full - it may replace the short form automaticaly) form of the rule's type (that can be preceeded by 'NOT' or ! for negation), that ends with delimiter, followed by it's parameters.

The sort of interface that allows user write something like this:

contA:red:green:blue
!cont1:purple:white:black
not regexp:[0-9]

which will means the string which contains all of the words red,green and blue; doesn't contains purple, white or black and numbers too (defined using regexp).

We can keep compatibility in two ways:

1. expect simple string to be of "Exact Match with wildcards" type (that is how it work's now) and start any rule with some rare special character (the character must be escaped if the string still starts with it thought - that is if we can't find a character that absolutely can't be a part of an answer now except line break). This will be more familiar to the user (which can still use old syntax), but may leads to mistakes by omission escaping in rare cases (thought validator can easily catch them most of the time).
2. automaticaly prepend every string with type of the rule for "Exact Match with wildcards" during upgrade. This may caught user by surprise first, but then he'll knows the syntax and won't mistakes just because he didn't know about it.

I think also about dropping wildcard syntax using regex instead (it's not hard to automatically replace \* with * and * with .*). --Oleg Sychev 18:22, 12 November 2008 (CST)

Implementation

The options should be implemented as subclasses of abstract class to make adding new options easier. Does we need to have them as actual plugins (with versions, language packs, installation and so on) or more simple subplugins?

Does we need to store all options (with logical operators) with given subanswer as a whole, or create a new table with one entry per options? Right now I'm against new tables.--Oleg Sychev 10:02, 12 November 2008 (CST)