Edinburgh Castle

Edinburgh Castle, by Roel Wijnants on flickr.com

This year’s Moodle Moot took place at Edinburgh’s Corn Exchange on 15-16 April. The inventor of Moodle, Martin Dougiamas, was in attendance (accompanied by his kids), and he popped up everywhere, participating in panels & discussion groups and giving his usual “what’s next for Moodle” keynote. This gave us an overview of the new features in Moodle 2.7 (released this month):

  • New events and logging model – allowing for more detailed logging, more control over logs, and event-driven actions.

  • New text editor: Atto. This has been built from scratch, so it’s very tightly integrated with Moodle. It uses HTML5, is very accessible, and has a built-in maths editor based on MathJax, so no server binaries required.

  • Bootstrap-based themes only, by default, so Moodle works properly on mobile. The old themes will still work, but are deprecated.

Also, this Moodle will be an LTS (long-term support) release, with fixes being published for 3 years instead of the usual 12 months.

Martin also previewed plans for 2.8:

  • Complete redesign of gradebook and grading plugins

  • Improved, usable forums (led by Stuart Lamour, of whom more later)

  • Simpler navigation

  • A new “element” library, to make development simpler and more consistent

One common theme this year was responsiveness on mobile devices, and a frequent contributor was Bas Brands, the creator of the Moodle Bootstrap themes. Bootstrap is a CSS/Javascript framework, developed for Twitter, that has been used to create responsive themes for Moodle. Since Bootstrap uses the JQuery javascript library, and Moodle is committed to the YUI library, Bas had to do a lot of rewriting of functions. Furthermore, the new Bootstrap 3 framework is a complete rewrite of Bootstrap 2, so a lot of the work will have to be done again…

Now Moodle works well on mobiles, why do we need an app? This was the question asked at the mobile discussion panel. Martin’s view was that an app should allow for offline use, and should facilitate the collection of data and pushing of those data to Moodle; not that the app does either of those things well at the moment, so there is a lot of work to be done on that front. Furthermore, Moodle only have one FTE developer assigned to the app at the moment, so unless the rest of the community steps up, the app is likely to remain limited. On the bright side, it will soon work with CAS authentication, so we’ll finally be able to use it at LSE.

Another major theme was usability. Stuart Lamour, who was behind the unique look and feel of the University of Sussex Moodle, popped up all over talking on this subject. He quoted research done by Brad Frost, which showed that users of websites ignore everything on the page except the central content they are looking for – in other words side blocks are pointless. Elsewhere he argued for an approach to course design whereby teachers are encouraged to ask “what do my students need?”. At Sussex they surveyed students to this effect and found that they wanted a clear, logical layout that corresponds to the teaching that goes on in class and that reflects the personality of the teacher. They therefore started using a single-page layout, with all content inline where possible; they moved all updates and messages to the top, so students see what’s new as soon as they arrive at the page; and they made profile pictures larger, to make the content and discussions more “human”.

Later on, a panel session on usability brought out the following points:

  • A general agreement that students want different systems to look different, so that they know where they are. Glasgow City and Dublin City both said they had found evidence to this effect.

  • We debated ‘Theory X vs. Theory Y’ approaches: should we prevent teachers from doing anything dumb with HTML, or should we let them do what they want and they clear up their mess afterwards? The consensus was that we use interface design to encourage them to take a clean and  simple approach, but allow them to do more complicated things if they need to.

  • The use of tables for screen layout is still common, and text editors still encourage this approach. What is needed is a text editor that allows teachers to easily do layout properly, using div tags.

  • There was some debate around on-screen descriptions. These are needed by first-time users, to be able to understand the context of each item on the page. But thereafter, does it just become clutter? No clear agreement emerged.

Finally, “Moving Moodle Forwards” was another panel session with Michael de Raadt and the ubiquitous Bas Brands, discussing how the community can help developers via the Moodle Tracker. Some useful nuggets here:

  • Votes are only really relevant for improvements; bugs are prioritised on the basis on severity, not votes.

  • Fixes are welcome in any form – the gold standard is to provide a github link for the fixed code, for each active Moodle branch. But the silver standard (uploading a patch as diff files) or bronze (posting the fixed code as a comment) are also welcome.

  • Process for bug fixing is as follows: Triage (is it a bug?); Development (assigned developer does the fix); Peer review (different developer checks the fix); Integration (developer adds it to active branch); Testing (automated and human)

Another good Moot overall. I was impressed, as ever, by the developments being made and by the spirit of sharing and mutual support that pervades this conference.