Tuesday, 5 May 2015

Count all activities on Moodle

It's that time again - I get to produce a report from the Moodle database.

The purpose of this blog is more or less a placeholder. I've written up my SQL:

SELECT `mdl_course`.`fullname` as 'Course Name'
, mdl_course.id as 'Course ID'
, sum(mdl_modules.id=1) as 'Assignment'
, sum(mdl_modules.id=2) as 'Chat'
, sum(mdl_modules.id=3) as 'Choice'
, sum(mdl_modules.id=4) as 'Data'
, sum(mdl_modules.id=5) as 'Forum'
, sum(mdl_modules.id=6) as 'Glossary'
, sum(mdl_modules.id=7) as 'HotPot'
, sum(mdl_modules.id=12) as 'Quiz'
, sum(mdl_modules.id=14) as 'SCORM'
, sum(mdl_modules.id=15) as 'Survey'
, sum(mdl_modules.id=16) as 'Wiki'
, sum(mdl_modules.id=17) as 'Workshop'
, sum(mdl_modules.id=22) as 'Feedback'
, sum(mdl_modules.id=25) as 'TurnitinTool'  
FROM mdl_course

join mdl_course_modules on mdl_course.id = mdl_course_modules.course
join mdl_modules on mdl_course_modules.module = mdl_modules.id

group by 'Course name'


and as you can see it's very pretty and sensible and should (theoretically) return the number of each activity type that features in courses on the site. What actually returns is:

Course NameCourse IDAssignmentChatChoiceDataForumGlossaryHotPotQuizSCORMSurveyWikiWorkshopFeedbackTurnitinTool
GC VLE10302310289724715898929911122391501655

While this is surprisingly handy, it has to be said it is

  1. inaccurate - we have many assignments. But I think this is a result of the assignments now being a wholly separate situation from the other module types, and therefore not being registered on the module list. I need to look into this again.
  2. not what I need. I need each course to be listed and the activity types *per course* to be clearly identified. 
I have absolutely no idea why it isn't working as it should, but I have a feeling my joins are causing the issue.

Monday, 2 March 2015

Digital Technology activity ideas

I recently delivered a session on using technology in teaching English. Most attendees were delivering GCSE English to vocational students who were retaking the subject.

I knew going in that I didn't want to stand at the front and tell people about available technology. While hearing about tools automatically makes me wonder what I can do with them, it's difficult after a hard day's work (this was an evening session) to focus long enough to process an understanding not only of what a tool's function is but what you can use it for.

Text taken from Wikipedia. Clipart taken from PowerPoint.

So I wrote a mini list of example activities and tools to cite and planned to sit back and let them do the thinking.

We covered a few common activities and below are the few that stuck in my mind:

  1. Using Twitter for... well, pretty much anything.
    1. Define words
    2. Describe an idea
    3. Tell a story
    4. Re-write a paragraph to fit into 140 characters
  2. Using Facebook for characters and stories
    1. Create character profiles
    2. Interact with the profiles to rewrite the story
  3. Using video in class
    1. Split into groups and set a task. Each group videos the culmination of their task and plays it back to the class at the end of the activity.
    2. Split into groups for a large class project. At the end each group produces their piece and a video of the whole group can be used to review the project at the start of the next class.
  4. Using comics
    1. Ask students to use a comic generator to interpret a scene from which all descriptive text has been removed. Compare their interpretation to the original text and see if it has changed.

I really enjoyed the session and although there was nothing unique discussed, I think the attendees got a lot more out of it than they would if I'd told them what was available.


Friday, 23 January 2015

The 80:20 rule

My degree involved an awful lot of coding and development, and the inevitable hours of related bug fixing and QA in order to complete a coursework in time. It was there that I first learned the 80:20 rule.

In any project, 80% of the work requires 20% of the effort.

Back then, the first burst of coding required to get something approximately right took about 20% of the effort. The QA; that long hard slog to the deadline, knowing that despite all your efforts it was highly unlikely you would ever achieve a bug free project and at 3 am deciding that as it had compiled, surely that was good enough? - That was the 80% of effort required.

I use that phrase rather flippantly nowadays and it seems that outside of programming the 80:20 rule is very different. However, these last few weeks as projects are altering and growing, I've become more and more aware of just how much that rule applies to *every* aspect of my job.

This week I have been writing a report which is crazy big. *Unbelievably* crazy big. It is actually a collection of mini reports on a variety of projects I'm running and the rule most definitely applied.

The first 20 or so pages were copies of data, interspersed with updates and feedback points. It came together really easily and I, foolishly, was delighted and thought "This won't be so hard after all!"

Of course, those were the data sets and responses that were easy to gather and interpret. Initially I had thought I was randomly selecting projects, whereas in fact I was starting with the ones I had most data on, or closest relationships with the people involved.

Suddenly it became a lot harder, and I had less time.

And of course, as is the nature of anything that follows the trend of an exponential growth chart, I don't think I'm ever going to finish.