A copy of a comment regarding the difference between customisation and adaptation, and the importance of the latter to learning content that encapsulates pedagogy.

It is a central argument of this blog that the attempt to apply technology to the improvement of education has been held back by the lack of education-specific software. Such software will generally encapsulate pedagogy. An objection to this approach was recently raised by Peter Twining in a useful discussion on his blog, EdFutures. It is a little difficult to link directly to the part of the conversation where this occurs – the best way is probably to follow the link to the discussion page and then to search for “Re Technology Enhanced Learning”, which is the title of the thread in which this discussion occurs.

To paraphrase the general objection to software that encapsulates pedagogy, such software might be seen as a way of scripting lessons that dis-empower the teacher. At the top level, I would respond that many teachers have a pretty shaky understanding of pedagogy, so the ability to put pedagogically proven tools into their hands is a key way in which we will empower (not dis-empower) teachers (see my Education’s coming revolution). As for the nature of those tools, I certainly accept that the way in which software is used in the classroom needs to be flexible, allowing the teacher (the professional on the spot) to apply the software in the right way. This provides the background to my conversation with Peter Twining regarding the customisation or adaptation of education-specific software.

Peter’s argument is that, according to an OU project in the 1990s called SoURCE, in which he was involved, the pedagogy encapsulated in software often needed to be subverted by the teacher—and that this suggested that the encapsulation of pedagogy was something of a blind alley. I copy below my reply to Peter, followed by my conclusion.

Reply to Peter Twining

It is a little hard to respond in detail, (a) because of the scarcity of project outputs and (b) because of the amount of time it would take. However, working from the SoURCE overview at http://kn.open.ac.uk/public/getfile.cfm?documentfileid=2220, I would make the following comments.

1. Customising content was the objective of the project—so it is not very surprising that it found that it could do what it set out to do. It does not sound as if the project made much attempt to assess the extent to which such customisation was found to be necessary or desirable by teachers and lecturers.
2. The extent to which software needs to be customised will depend to some extent on the quality of the software, the validity of its original objective, and the availability of alternative software that targets the teacher’s preferred pedagogy. An assessment of the significance of the project outcomes will need to start with an assessment of the quality of the software being used and the validity of the pedagogic model that it encapsulates.
3. That said, I think the principle of adaptablility is a very important one. Let me propose a difference between “customisation” and “adaptability” on the basis that the first incorporates a subversion of the original pedagogical intention of the software and the second does not, but represents the application of the software to a variety of different contexts. So your paper quoted above says:

I haven’t worked out what the “Elicitation Engine is yet—but it seems clear to me that the two ways in which you are changing the application of the software represent my definition of “adaptability” and do not represent a subversive “customisation”. “Changing the artefacts that the software is manipulating” represents the application of the same encapsulated pedagogy to a different subject area—this strikes me as an essential feature of any pedagogy-encapsulating software. Second, the use of the Elicitation Engine as either a “reflective tool for students or as an assessment tool for staff” boils down to different ways of using the tool and its outcome data in a wider ecosystem. This too is an essential characteristic of a digital ecosystem built on open interoperability standards, that the student and teacher can play Lego with their software components, modelling different pedagogical processes at the macro scale by different combinations of pedagogy delivered by different software applications at the micro scale. Not all pedagogy is encapsulated in the atomic learning activity—the higher-level pedagogy is achieved by the combination of those atomic elements.

In short, neither of these examples seem to me to represent the customisation of encapsulated pedagogy in way that is subversive of the original intention of the software.

One further point. Customisation by tweaking program code or using software for a purpose that was not intended is likely to be difficult and to cause confusion amongst users—particularly when deployed in a class of 30 who are bound to find out any flaws in the software pretty fast. The example that I quote from your paper illustrates the two principles of *adaptability* which I think are essential:

1. adaptability by parameterised launch (in this case, providing a different list of resources) with parameters being specified in user-friendly interfaces;
2. adaptability by different selection and combination, with these “sequences” and other aggregations of content being created in easy to use, drag-and-drop authoring tools.

Neither of these principles undermine—but rather enhance—the value of software that encapsulates pedagogy.

Conclusion

Since its inception in the 1990s, the Shareable Content Object Reference Model (SCORM) attempted to promote the reusability of learning content (the foremost of a number of qualities that became known in the SCORM community as the “-ilities”. In this, SCORM failed.

In my view, the failure was due to two key problems:

1. an inherent lack of robustness in the SCORM protocols (meaning that one person’s implementation of the specification did not always interoperate with someone else’s and content authored for use in one system could not be reused in another system);
2. a lack of attention to another of the key “ilities”: adaptability. This could be achieved, as outlined in my reply to Peter, both:

• by parameterising content launch (remember, by “content”, I mean activity software, or more specifically, a Learning Activity Platform);
• by allowing the combination of atomic learning activities within sequences—SCORM attempted to deliver this in its series of 2004 editions through an IMS specification called Simple Sequencing, which never worked very well).

Seen against this history, Peter’s point could be articulated as follows: pedagogy-encapsulating software is hard to deploy unless these technical issues are sorted out in a way that allows flexible deployment. A key step in sorting out the pedagogical argument lies in the creation of robust interoperability standards that address the issues that SCORM failed to solve.

Advanced Distributed Learning (ADL, the stewards of SCORM) are promoting the Experience API (xAPI, also known as Tin Can) as the replacement for SCORM. I think the specification shows a lot of promise—but to be really effective, it will need to be embedded in a wider ecosystem of standards. xAPI addresses the reporting of learning activity outcomes but does not address either sequencing or parameterised launch, what I see as the two key aspects of content adaptability that Peter and I agree is needed.

Finally, the prospect of adaptable software that encapsulates pedagogy illustrates another distinction that came up in my extensive discussion with Peter Twining at EdFutures. Peter maintained that one reason why technology needed to be embedded across the curriculum was that technology was changing the essential nature of all subject disciplines. I disagreed. My argument has been that the essential nature of most subject disciplines (including Computing itself) is not changing, but the ways in which those disciplines are applied is changing. What therefore needs to change in the teaching of these different subjects is the contexualisation of age-old principles and not the age-old principles themselves. If you are going to teach vectors, do so in the context of the way astronauts float around in the International Space Station, rather than by the way that sailing ships move through a tidal flow. The ability to vary the contextualisation of learning objectives is an important aspect of pedagogy (I am currently rewriting my earlier post on pedagogy to cover this point more thoroughly). In the context of the current debate about the Computing Curriculum, this point underlines the importance of making the distinction between:

• learning objectives (the end of education that is encoded in the curriculum);
• pedagogical principle (the means of education, at an abstract level);
• teaching practice (the application of pedagogical principle to a particular teaching environment).