Claude and I have spent many happy hours over the last few weeks planning a major redesign of CodeRunner. I'd appreciate comments on the plans.
The redesign is documented in full here for those who want a 19-page deep-dive. But most of you might prefer to browse the following key attributes and check out the mockups (thanks Claude) of the new user interfaces - click the Play button on a form to interact with it. Please keep in mind the mockups are incomplete, and are intended to convey the general flavour, not necessarily all the details.
Key attributes of the proposed new implementation:
- All existing questions continue to function as today - the students don't see any change.
- Porting of questions to the new format takes place automatically during the upgrade.
- Question prototypes are no longer pseudo-questions stored in question banks. Instead, they are held in a separate database table and are managed via a prototype editor, accessed through the CodeRunner management page.
- The prototype editor is a separate Moodle plugin, so CodeRunner is now three Moodle plugins (question type, behaviour and prototype manager) rather than two.
- Existing prototype questions remain in place simply as inert hooks into the prototype manager, until users are familiar with the new model.
- Questions refer to their prototype directly rather than by name, so the dreaded ‘missing prototype’ and ‘duplicate prototype’ errors go away, and moving or sharing questions and banks can no longer break them.
- Prototype edits now have a change history recording what was changed and who made the changes.
- Prototypes can be tested on all dependent questions before publishing. Like question edits, they reach attempts already in progress only through a regrade.
- Prototypes allow multilevel inheritance. So for example, our University of Canterbury python3_scratchpad question type could become a child of the built-in python3 question type and might have as its children python3_files_function and python3_files_program, eliminating many of the maintenance issues (e.g. ensuring that common code is shared rather than duplicated).
- Both the question form and the prototype editor provide a more friendly UI. They group controls into expandable sections (see the mockups for an example, particularly the Question editing form, which is more detailed.)
- Each prototype in a prototype chain can override any subset of the fields from its parent.
- Questions inherit from prototypes in the same way, and can override any subset of their prototype fields without becoming disconnected from the prototype.
- Many of the existing question fields, like penalty regime, precheck, hide check and answer box rows, move into the prototype chain so a course can configure its own preferences for these in a custom prototype, and override them in specific questions only when needed.
- Prototypes can be shared across courses.
Running the mockups (by hitting the Play button) should make most of these points clear. Or see the full document if you really want the details on how it will work.
Comments/feedback welcome, either here in this forum thread or by commenting on the full document.
Richard