The Moodle Dailies – a guided tour

I’ve had quite a number of requests from people who couldn’t make my session at the 2011 MoodleMoot, and have finally got around to creating a screencast walkthrough. I’m not the world’s biggest screencasting fan (after all, who wants to sit through 15 minutes of being talked at?), but the nature of Moodle conditional activities is such that I’ve created 15 minutes of being talked at for you to sit through if you’re so inclined. The video takes you through the introductory stage and first full level of the Dailies as a player, then walks through the back end and talks a little about the setup and a couple of design tricks.

For those of you who haven’t been playing along at home, the Moodle Dailies is a games-based PD environment for staff (or students) to learn to use Moodle – read the background info here. It was primarily designed in response to my frustration that lecturers/teachers/etc are generally not self-directed learners and the current workshop model (2 hours of being told what to click on) is doing nothing but creating a dependency on training that isn’t efficient, scalable or effective. The Dailies are an attempt to move into a completely user-directed PD model. The design is based on key game concepts from both World of Warcraft and Angry Birds and really turns the traditional PD model on its head (as well as moving away from any kind of traditional LMS course delivery).

Feel free to ask curly questions in the comments – my goal is really to get discussions happening around a big rethink of online teaching & learning and how we design professional development, and game design in Moodle is my way of getting the ball rolling.


Better feedback? Level up.

@witty_knitter has been tweeting this morning from a feedback in science education forum, and of particular interest to me has been the need for immediacy and relevance of feedback balanced with the practicalities of very large cohorts. It has long been realised that timely feedback is difficult to provide on essay-based assessments and paper exams, and most people’s solution to this has been LMS-based multiple choice quizzes. M-H’s tweet below highlighted the issue nicely:

[blackbirdpie url=”!/witty_knitter/status/96754596097179650″]


A following tweet referred to a unit with a cohort of 1200 enrolled – how on earth do we balance students’ desire for interactivity and personalised and immediate feedback with the practicalities of managing such large numbers?

My answer? Games.

WoW has an enrolled cohort of 11.4 million. Angry Birds has 12 million on iOS alone.  Yet each of these ‘students’ gets immediate, rich and personalised feedback on every action. The level of interaction is huge and tests far beyond basic recall, yet the system is completely automated from a ‘teacher’ point of view. The ‘marking’ load is nil, yet ‘students’ are completely satisfied. It might not be possible for you to use commercial games or to design a serious game with a UI on par with commercial games, but even borrowing a few simple concepts from gaming can solve many of the current issues with feedback:

  • Level structure/quest chains – most LMSs now support conditional/selective release criteria, and the simple act of having to complete one task before accessing another is an effective feedback mechanism. Some systems additionally allow you to stream activity release based on certain criteria (grades etc), allowing a degree of personalisation of feedback.
  • Exploratory environments – hide things. Don’t tell students where or how to do every task in the unit. Finding an item or process is a reward for effort, and that reward is a feedback mechanism, with built-in win conditions that let students know how they’re tracking.
  • Competition – don’t be afraid to let students compare themselves (whether in forums, via completion tracking, gradebook etc). When success/failure conditions are low-stakes (moving to next level, locating a resource), competition can be an extremely effective feedback mechanism.
  • Wisdom of crowds – use informal peer review as a feedback mechanism. I can guarantee there will be at least one student who is online more frequently than you are – use that immediacy to your advantage.

For those of you reading that list and thinking ‘Yes, but how do I…’ (or even better, ‘why would I…’), I have a quest for you. Next unit you run, provide a simple introductory activity (forum introduction, 3-question prior knowledge quiz etc etc) and make your unit information dependent on its completion (ie the first activity must be done to ‘unlock’ the unit information document). If your LMS doesn’t support conditional or selective release, ‘hide’ your unit information document somewhere unexpected and ask students to find it. See what your students think*. Use it to kickstart a discussion on how students feel about feedback. It’s simple to build and low-commitment, but might just get the ball rolling on an improved feedback workflow for both teachers and students.

*Expect some of your students to hate it, vocally and repeatedly. They will get over it. My philosophy in regards to change and innovation in teaching and learning is ‘illegitimi non carborundum’ (don’t let the bastards grind you down) – in other words, don’t let the whingers be your reason for not trying something new.

Resolving game issues in Moodle – lessons learned

For those of you who have been vaguely following the Moodle Dailies project, this is the next installment, leading up to my presentation at the 2011 AU MoodleMoot. For those of you who haven’t been following, read here, here and here.

As I get closer to a completed proof of concept, I thought it was worth outlining some of the design lessons (on the technical side) I’ve learned in trying to wrangle Moodle into something approaching a game-like structure:

  1. You can’t be a game purist. It’s not a real game and it’s never going to be a real game – at the end of the day, it’s an LMS. There are a lot of compromises you’re going to have to make.
  2. Don’t bite off more than you can chew. My initial intention to have 20 levels has had to be drastically scaled back to 5 (at least for now), simply because each level is a much bigger beast to design than initially thought. Moodle is somewhat deceptive because it’s technically quite easy to use, but the conceptual issues involved in game design mean a huge amount of time is sunk into problem-solving and testing (as well as mundane but necessary tasks like Creative Commons attribution).
  3. The scroll of death is not your friend. If you are designing in three-tier levels (a la Angry Birds), bear in mind that no matter how well you manage the end-user UI using conditional activities and clever linking, the back end for you as a designer is going to be a huge, hairy scroll of death. A level could potentially have 10 text-and-graphic labels – only perhaps 3 are visible to the end user, but you will see everything. This is another reason my initial 20 was scaled to 5 – it’s just not feasible to work with the back end on that scale.
  4. A rose by any other name is going to be a pain in the backside. When you are heavily relying on activity completion conditions and the use of labels, naming is paramount. Label names take the first bit of text within – and having 50 labels called ‘Click here to go to’ is not helpful when trying to set conditional activities. The name that each dependent activity will take is very, very important.
  5. Legacy course files is your friend. For run-of-the-mill online courses, this isn’t the case, and for good reason. However, when you are working with game design and constantly reusing graphics (next time you play a game, pay attention to how many graphic elements are reused – Warcraft inns, anyone?), the ‘bucket’ way Moodle deals with files really starts to fall down. If you haven’t got legacy course files, use your public folder in Dropbox or hang stuff off Flickr. You’ll thank me when you can reuse code.


And so on. Perhaps the biggest lesson I’ve learned is that designing a game, even in something apparently quite simple like Moodle, takes a lot of long, hard work without much to show for it. As a research project, this has been one of the most time-intensive and least predictable. It lacks a pretty set of data – game design is messy. Interestingly, though, this project has been very effective at both making me think in depth about what I am aiming to design, and about the creative possibilities inherent in what is fundamentally a restrictive learning management environment – something you won’t get from reading papers.

Rethinking the Moodle Dailies

For a while now I’ve been ‘stuck’ with my Moodle Dailies (GBL site for staff Moodle training for new readers). To try and unstick my thinking, I did a quick workthrough of the below Mashable post on disruptive innovation (would recommend reading the whole post) – here’s what I came up with:


Step 1: Disrupting staff training

Staff LMS training at universities is not solving the problems of uptake or improved teaching quality.

Step 2: Cliches

* Training means someone standing at the front of the room while everyone sits and either listens or copies, OR
* Training means reading information online then demonstrating it (eg a quiz)
* Training must be overt/explicit
* Training is not fun

Step 3: Hypotheses:

* What would happen if training was fun?
* What would happen if training was not explicit (ie content not necessarily mirroring desired skills/outcomes)?


And after doing this, I realised I have been looking at things completely backwards. I have been focusing on the self-directed motivation that gaming offers, but still trying to tie the actual content to the concept of ‘Moodle training’ – ie the site content is explicit – you still *realise* you are doing Moodle training. That’s my problem.

Games don’t set out to teach people things. They are not explicit with learning outcomes. Content is designed purely for engagement. The dailies do not need to be explicitly about Moodle training – learning to use Moodle should happen incidentally in the process of engaging in something fun.

Right. Unstuck.

Amplify’d from

Step 1: What Do You Want to Disrupt?

Step 2: What Are the Business Clichés?

Step 3: What Are Your Disruptive Hypotheses?



Using Moodle round the wrong way – an exploration of lessons and conditionals

A while ago now I wrote this post outlining a few ideas on using gaming principles to inform staff training. Those ideas are now becoming reality, and I’m in the midst of designing the Moodle Dailies – a training site for both staff and students. The idea is informed conceptually by WoW daily quests (short 10-15 min tasks that keep you familiar with the environment, increase skills/reputation etc etc) and structurally by Angry Birds (a structured sequence of levels that you must pass to unlock the next level, and each level can be passed with three varying levels of skill). Where the site is really out of left field in terms of traditional training is in the fact that no how-tos or other skill-based information is offered – a goal for each level is defined, but participants must source their own information and develop their own skills. Just like in a game, really.

To build a Moodle site structured like this, I’m really reliant on the use of conditional activites (to allow levels to be ‘unlocked’ and so on). The addition of conditional activities in Moodle 2 has been a bone of contention with many educators. Initially designed to echo the ‘selective release’ of other LMS systems, conditionals give you the ability to dictate a student’s progression through your course. Advocates of authentic, constructivist and self-directed learning argue that student progression should not be dictated, in favour of a more exploratory model. I’ll admit I initially had similar thoughts. Mark Drechsler’s recent (and excellent) post on open source ecosystems covers some of the issues in LMS feature sets here. However, I think to argue that conditional activities don’t create an effective educational environment is only seeing half the story. Like most tools, the devil is in the details – use it poorly, with a restrictive, transmissive approach in mind, and it will be a poor learning experience. But use it creatively, with an explorative and self-directed approach in mind, and the game changes. I’ve found that trying to structure a game-like environment with conditionals really makes you think about progression, motivation and metacognition. If your design is based on goals and not information delivery, there’s ample opportunity for authentic, exploratory learning. All you need to do is think a bit backwards.

The big sticking point for me in the design of the Dailies has been level completion. One wishing to provide level scores and conditional progression in Moodle has several options at their disposal. For practical reasons that I won’t go into here, quizzes, choices and feedback modules were vetoed in favour of the lesson module. However, the wrangling of lesson modules has been a small adventure – it is a fickle and convoluted mistress. I certainly don’t feel like I’ve arrived at an ideal solution. The idiosyncratic scoring and jump structure mean that you are forced to ‘feed’ responses to some extent (ie someone who attempts the level once can see very clearly what they need to do to get higher scores next time), and irritatingly, in order for the lesson to log a grade or a view, you are forced to display an ‘end of lesson’ page that is clunky and non-customisable. I found out the hard way that there’s only so far you can hack a module before you have to start playing by its rules. That said, there’s still a lot of scope for designing disruptive use of modules that were probably initially designed for transmissive, information-push delivery.

I think what has stood out for me the most in this design process is that, while there might be particular design elements inherent in a system, particularly when features are requested by the community to meet certain needs, there’s no real restriction in this. Pedagogy can be rethought infinitely within the technical bounds of a system. So to those who are wary of conditional activities (or anything else for that matter), may I suggest you just spend a while with it trying to use it around the wrong way, for an entirely unintended purpose, and you may find yourself a fan after all.

Moodle, dailies and angry birds

I’ve just been reading this post by @deangroom and aside from it being an excellent concept it’s got me thinking. Having never really been anything more than a passive gamer (although I did have an extended love affair with all things Mario on the N64 as a teenager), I’ve recently fallen prey to Angry Birds. Angry Birds is an iPad/iPhone game which involves flinging assorted angry birds at various structures holding green pigs, which one must destroy. It is insanely addictive and insanely frustrating.

However. The idea of dailies has got me thinking about exactly what it is that keeps me flinging angry birds day after day, despite my n00b skills. Essentially, it’s the thrill of the conquest – because achievement is broken up into small levels, my ROI for effort is quite good, and I can play for as little or as long as I like whilst still feeling like I’ve achieved something. The satisfaction of killing the pigs keeps me coming back to see if I can get more skills to kill more pigs in better ways. The other genius of Angry Birds is that there’s more than one way to complete a level. You can get an average score for a one-star completion that still allows you to progress to the next level, but once you’re a bit more skilled, you can return to that level and play more efficiently to get two- and three-star completions. Alternatively, you can just be skilled in the first place and knock over three-stars on every level. This is not me. But it would be nice. Additionally, my husband has now got Angry Birds on his iPod Touch, so there’s a nice element of competition.

Currently I’m charged with the task of designing the training program for our impending move to Moodle. With any training program, the real issue is how to get people to engage, particularly those who don’t self-select. Dailies might be at least a partial solution. I’m thinking of a course where staff login once a day, every day, for a very short period of time (Dean makes the excellent point that no-one is too busy to spare 10-15 minutes). The course is built on levels, which must be completed to ‘unlock’ the next level (using Moodle conditionals). Each level can be completed with one-, two- or three-star skills. It’s designed for one level to be done daily, but restrictions are only on completion, not time, so motivated people can rip through the course as fast as they like. Conversely, time-poor people don’t have to try and cram in everything in one go then immediately forget everything (which is the usual mode of operation in LMS training). Let’s just hope that if I build it, they will come.

A side note that I find interesting is the concept of cheating. If I’m getting frustrated on an Angry Birds level I can’t beat, I’ll go to YouTube and look up walkthroughs. My husband thinks this is cheating. I think it’s smart. In a Moodle dailies course, I’d encourage people to ‘cheat’. The more they go outside the course to source tips and skills the better. Bring it on, I say.