Let us hope that "ICT" is dead and buried
Both the SoURCE website (www.source.ac.uk) and the OU's Knowlege Network (where many of the outputs from SoURCE are located) are currently unavailable. Check out [] and search for SoURCE ...
Our experience was that even with software specifically designed to embed pedagogy, and where we explained how to use the software to teachers (actually lecturers in HE), they often undermined the pedagogical model.
Hi Peter, Sorry for slow reply - only just found this comment.
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 - so 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 how well it met its original requirements.
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 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:
"Thus, for example, you can customise the Elicitation Engine by changing the artefacts that it is manipulating and/or by using it as a reflective tool for students, or as an assessment tool for staff to identify students’ misconceptions".
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 "adaptability" and not a subversive "customisation". "Changing the artefacts that it 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.
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 cause confusion - particularly when deployed in a class of 30 who are bound to find out any flaws in the software that exist. The example that I quote from your paper illustrate 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.
You are quite correct Crispin that customisation within SoURCE did NOT involve changing the pedagogy embedded within the software. The ability to customise the software for use in different contexts (e.g. with different artefacts for 'sorting') was part of the software design. This was not where the problems occurred.
The problems were when someone came to implement the use of an instantiation of software that had already been customised. For example: Elicitation Engine (EE) Shell - customised by adding some artefacts => An instantiation of the EE. This then gets used in some teaching context. It is at this point that the pedagogy is undermined - for example by the 'teacher' telling the students what categories to use to sort the objects rather than expecting them to come up with their own categories.
This sort of undermining of the pedagogy that was designed into the software occurred frequently in our experience, even when the teachers had engaged in professional development that was intended to help them understand how the software was designed to be used. They used it in ways that fitted with their existing pedagogical practice by and large - rather than the pedagogical practices designed into the software.