At the OU we’ve been using the questionnaire module (contributed by @mikechurchward of Remote Learner) since the start of OpenLearn, and over the last year also on our student facing system. So I was obviously interested in discussions about replacing the core Survey and Feedback modules with something that might cater to the needs of users of all three modules.
Daniele Cordella and Andrea Bicciolo have been leading the work on the new module and have recently offered an alpha version for comment https://github.com/kordan/moodle-mod_collection. So here I go! You can see their formal announcement of the work here with relevant tracker links. If you’ve already read my post in that thread, stop reading now – as this is mostly a rehash.
Currently the code is written as the Collection module, but when finished it will be called Survey. Collection sounds more like a replacement for the database module. And in some of its UI it even looks like a replacement for the database module. You could ask why we need a survey tool and a database tool – maybe one could be configured to suit both purposes? Comments welcome from any-one who knows better than me!
There’s some good and some less good in the alpha version.
The good is that some requested features for questionnaire are already in: like conditional branching, lists of participants and their submission completeness, user notes explaining each question, using plug-ins for each question type so they can be extended locally, improved user entry data validation.
Less good is that there is no questionnaire migration script – I guess we’ll have to work out the database structure and offer one! The help texts and other language strings are either incomplete or a bit confusing in places – input from a native English speaker will probably help here and I wonder if I’ll have time to help out there? And there are a number of features which would be important to us that are either left out, not yet implemented or broken (I’m not sure which! Comments welcome): saving template question sets for reuse in other courses, sharing a survey across multiple courses, emailing submissions, connection to gradebook, aggregated responses reporting, graphical reporting.
One feature which really caught my eye was the very complex access control for who can view/edit/delete submissions. Normally in moodle, only the owner of a post (say forum entry, wiki edit) can edit or delete the post. Here there are 20 combinations which can be set up for each collection instance. The default was all/all/all which I take to mean that any-one can edit or delete any-one else’s submission. Seems like an odd default to me, and personally I can’t see its use. I’m unsure why this needs to be so complicated, and why capability checks are not sufficient.
I suppose it must have a use for some-one, but that just leaves me thinking that I’d want to set up a default value to suit the OU and tell people not to change it unless they’ve really thought about it. Since the module instance screen is complex, perhaps a set of defaults like you get for quiz or glossary could be set up by the system administrator to make ‘simple’ surveys easier to configure?
I’ve mostly conducted a brief functional review of Collection to see if it meets the OU’s requirements, but as an aside I’ll say that I noticed that the code will not pass HQ peer review in its current state, as there are a number of coding guidelines that need to be adhered to and the branch will need the commits tidying up and given good messages. Not a small job on such a significant amount of code :( There are also a few places where the newer APIs could be used, especially by adding renderers to allow themes to override the display if they wish.