Bringing github and the Moodle book module together – step 1

The following is the first step in actually implementing some of the ideas outlined in an earlier post about bringing and the Moodle Book module together. The major steps covered here are

  1. Explore the requirements of a book tool.
  2. Name and set up an initial book tool.
  3. Figure out how to integrate github.

A book tool

The Moodle book module is part of core Moodle. Changing core Moodle is (understandably) hard. Recently, I discovered that there is a notion of a Book tool. This appears to be a simple “plugin” architecture for the Book module. People can add functionality to the Book module without it being part of core. The current plan is that the github work here will be implemented as a Book tool.

What does that mean? My very quick search doesn’t reveal any specific information. The book tool page within the list of plugin types in the Developer documentation is missing. Suggesting that perhaps what follows should be added to that page.

The plugin types page describes book tools as

Small information-displays or tools that can be moved around pages

Which is perhaps not the best description given the nature of the available Book tools.

The tool directory

The book tools appear to reside in ~/mod/book/tool. Each tool has it’s own directory. Apparently, with all the fairly common basic requirements in terms of files


The Book module’s lib.php has various calls to get_plugin_list(‘booktool’) in various places

  • book_get_view_actions
  • book_get_post_actions
  • book_extend_settings_navigation

The first two look for matching functions (e.g. book_plugin_get_post_actions) in the book tool’s lib.php which get called and then used to modify operations.

The settings navigation is where the changes to the settings/administration block get made and from there that’s how the author gets access to the booktool’s functionality.

Naming and getting it started

The plan seems to be to

  1. Create a new github repository for the new book tool
  2. Copy and edit an existing book tool to get started.
  3. Figure out how to slowly add github functionality.

Creating the booktool github repository

The repository will need to be called moodle-booktool_pluginname. What should the plugin name be?

I’ll start with github. Existing tools tend to include a verb e.g. print, exportepub, importepub, exportimscp. So this may be breaking a trend, but that can always be fixed later.

And then there was a repository.

Clone a local copy.

Copy the contents from another book tool and start editing

And take a note of work to do on the issues section of the github repository.

Updated the icon. Wonder if that will work as is?

Login to local moodle. It has picked up the new module and asking to install. That appeared to work. Now what happens when I view a book resource? Woohoo that works.

Doesn’t do anything useful beyond display the availability of GitHub (with the nice icon).

Early success

Push that code back to the repository.

How to integrate github

Time to actually see if it can start talking to GitHub and how that might be achieved.

Initial plan for this is

  1. Hard code details of github repository and credentials for a single Book module.
  2. Implement the code necessary to update the link in the settings block based on whether the book is up-to-date with the repository.
  3. Implement index.php function to display various status information about current repository and book.
  4. Implement the fetch and push functions.

    From here on a lot more thought will need to be given to the workflow.

  5. Implement the interface to configure the repository/credentials

Which all beg the question.

How to talk to the GitHub API

The assumption underpinning all of this is that the tool will use GitHub API to access it’s services. Moodle is written in PHP, so I’m looking for a PHP-based method for talking to the GitHub API.

There’s no clear winner, so time to do a comparison

  • Scion: Wrapper – initial impressions good. Does use cURL. But requires other “scion” based code
  • KnpLabs API – requires another library for the HTTP requests. Not a plus.
  • tan-tan-kanarek version – looks ok. No mention of other requirements.

Let’s try the latter. Installation and it’s all working. Now only need to grok the API and how to use it from PHP.

The focus here is on an individual file. The book will be connected to an individual file.

Most of these request seem linked to the Contents part of the API – part of Repositories.

Actions required

  1. Does the file exist in the repo?
    Getting the content should return a 200 status code and “type: file” if it is a file, but it will also return the content of the file.
  2. Create a new file
    API: PUT /repos/:owner/:repo/contents/:path
  3. (fetch) Get the content for the file.
    API – GET /repos/:owner/:repo/contents/:path
  4. (push) Update the file with new content.
    API: PUT /repos/:owner/:repo/contents/:path
  5. What is the status of the file in the repo?
  6. What is the relationship between the content/status of the file in the repo and the content in the book.

Running out of time. Will have to come back to this another day for Step 2.

Import and the Book module: a case of knowledge loss?

The ability to modify open source software (like Moodle) is often identified as one of its strengths. The ability to scratch your own itch, to modify the software to fit your needs is seen as a major plus. Especially when – as with Moodle – that software has an inherently modular (the M in Moodle stands for modulear) architecture that makes it easier for people to scratch their own itch. But making modifications to large bits of software like Moodle requires a fair bit of specific knowledge.

Costello (2014) points out that the “perception that Moodle is easier for institutions to adopt to their own needs is widespread” (p. 193) and that this ability to modify Moodle can form part of the rationale for adoption. Especially for institutions that see themselves being “a co-creator and developer of innovations rather than simply buy(ing) them already packaged up” (Costello, 2014, p. 193). The reality is often messier. The following is capturing one example of that messiness.

The import problem

As outlined in this post I had a problem with the Moodle Book module and its import functionality. A problem illustrated by the following image. In short, the import functionality allows you to provide a zip file containing multiple HTML files. The import should unpack that zip file and place each of the HTML files into the book as separate chapters.

Problem with Moodle book import

But as the image above shows I found two problems

  1. The order of the files were changed from what I wanted into a form of alphabetical order.
  2. The names of the chapters would retain file system components (e.g. _sub in the filename indicating a sub-chapter and the .html extension)

I checked the documentation on importing at the time and seemed to be doing all that is required. This was somewhat frustrating because it required a lot of manual intervention on my part to set right.

Disbelief by kmakice, on Flickr
Creative Commons Creative Commons Attribution-Noncommercial-Share Alike 2.0 Generic License   by  kmakice 

My immediate response was something like that to the right. The Book module has been around for a while. It’s part of the Moodle core. Importing HTML files into a Book is likely to be a fairly common practice. Surely this couldn’t be how it was left to work. After all, “given enough eyeballs, all bugs are shallow” is a mantra of the open source community.

Oh well, I like to code and perhaps this problem is an example of where I can make a difference. I look at the code for the Book module and fairly quickly see where the problem is, can conceive of and implement a solution, and contribute it back to the broader Moodle community. The patch is sitting there waiting to be checked and perhaps might eventually become part of the Moodle core.

A happy story of the open source model working (if a little slowly).

But it’s not as simple as that

I talked about this and other itches around the Book module in this presentation at Moodlemoot’AU 15. Quite a few people attended, quite a few commented positively, and the presentation has been viewed 670+ times on Slideshare. Lots of eyes.

But it’s only yesterday when I get an email from Jonathon Fowler a Moodle developer (amongst other things) where I work. On hearing about the import problem his reaction was much the same as mine. A bit of disbelief. Johnathon knows the original developer and didn’t believe he’d leave the import function sitting in that state. He looked at the code and he was right. It hadn’t been left in that state.

Apparently, the import function will correctly order and name the chapters if you

  1. Put the title of each chapter (HTML file) in the title tags of the HTML header.
    The following chapter will have the chapter name “Overview”


    Why didn’t I do this? Because my authoring process was to edit a single HTML file where the chapters were separated by div tags. A Perl script separated the single HTML file into multiple and stuck them in a zip file. I need to modify the Perl script to add in the title to the single HTML files.

  2. Add numbers to the start of the file names.
    So with the example from the image above, the required file names become

    1. Overview.html
    1.1 Create a new book_sub.html
    1.2 Rewrite an existing book_sub.html
    2 The import itch.html

    And the script will need to be modified to add numbers to the file names.

Tested and that all works.


/doh by striatic, on Flickr
Creative Commons Creative Commons Attribution 2.0 Generic License   by  striatic 

Appears I’m a bit too quick to engage in a bit of minor “solutionism” rather than try to understand the features of the tool. There was a problem, there seemed a simple (fairly) clean solution and so I solved it.

I’ll reflect a bit on any potential broader implications later, but first.

Improve the documentation

Before I go too much further I need to improve the documentation on importing into the Book module so that no-one else makes a similar mistake.

Uggh, the docs are in some hideous markup language. Moodle wiki? Perhaps best to look at the guidelines for contributors first. It does appear to be using Mediawiki, better go find some formatting help.

Not happy with it, but it’s a slight step forward.

Bugger, just realised that this fixes the documentation problem on the Moodle docs website (for 2.8 anyway), but it doesn’t fix the inline help that appears in the Book module. It still has much the same

I should also update the tracker item I added to make sure no-one else wastes their time on this. Will do that after I post this.

Broader implications?

I wonder if this points to anything broader beyond lack of attention to detail and a tendency to code up a solution.

It does add a small anecdote supporting the idea that (one of) Linus’ laws (i.e. more eyes == bugs are shallow) is a fallacy. Quite a few people saw me mention this “bug”, but no-one (until Jonathon) picked up my inability to identify the existing functionality.

It appears no-one currently involved knows the Book module well enough to have been aware of this functionality. The documentation also shows no explicit mention of this “hidden” but needed functionality.

I wonder how many people have had this problem? Or is it just me? Update: able to do a quick check of an institutional Moodle, 17 (2.2%) of 759 books in that sample were imported. And those were from a single course.

It appears that the “lack of love” given the Book module over recent years is showing in terms of lost knowledge. How does a large, modular open source project detect, avoid, or prevent this type of “knowledge loss”?

All up I’ve invested a fair bit of time in this experience (just this blog post alone consumes a bit of time) for fairly minor improvements. This work is not exactly going to directly transform the learning of 1000s of learners. What would be required if you really wanted to do something interesting, impactful, and complex?

A lot of that time has been spent learning or re-learning knowledge about how to engage with the Moodle ecosystem. You need to know something about software development, PHP, github, Mediawiki, Moodle documentation and associated processes etc and then you get to the really hard stuff, knowing what the people using the system want to do and how that might translate. From all that I’ve seen the Book module once had someone that had that knowledge, but it appears to have been lost.

For an individual (or organisation) to get their head around all that requires quite a large investment of resources/knowledge. Moodle core have the technical knowledge down pat and are adding more developers, but what about the knowledge of the user experience? They are also taking steps in that direction, but that in itself is going to generate a need for more resources.

Leading to questions of prioritisation, which inevitably leads to the problem of stavation.

Has me wondering if it’s time (and possible) to add another layer of abstraction here. Is something like Moodle at too low a level of technical abstraction?

Testing my patch

The next question is what impact my patch has on this behaviour.

Will the normal Book functionality work?

The need to include the numbers within the filename of each HTML file, essentially re-creates what my patch does. Hence my patch should work okay. The order with numbers should be maintained.

Yes, that appears to work. The numbers are removed as expected.

What if I remove the numbers and rely on my patch for ordering?

Yes. This will and does work.

What if my script includes the chapter title in the title tag?

Modified the script to add the filename plus “XXXXXXX” to the title tag within the HTML file, and that’s what is used for the chapter names.


It appears that my patch plays nicely with the existing functionality. Begging the question, does my patch add anything? Well,

  • If you leave the numbers out of the filenames, my patch will order the chapters in the same order as the zip file (rather than a natural sort).
  • If you don’t put anything in the title tag of the HTML file, then my patch will nicely remove the _sub and .html parts of the filenames.

Not a complete waste of time, some small benefit.

I’m slightly relieved that my code didn’t break anything.


Costello, E. (2014). Opening up to open source: looking at how Moodle was adopted in higher education. Open Learning: The Journal of Open, Distance and E-Learning, 28(3), 187–200. doi:10.1080/02680513.2013.856289

What’s good for “open content” is good for the LMS/virtual learning space?

My tweet stream reminded me this morning that #oer15 is up and running. The following tweet from @courosa was amongst the first I saw.

The tweet draws on the 5Rs framework from David Wiley as a way of defining “open content” as having a license that allows others

to engage in the 5R activities:

  • Retain – the right to make, own, and control copies of the content (e.g., download, duplicate, store, and manage)
  • Reuse – the right to use the content in a wide range of ways (e.g., in a class, in a study group, on a website, in a video)
  • Revise – the right to adapt, adjust, modify, or alter the content itself (e.g., translate the content into another language)
  • Remix – the right to combine the original or revised content with other open content to create something new (e.g., incorporate the content into a mashup)
  • Redistribute – the right to share copies of the original content, your revisions, or your remixes with others (e.g., give a copy of the content to a friend)

Why stop at content?

When it comes to learning (and teaching), I wonder about the focus on and definition of “content”. Especially if you take @downes perspective that the “content in learning functions as a McGuffin”. At the very least, the content in the courses I design is somewhat important, but it’s not the only thing.

What the learner does with and takes from that content is more important. What the learner does is enabled and constrained by the tools available to them and the affordances those tools offer. Sitting in a lecture, reading a print book, watching an online video, engaging on a blog, engaging in a discussion forum all offer different constraints and enablers.

Regardless of their relative merits, increasingly the learners in my courses are being required to engage with a range of digital technologies in the form of a the institutional LMS and other tools. These tools – both institutional and personal – make up their virtual learning space. Complaints about the LMS have been many and regularly over the last 10+ years.

Perhaps the most regularly complaint from certain circles is that the LMS is not open. Not open in terms of only people enrolled in the course at the institution are able to access it. Not open in terms of once you leave the institution you probably don’t have access anymore. Not open in terms of not being able to use Google (or in my case any search engine) to find material on the LMS.

But recently there has been another trend in institutions that have been making the LMS even less open. Many institutions are now mandating consistent, minimum standards for all courses hosted in the LMS. At my current institution that has translated into the virtual learning space for a course having to look a specific way and more troubling to use specific locally produced tools (e.g. a particular way for presenting assessment information and a study schedule).

What’s worse is that this mandated consistent set of minimum standards is being seen through the lens of an “established” view of technology. That you can’t and shouldn’t change the technology. In fact, if you do change the technology you are seen as breaking policy and are required to “please explain” (as has happened to me this year).

In some large part this type of thinking to me is an example of this quote from Bret Victor

We’re computer users thinking paper thoughts

The mandating of consistent, minimum standards for all courses in an LMS gives me a strong sense of a deja vu for the bad old days of 2nd generation print-based distance education. The days when all the distance education courses for a University had to use the same style guide, even if it broke all the Prolog code in the Machine Intelligence material. Mandating consistent, minimum standards for all courses in the LMS is “computer users thinking paper thoughts”.

It’s an example of people not understanding what’s really different about computers and digital media. Mike Caufield makes this point

I would argue (along with Alan Kay and so many others) that for digital media the most radical affordance is the remixability of the form (what Kay would call its dynamism). We can represent ideas not as finished publications, but as editable models that can be shared, redefined, and recontextualized. Conversations are transient, publications are fixed.
But digital media can be forever fluid, if we let it.

Universities are missing out on the full benefits of digital media because they are “computer users thinking paper thoughts” that don’t even recognise the “remixability” of digital media and the potential that brings. Instead of leveraging this affordance of the medium and letting it be fluid, institutions are setting it in stone.

Even if you open access to the LMS, will it be open?

Even if an institution opens up access to the LMS. Allows any one into it. I don’t think it can be classed as open, because access is only the first step in being open.

I’m thinking that the LMS – or any other institutional virtual learning space – can’t be truly open until allows me to

  1. Retain – to make and control copies of the data, experiences, and perhaps affordances offered by that learning space.
  2. Reuse – the data, experiences, and perhaps affordances in other ways, in this space, and other spaces.

    e.g. download data about learner activity to my laptop to perform analysis not available in the LMS. e.g. take data from the LMS to generate a “learning report” to automatically “mark” learning activities.

  3. Revise – to adapt, adjust, modify or alter the data, experiences, and perhaps affordances in other ways, in this space, and other spaces.

    e.g. I can use jQuery to point the mandated “Assessment” link to assessment information that is presented more appropriately.

  4. Remix – to recombine the original and revised data, experiences, and perhaps affordances in other ways, in this space, and other spaces.

    e.g. take LMS data and data from the student records system to develop a “learning process analytics” tool used in the course.

  5. Redistribute – the data, experiences, and perhaps affordances in other ways, in this space, and other spaces.

    e.g. the idea of a tool that allows the learning material in my course to be re-purposed as an open book.

Should/can the virtual learning spaces be open in terms of the 5Rs? How might this be done? What problems/benefits might accrue?

Personally, these are important and interesting questions. Not the least because I’m already doing this (see the examples above) via various backdoor methods. And it is helping to make the task of teaching 300+ students somewhat bearable.

Starting the “Moodle open book” project

Back in February I shared shared some thoughts about some ideas for grants for producing an “open textbook” at my current institution. In the end, these thoughts were translated into an application which has just been officially announced as being successful. The following is my first attempt to get my head back into the project and outline

There’s also an initial project page.

About the project

Rather use the funds to write an (is it at the stage of “yet another”) open textbook. The project aims to develop a framework to enable the re-purposing of existing course materials as Open Educational Resources (OERs). In this context, “framework” is defined as “a collection of technologies, processes, and practices”. The idea is to create and test a framework that others may be able to use to create their own OERs as part of producing their course websites.

While this project has an initial focus on producing an “open textbook”. I’m hoping the project will move beyond the limitations of the “book” metaphor. For me, an open textbook makes about as much sense as a horseless carriage. In fact, one of the aims of the project is to provide support in the framework for moving beyond an open textbook. For example, enabling the sharing of small bits of the “book”, for that “sharing” to include more than just re-using the finished product, and move more into co-authoring etc.

The starting point (perhaps even core) of the framework will be the Moodle book module. Moodle is the LMS used by my institution. As such it’s the tool I use to teach a course that now consists of 60+ Moodle books. The framework will make it easier for me (and hopefully others) to use the Moodle book within the confines of a Moodle course and to produce OERs.

The framework is required because

  1. the Moodle book module produces material that is not open; and,

    i.e. it only produces resources available from within Moodle. At my institution, this means that only students currently enrolled at the University and at some stage enrolled in the course can access the resources. I’ve had a couple of past students want to access material from the course, but beyond this the content can’t easily be open and generate all the benefits that is meant to bring.

    Beyond getting access to the material the authoring model for the book module is not readily made open. It’s hard to have the collection of books in EDC3100 benefit from the residue of experience of past students. Currently, I attempt to modify the books based on questions and feedback from students. Would be useful to allow them to do it themselves.

    Beyond the students it would be useful for the material to benefit from the expertise of folk outside the course and to be used by them.

    From a slightly more institutionally insular perspective, it would also be useful for books to be easier to share and collaborated on between courses.

  2. the Moodle book module could be enhanced.

    Round trip authoring with the Moodle book module has some space for improvement.

    Even when students can still access the Moodle course site, there are issues around finding the information again. There is no search function. This is a frustration for students (and staff) at the moment.

    There’s limited support for collections of Moodle books. For example, each week in my course takes the form of a “learning path”. The Moodle books – typically at least 4 or 5 a week – outline the path. The current print function can only print a single chapter or all the chapters in a single book. There is no easy way to print a collection of books. Yes some students still want a print version of the information, even though much of it is in a form not conducive to print.

    Currently no apparent simple process for students (or teaching staff) to track student progress through books. At the moment, I’m advising students to bookmark the current page in a book if they have to do something else and haven’t finished the book.

Breaking BAD – the method

The project – like most of what I do – will be use an approach informed by a BAD mindset. That is:

  • Bricolage;

    The focus is on solving existing problems with the tools at hand. i.e. the aim isn’t to identify all the possible requirements, identify some wonderfully perfect future solution drawing on all the latest whiz-bang technology that requires radical transformation of existing practice. Instead, the aim is to address problems facing people right now with the tools that are available. Hence starting with the Moodle book module.

    There’s questions to be asked about whether Moodle is the best place to start this type of project. There’s questions to be asked whether the Moodle book module is the best Moodle module to base this project on. From a context-free perspective, the answers to these questions is almost certainly “no”.

    However, the production of OERs is not a context-free task. From the context within which I set, the Moodle book module is the best place to start. How well it suits others we’ll see. But chances are work on the Moodle book module will be useful to people already using Moodle and the book module.

  • Affordances; and,

    There are two parts to this. First, there’s the more prosaic idea of leveraging the affordances offered by a range of available technologies to provide useful functionality. e.g. forging a link between the Moodle book module and github to offer version control functionality. Second – and perhaps more interestingly – is to harness the protean nature of digital technologies to modify the Moodle book module and its products to ensure that it’s easier for any and all to remix it.

    I’m particularly interested in exploring how the protean nature of digital technologies can be merged with David Wiley’s Remix Hypothesis

    The Remix Hypothesis states that changes in students outcomes occurring in conjunction with OER adoption correlate positively with faculty remixing activities.

    Both in terms of the more standard – the project makes it easier for people (not just faculty) remix OER – but also the more interesting and challenging – the project makes it easier for people to remix the tool used to produce/remix the OER.

  • Distribution.

    How the project might break down the hierarchical walls that inhibit remixing and learning will also potentially take many forms. Providing support for moving beyond the traditional hierarchical distinction between author and readers is one. Breaking down the hierarchical client/server abstraction behind Moodle (and most/all LMS) is another.

  • Product(s)

    The project will likely produce at least the following products:

    1. software and documentation – under the GPL;

      This will most likely be mainly focused on changes to the Moodle book module (or something related). But may involve additional software. It will also include the necessary documentation etc. to support its use.

    2. an open book/OERs based on the EDC3100 course material; and,

      The aim is that the software the project develops will enable the conversion of the course material (based on Moodle books) into OERs of various forms. The question of context specific information in the course material and how generic to make that information will be interesting to explore.

      It should also help the on-going maintenance of the material and perhaps lead to change in pedagogy.

    3. presentations and publications.

      At the very least there will be a presentation proposed for Moodlemoot’AU 2015 reporting on initial analysis of Moodle book usage and functionality (see aim #1 in the next section), identifying potential changes, and asking for feedback and critique. There will also be required presentations at my current institution as part of the requirements of the grant.

      Beyond this there will be other research publications exploring various areas of interest (see a bit below).

    Aims and timelines

    The project comes with four main aims with some associated timelines:

    1. April to July 2015 – Explore the affordances and limitations of the Moodle book module for developing and maintaining OERs.
    2. August to January 2016 – Develop a framework to enhance the affordances provided by the Moodle book module for developing and maintaining OERs.
    3. December 2015 – Test the framework enhance the existing EDC3100 learning materials and produce an open book.
    4. April to January 2016 – Commence and support the integration of this framework into the USQ and Moodle communities.

    The timelines are specific to the grant. In reality, much of this is intended to continue post the grant. If only because I will be using the framework in my own teaching. Some details of what might be done to achieve each of the aims follow.

    Explore the affordances and limitations

    The aim here is explore what people using the Moodle book module are missing and what they enjoy from the module. Also involves becoming more aware of the affordances that are available for producing an OER/open book in terms of broader technologies and practices.

    1. Document the current process for producing EDC3100 “book”.
    2. Analysis of current USQ usage of Moodle book.
    3. Exploration of Moodle book awareness and usage by USQ staff.
    4. Exploration of usage of the Moodle book module amongst the broader Moodle community using a survey and analysis of existing discussions.
    5. Analyse findings to identify broad areas for development.
    6. Present findings at MoodleMoot’AU 2015 and at USQ and encourage feedback.

    Develop the framework

    1. Identify and work with appropriate USQ stakeholders about the project and how to best achieve its aims.
    2. Prioritise areas for change and commence development of the framework.

    Test the framework

    Throughout the second half of 2015 the plan is to use the modified version of the book module in the courses that I’m responsible for. EDC3100 is a course I’ve been teaching for 4 years and has a range of existing resources. EDS4406 is a new course that is about to be developed and taught in the second half of 2015 for the first time. EDS4406 will be using much the same design as EDC3100 and is being developed by a course writer with some oversight.

    Exactly how and what can be tested will depend on local negotiations. The main barrier will be if and how the latest version of the modified Moodle book module can be harnessed in a course that is being offered. There are good reasons why this will probably involve some workarounds to ensure minimum disruption.

    By the end of 2015 the plan is to have at least the EDC3100 material (and hopefully EDS4406) available in ePub/mobi/PDF formats.

    Working with communities

    1. Engage and contribute to the appropriate Moodle forums.
    2. Present findings from the “explore affordances” aim at MoodleMoot’AU 2015.
      Proposals due on 6th May.
    3. Contribution of any changes the Moodle book module to the community.
    4. Share project progress via social media and online development tools.
    5. Presentation at USQ L&T grants showcase.
    6. Production of final report, open book based on EDC3100 material, and materials for S1, 2016 offering of EDC3100.
    7. Artifacts disseminated through the PLAS website and continue discussion regarding institutional-wide adoption of the framework

    Other research

    Beyond seeking to make it easier to develop OERs via the Moodle book the project is also an opportunity to do a bit of small scale research into broader questions about the implementation of e-learning in universities and OERs. Some of the questions I want to explore

    What’s the right balance between course specific and generic?

    The EDC3100 books are specific to the course and its context. It references Moodle, assignments, Professional Experience and other concepts/practices etc that are specific to the institution. These limit the usability and usefulness of the OERs for people not withing that context.

    What’s the right balance between course specific and generic? Can you ever be generic? What implications would have course materials openly available have for pedagogy, for students, for the institution?

    Who is making changes to the LMS and why?

    The Moodle book has been around for quite some time. I’m wondering how much its functionality has evolved over that time. Why? Who made the changes to the Moodle book module? What might be learned from answers to those questions about the evolution and practice of e-learning within Universities?

    How can you break BAD with the LMS? What’s the impact and value of doing so?

    We argued in in this paper that “teenage sex” problem with institutional e-learning is caused by the overwhelming use of the SET mindset to drive its implementation. This project is explicitly trying to use a BAD mindset to help. Can it be done? Or is as we identified in the paper, the overwhelming assumption of a SET mindset too strong to overcome? If it can be, does the BAD mindset help or hinder? What works, what doesn’t? Why?

    Can the “remix hypothesis” and the 4Rs be applied to the systems, not just OERs?

    The 4R framework (again from David Wiley) says that with OER you should be free to

    1. Reuse – the right to reuse the content in its unaltered / verbatim form (e.g., make a digital copy of the content)
    2. Revise – the right to adapt, adjust, modify, or alter the content itself (e.g., translate the content into another language or modify a learning activity)
    3. Remix – the right to combine the original or revised content with other content to create something new (e.g., incorporate the content into a mashup)
    4. Redistribute – the right to share copies of the original content, your revisions, or your remixes with others (e.g., give a copy of the content to a friend)

    The technologies currently being used by institutions to implement e-learning – even open source systems like Moodle – are implemented in ways that limit use against the 4Rs. e.g. my experience is that if you revise the HTML generated by the LMS using JQuery or Greasemonkey you run the risk of being accused of being “dodgy” or “breaking policy”. Instead of being open and protean, the digital technologies universities are using are closed (even if they are open source) and concrete in terms of what teachers and students are allowed to do with them.

    I want break the concrete and explore the benefits of being protean.