Development: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)

You must type much in shortanswer questions anyway, and the less you'll get distracted by mouse (i.e. dropdowns) the better. Wiki is an example, that people easily adopts simple pseudocodes. We may get some buttons to simplify editing for newbies later (as in MediaWiki now), of someone will help me with it thought.

Right now I think about two possibilities:

1. An 'answer' field will remain, but now it is used mainly to enter the correct answer in user-readable form (and backward compatibility), it may be empty; if it isnt't empty and rules is empty it will be matching against students response just as it is now, however there are better options. The 'rules' textarea field will be added to describe rules for matching questions with types mentioned above using simple pseudocode. If the both rules and answer field are filled, the answer must match with rules. That'll costs us a new field in table, and (probably) some problems with backups and import/export compatibility, which is an area in Moodle where I'm not competent enought - but I think it'll be quite easy to any experieced Moodle developer to help me there.
2. We may just replace 'answer' field with textarea, leaving first string in it for an answer (as it is now and for display to the user) and other for rules. However this'll create some strange things with an empty first strings, where it may be easy to make an error (thought validator will find it).

I would like you opinion about what path to take.

Syntax

The place for syntax proposals.

Compatibility issues

Singular shortanswer questions compatibility

Most existing questions must work as before, and the rest must be automatically upgraded, it's clear enough. Well, with interface proposed above there would be no problems at all there.

Embedded answers (close), numerical, calculated compatibility issues

Pierre, you could actually help me there, as you knows embedded answers question type well.

Oleg take a look at the code using the 
http://xref.moodle.org/nav.html?index.html
You will see that calculated depends on numerical that depends on short answer.
Cloze create numerical and short answer.
You will then conclude that you cannot easily alter the short answer question type.
The solution is to create a specific variant of short answer.
Test it on contrib and propose it as a plug-in.
History will tell us if your new extended short answer will render the short answer obsolete...
Pierre Pichet 12:51, 13 November 2008 (CST)

Pierre - I look on numerical question and found nothing that'll create compatibility issues if we choose first alternative in the interface section (do you read it?). The numerical question overloads all functions that are intented to alteration (and calls parent function only once at all, but we need not to change it). Just a new field which opens new possibilies when filled, but leave things to the way they were if blank rarely hurts anything.

This is not my personal itch. The idea for this change was proposed by Tim. I can help him in developing shortanswer question to more generic means, but I have neither intention nor resources to create and support another similar generic question type - for an additional type I'm content with our preg question very well.

Now, when we discuss things on more specific basis, can I delete our discussion above? It pretty overloads the page and hardly contains anything useful related to the current state of things. --Oleg Sychev 14:33, 13 November 2008 (CST)

Rebuilt the page as you need it following MDL-17229.
Can I call this an happy ending? Pierre Pichet 20:57, 13 November 2008 (CST)

Pierre, you misunderstand the goals of MDL-17229. MDL-17229 is for refactoring, not for development. If fixed, it'll create a more close relationship between numerical and shortanswer questions (reducing code duplication and so maintenance work), (it won't create any new user-visible functionality). This page is for development. I'll create an issue for it on the tracker when I have more detailed plan. Right now Tim want it to be there. I'm unsure what you means by 'ending'... --Oleg Sychev 04:12, 14 November 2008 (CST)

First of all could you please describe me connection between close and shortanswer questions:

1. Which parts of code from shortanswer directory close question actually uses?
2. Are subquestion descriptions reconstructed when editing question, or they are stored in DB just as the user enters them?
3. How shortanswer question parser handles line breaks in answers (either simple line breaks, or

   that HTMLArea generates on pressing enter)?

4. How shortanswer question parser handles *(wildcard) and : (answer's separator) if they must be a part of an answer?

Right now I can't see an easy way to get access from close question to the new functionality of shortanswer. You may implement something about this later thought.

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. They add many problems with moving questions to another category and so on. --Oleg Sychev 10:02, 12 November 2008 (CST)