VLE Report 2015/Participatory features
This page is part of the VLE Report 2015.
Moodle arose in a context valuing collaborative features in education and software development, under the slogan "The use of Open Source software to support a social constructionist epistemology of teaching and learning within internet-based communities of reflective inquiry". On the other hand its social constructionist credentials are not found so distinctive these days. Wikimedians have a more thorough-going vision of participation, and one member of the Education Committee looked to "refocus the VLE to be more conversational".
Summary[edit | edit source]
In the end, the proposed innovations around MediaWiki+Moodle were not delivered. The VLE was largely the work of a single author, Charles Matthews, though some material written by John Broughton was adapted. Attribution credits are given at the beginning of each lesson. Moodle, as with OER systems generally, is quite weak on the metadata side.
The CC-by cascade[edit | edit source]
On Wikipedia, a simple copy-paste move of an article can provoke horror. As if it were parenticide, which metaphorically it might be. This is a striking example of Wikimedia culture, and requires explanation, because the world in general has to work hard to see the point. It is not clear that Moodle does.
In terms of educational material, the VLE does not exhibit "mashup" characteristics; which on the other hand are common in primary and secondary education as a way of adapting teaching material rather than constantly reinventing the wheel. Wikipedia is quite strict on plagiarism, the English Wikipedia having a guideline on it ([[w:Wikipedia:Attribution]). As is well known, plagiarism is rife in higher education, to the extent that institutions have to process submitted work systematically even to keep it in check.
It has been plausibly been argued that consciousness of the need for attribution is too low, in secondary education for example, even on the teaching side: and that therefore pupils do not acquire the right attitude by the time they are supposed to produce original written work at universities. Whatever the merit of this claim, OERs do not always carry attribution metadata. As soon as collaboration is introduced the problem is exacerbated.
Look now at Wikipedia practice when two articles are merged. In theory, attribution is preserved, because:
- The merging editor is supposed to announce the mergefrom article's name in the edit summaries as its content is added into the mergeto article. The edit summary is free text, not searchable or updateable by editors.
- Failing the edit summaries, the merge may have been formally announced with templates "mergefrom" and "mergeto".
- With the two merged articles identified, the authors and so attribution may in principle be recovered from the page histories, as a list of account names and IP numbers.
The caveat of "on principle" includes the following point: pages may have been partially merged, earlier, into those pages being merged. There are as many page histories to scrape as there are pages that have been combined.
The idea of the "CC-by cascade" reflects the complexity of the history of well-used educational material, constantly adapted and update. The requirement of tracking attribution becomes an overhead. So one conclusion from contemplating the metadata situation in Moodle is that MediaWiki, somewhat better, does not have the perfect solution:
- there is a need to encapsulate the cascade of attribution so that the social asset of collaboration does not become an administrative millstone round the neck.
To sum up: setting a good example on plagiarism includes a technical issue to address. This is also a social issue, because it involves recognition.
Transclusion[edit | edit source]
Transclusion is familiar in the Wikimedia world because it is, at least, the principle of the template, the ubiquitous workhorse that allows for efficient and compact working. Moodle does not offer templates: within a course any unit can be duplicated, so in that sense "write once, use many times" is possible. But this is more like substitution: it doesn't offer retrospective revision everywhere.
Transclusion was one of the neologisms of Ted Nelson. Moodlers seem to prefer "embedding". In any case the idea is that a chunk of HMTL on one page is copied into another page, as such. The idea, which was not novel as such, was to use transclusion from a dedicated wiki (ModuleWiki) to the VLE in a controlled way, to allow the community on ModuleWiki to modify, expand or write from scratch material on the VLE. There is more than one method that would allow this.
Options for transclusion all have some issues to resolve. They include:
- Use IFRAME on permalinks (i.e. links to old wiki page versions). This turns out to be the original method as used on WikiEducator. The use of IFRAME, which is poorly supported on browsers and a reputed security risk, was rejected already in 2012.
- A transclusion module more generic than Jan Luca's, on permalinks.
- A transclusion module as before, but with flagged revisions.
- "Live" transclusion, namely direct transclusion of a wiki page by a module. This was ruled out because it would permit vandalism of the VLE by any passer-by on the wiki.
So the choice of methods came down to #2 versus #3. The point here is about community factors. Editing rights on the VLE would be given to a tightly restricted group: edits to Moodle cannot be reverted (the major distinction from Wikipedia on versions), and backed-up versions are the only ones saved. So for collaboration you want the larger group to be on the wiki, and a skeleton staff on the VLE. Flagged revisions is the more complex solution, but it also allows the major editorial decisions to be taken on the wiki. In detail, anyone at all can edit the wiki pages, but only a select group can approve an update. With editorial control then lying outside the VLE, participation is set higher than for permalinks, where an editor on the VLE must be the one who changes the permalink, a clumsy hand process.
Whether #2 or #3 were chosen, there would still be a full wiki page history to consult. No version on the Moodle page would therefore be lost. Further, attribution could be given as for Wikipedia, in the way discussed in the previous section.
None of this was tested in practice, given performance issues with the transclusion module. These remain unexplained, and have not been tested out since 2013.
Editorial control[edit | edit source]
From a social point of view, who dictates the content of the VLE would appear to be the ultimate issue. On Wikipedia, which proved a false analogy, it certainly is. No controversy having arisen, it appears there is no case law; but the WMUK office would control it as an operational matter.
The wiki front end[edit | edit source]
The design proposal was based on the idea of a wiki front end, set up so that logging in to the VLE would be on the pattern of logging in to Wikipedia, or other MediaWiki site. Those using Moodle would normally do so under the direction of a tutor who would enrol them in a particular course, and put it in context. This was not the intended way the VLE would be used: so ModuleWiki was intended to offer general introductory material, and access to any lesson, via a single sign-on (SSO) module. The SSO module was got working in the WMUK hosting.
Feedback pages on ModuleWiki were also provided, so comments on the lessons could be recorded in a public way. Moodle has an internal wiki, and internal messaging functions. Neither of these was an intended part of the system, the wiki because it has few features, and the messaging because it could be used for trolling.
Proposed integrated system[edit | edit source]
The proposed system of SSO and transclusion was envisaged as a site where three groups could work together on course material, for study, discussion and development of fresh content. The feedback system would mean that you could discuss the course material (without any login, if unregistered) as an editor on ModuleWiki; and with others on User talk pages. The transclusion system would mean you could make proposed changes to Moodle versions. The flagged revision system would mean a select group could update the content actually seen on the VLE. A small group would adminstrate the VLE.
In practice only some of the VLE would be open to revision at any time, the rest being kept stable. Unlike Wikipedia pages, educational material benefits from measured changes, rather than many small increments and tweaks.
This possibly utopian vision of a community at work can at least be compared to better known one, such as the cMOOC of George Siemens.