I’d thoroughly recommend watching this, it sums up a lot of my thoughts on working with the Moodle community.
It is such a natural thing to take feedback on your code personally but in truth working with the experienced folk at moodle.org is a fantastic opportunity to develop your skills and recognise your weaknesses.
When I first switched from teaching to development one of my biggest dislikes was having to manually transfer feedback from my Moodle Assessments to the student records on ProMonitor, the E-ILP system used at BSDC.
I’m now looking at the possibility of developing an Advanced Grading Method for Moodle 2.2+ which can be driven by the markbook structure in ProMonitor. My hope is that I can present the tutor with a form which matches up to their gradebook in ProMonitor 100%; something which 9 other colleges in the UK have expressed an interest in!
Today I have been looking at how the grading method will be related to ProMonitor’s database. Initially I was quite optimistic that it would be easy to select a course, followed by a unit, and finally an assessment which you wanted to use for the grading structure. This is a simple workflow which makes sense, but unfortunately it doesn’t reflect the way that people use ProMonitor.
For example, if you have an option of three routes on the second year of a BTEC programme, the probability is that each route will share a large number of units. In this case you will have three ProMonitor courses each containing the same unit.
Unfortunately ProMonitor’s approach to solving this is to allow tutors to clone assessment units in the database. In order to allow tweaks and changes to be made to one and not the other these clones are duplicated in the database with no common identifier shared between them. Even if there was a common identifier it would not be sensible to assume the structure was remained identical on each unit. In other words we have to accept that the unit within each course unique.
The easy solution is to make my new grading method refer to one “course” only and expect our Moodle users to create separate assessment activities for each path of the course where they might not have done before. This is not ideal but at least gives us a safe fallback position.
One option may be to write a method of finding duplicated assessment structures and “undoing” the duplication within the database. The worry with this is that an assessment structure may change after the grading method has been added to the assessment which would lead to problems when trying to synchronise with ProMonitor.
The better solution may be to alter my workflow allowing tutors to add multiple courses/unit/assessments to the grading method and then dynamically switching to the correct one for each student. However, this raises the prospect that a student may have more than one applicable assignment, in which case we would need to ask the tutor which they would like to grade. Alternatively the student might not be enrolled on any of the assessments, in which case we would have to present the tutor with an error message.
Fingers crossed I can come up with something that works well for everyone!
There is a tendancy to over-engineer solutions in the Moodle community sometimes, and this tends to lead to confusing interfaces or even worse something that doesn’t work as it should.
I’ve spent most of the last few months writing local plugins for Moodle; the kind that have eight tables in the database and make your mind melt as you work on them. So when I found a bit of time I decided to create a simple straw poll block which would “just work”.
A straw poll is a simple thing, and because it is in a block we know that there should be a limited number of questions. Equally I felt it was overkill to support the exporting of complex spreadsheets to show the results. A total and a percentage should be enough for any straw poll, and if you want more than that there is the wonderful Choice activity!
So I decided that the Questions and the Responses could all be held directly in the block configuration meaning the only table that would needed in the database would be for responses. This is more efficient since block configuration is already loaded and it cuts down the number of DB queries Moodle needs to do.
The configuration for the block is very simple, with one text box for the question, six text boxes for possible options, and a few extra options to control how the user will interact with the block. The empty options are simply ignored by the block and responses cannot be submitted for them.
I will be submitting a Beta of this block to Moodle.org soon, but if you would like to try it out now you can download it from my GitHub repository.
Forms in Moodle have always been a bit lacklustre. Whenever I am training staff on how to use them I have to admit that the forms “look scary but are mostly irrelevant” when adding new modules or editing course settings. Gladly this is all set to change with the upgrade to Moodle 2.5.
For those of you who haven’t looked into this too closely I should explain that Moodle uses a class called MForm to make it really easy to build forms in Moodle. These forms are then rendered in a pretty standardised way. In Moodle 2.5 these forms have been streamlined to hide the superfluous settings within an expandable tab by default
I had been looking at the possibility of writing a YUI module to take these mform pages and give them a tabbed format which highlights sections with required fields. But with these improvements it may be possible to do this with just CSS.
I will keep posting about my progress, but it occurs that there are a few difficulties which I am going to have to think about fairly carefully:
MForms are not used everywhere that you would expect. For example when editing the settings on the front page of Moodle I was suprised to find that it presents itself without any fieldsets and without the standard mform classes.
MForms are used where you wouldn’t expect. Right the way through the course import process the pages are dynamic mforms in two columns making the styling look slightly out of place.
Not all required fields are required. By which I mean that you can create a completely useless instance of the “File” resource, but really we want the attached file to be highlighted to the user as a priority. Somehow this has been overcome in the new version of Moodle, but I’m not sure how dependable that is.
Hopefully I will be able to come up with a non-invasive solution for tabbed forms in Moodle!