Re-usable activity modules - how can this be done?

Re-usable activity modules - how can this be done?

by Joe Cape -
Number of replies: 3
Picture of Plugin developers

I am trying to create a new kind of activity module that would enable 'module reuse'. I am interested to hear whether others have had a similar need and how this has been approached.


The idea is that a new kind of 'alias' module would allow me to use the content and setup of an existing module. It would then save any grades or other user data with reference to the 'alias' module. The main motivation is to support the DRY principle: If a module is reused in several courses, it is best to maintain one version of it and reuse rather than replicate. In some cases, it also opens up the possibility of better reporting. If 20 feedback modules have the same set-up across different courses, for instance, at present the response analysis has to be done within each module in each course. If it is known that all of the modules feature the same questions, the report could integrate the responses across the whole site.


My implementation approach is to have this new activity module linking to the 'target' module. In the target module, all links are changed to include the alias_cmid in the URL parameters. Tables related to user data are changed to the include this alias_cmid and this is inserted when saving user data. Report queries are then adjusted to retrieve records with the alias_cmid if the target module has been accessed through the alias.


I have tried implementing this with the SCORM module but found that it was too complex to be workable. There were 40+ links that would have to be changed (to include the new cm_alias ID) and maintained. There were also many different reporting options that would have to be supported. It seemed like it would be too easy to miss something that could lead to bugs and access errors (users being directed to the original SCORM module rather than the alias).


I am now making a stab at it for the Feedback module, which seems somewhat more manageable. The biggest issue I can see is that there will be a large maintenance burden for any updates to the module since it has to be changed in so many places to support this.


I'm keen to hear whether there's a better approach. Has this been discussed here before?

Average of ratings: -
In reply to Joe Cape

Re: Re-usable activity modules - how can this be done?

by AL Rachels -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Have you looked at the Sharing Cart block? I used it in combination with a "resource course" to keep from having to recreate activities. For instance, I would have a default quiz set up in my resource course and then copy it into the Sharing Cart. In any of my production courses, I could add a Sharing Cart and have access to whatever I had already placed in it. With just a couple of clicks, I could place a copy of the quiz in it's new location. Sharing Cart seems to work with just about any plugin available for Moodle. I did not use the data copy capability but it does seem to be able to copy data from one location to another, too.

In reply to AL Rachels

Re: Re-usable activity modules - how can this be done?

by Joe Cape -
Picture of Plugin developers

Thanks for the suggestion. I've had a play about with it and it looks like a really well put together module. It's a much neater way of using backup/restore functionality in many scenarios. It is not really what I had in mind however since it still depends on *copying* the content of activity modules, whereas I am looking to have one definitive version of the module and have alias modules that *point* to that version. 


By way of example: I tried using it to share feedback modules between courses and can see that it copies all of the questions used in the feedback. It would be better to be able to use the same questions (i.e. only have one record for each question that is used for all instances of the same feedback). That way, if I have 20 feedbacks in different courses, I can change the question in one place and update all. It also means that I can build reports with the expectation that all feedbacks have exactly the same content and set-up.

In reply to Joe Cape

Re: Re-usable activity modules - how can this be done?

by Richard Oelmann -
Picture of Core developers Picture of Plugin developers Picture of Testers

Feedback is probably not a good example of what you want to achieve simply because it can already do what you are describing.

If you add a Feedback to the front page (put it in the Main Menu block and then hide the block if you dont want it visible on the front page), you can then map that Feedback to the courses you want it to appear on and add the feedback block itself to those courses so that the activity appears on the course (you can have multiple feedbacks across different courses, or on the same course for different purposes, the block will list any that are mapped to that course). If you know you want feedbacks on every course page, then add it as a 'sticky block'.

If you edit the questions on that feedback via the front page, those changes will appear in every mapped course - its just a link to the front page one after all. And when you look at the responses via the front page feedback, you will see that you can report in total, or filtered by courses.

I've done this previously with student surveys for teaching programmes and created a feedback tempalte which I then used to create a feedback activity for each department, the department feedback was mapped to all the taught courses and when the students responded the replies could by analysed by taught course or by department (department heads were restricted from seeing the raw results in other departments by using the separate activities), and because all the departments used the same template, exporting and combining the data at a faculty/institution level was then a very simple job too (an sql report from the database or an Excel spreadsheet depending on what you want).


If you want to apply that kind of logic to other module activities, actually looking at the feedback module and its back-end code might be a good place to start, because it seems to already do what you are asking about.


Richard