Let us hope that "ICT" is dead and buried
I agree that software might be used in ways not originally intended - but I do not see that it follows that educationally-focused software "will not solve the problem of pedagogically sound use of technology". Just because you can have a tin which says "just add pedagogy", does not mean that it might not be better to have a tin which says "comes with pedagogy inside". And the fact that you *can* bodge stuff together does not mean that you *should*. And if you find the need to undermine the embedded pedagogy of the original software, does this mean that the original software was not well designed or was inappropriate to the intended purpose?
It partly depends on the sort of software you are talking about - a point that I addressed in my post "Aristotle's saddle maker", at http://edtechnow.net/2012/01/25/aristotles-saddle-maker/. Some software is very generic, some is very application-specific. You could not, for example, used a system designed to handle point-of-sale transactions for doing anything much other than handling point of sale transactions. Whereas a word processor or web browser can be used for all sorts of things. In an educational context, it is the application-specific software that is lacking: at a systems level assignment managers, common markbooks, e-portfolios, learning analytics; at the instructional level, subject-specific creative tools, serious games etc.
Part of the problem with ed-tech is (a) most teachers are not technologically confident, and (b) most teachers are not even very pedagogically confident - they do not read the research literature and I doubt whether there is even general agreement about what pedagogy *means* (see my most recent post - more of a draft than a finished piece at present - on "Five principles of pedagogy" at http://edtechnow.net/2013/05/12/pedagogy/). So what has happened is that ed-tech has proceeded as a kind of local boy scout modelling club - lots of string and sellotape and enthusiasm which *hasn't* really been very infectious. What I am arguing is that we need the education-specific software that works out of the box, puts good pedagogy in the classroom and does not depend on the local teacher to reinvent another bodged-up wheel.
Can you point to a write-up of the SoURCE project which you are referring to?
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.