[quoting Wild, 14 Nov 95.a] I hardly think these two (LC and constructivism/instructivism) debates can be compared in kind.
I agree. What I was trying to get across was that this is not a black and white field we work in. Too often it seems to me that I hear echoes from Orwell's Animal Farm "Four legs good, two legs bad"--or in ITForum, "Constructivism Good, Instructivism Bad", "Learner Control Good, Program Control Bad." That's not how it is--there is a lot of gray which perhaps hasn't been adequately explored.
It is true that, for most of us, it is respectable to apply one or more theoretical underpinnings to our work (although, perhaps not in the one product/package); but at the highest level, we all have to express a preference for a model of how learning is BEST achieved. And, furthermore, once we have expressed, say, a preference for constructivism, this does not invalidate using instructional strategies that provide for, for example, drill (low level skill learning). This is often our biggest mistake--namely, making the assumption that instructional strategies that provide for low-level learning are necessarily "instructivist" in nature. They are not.
Well said.
[quoting Dalgarno, 14 Nov 95] But if we want to encourage teachers to develop interactive courseware and use it as part of their classes, the tools need to be easy to use. If the tools are too hard to use for the average user then the tools are at fault not the users.
This I would argue is an old idea--what needs to be done (and is being done--is to teach teachers how to use the tools and take advantage of them.
The tools I have in mind will include templates for a range of different types of interactions and knowledge construction tasks. The job of the teacher/developer should be to choose the type of interaction they want and the content they want, and then put it all together without having to learn a programming language.
Again, this is coming in the full circle--and it didn't work last time. When we started (after Assembler and Fortran) a major tool was the Tutor language. When this didn't seem appropriate for the teachers, hundreds (literally) of Authoring Systems appeared which, you guessed it, provided a set of templates so teachers could do all the work. The result? Years of people saying how bad instructional software was. I may have been around too long, but unless you know something about how to make a computer work for you (programming for want of a better word) then you're not going to get far with any application or tool you're interested in. Unless developers are competent programmers, then I say forget it. Even Authorware, which you could argue is "programmerless," cannot be taken advantage of without certain programming skills.
This is perhaps moving off the topic of interactivity specifically--but the functionality of the tools linked with/to the creativity and skill of the developer is a determinant of the level of interactivity which can be implemented.