Friday, November 28, 2008

Stephen Downes on Modularity (or Learning Objects)

In his comprehensive look forward into The Future of Online Learning, Stephen Downes, takes a look at where we have come over the past 10 years and looks forward another 10 years. (See my other comments on "learning communities" and the "learning marketplace.")

Downes also reviews the idea of "modularity" or what has been referred to as "learning objects." He is not quite ready to abandon this idea even though he acknowledges that this idea has been not been as promising as many thought. In general, he reminds us that the "lego" metaphor has not been useful. So far educational content has not been reduced to small chunks of material that can be easily assembled into larger learning units. He has a couple of ideas that seem to help move this conversation forward. First, he suggests that the reuse of learning objects may need to shift from the teacher's hands to the learner's hands. In other words, he suggests that rather than teachers assembling content and connecting it together, the student collects learning materials and assembles this material for themselves.

He also comments that the size of a given unit of learning is shrinking. Rather than thinking about learning coming in course-size units he writes, "a 20 or 40-hour course may be appropriate in an in-person learning environment, shorter courses are more appropriate online, as short as ten or fifteen minutes."

In the end, he acknowledges, "None of our metaphors, such as Legos or atoms, describe this version of modularity appropriately. I once used the metaphor of objects in an environment....the objects function autonomously, connected, interacting, but not joined." Here is acknowledges Wienberger's idea about "everything being miscellaneous." Although this is true, this does not mean that it is not useful to create particular types of miscellaneous units that can be assembled into largeer integrated structures.

This does not seem to help us move forward. I remain unconvinced that we have either the right metaphor or the right "unit" in which to construct learning. I remain convinced that the simplest learning unit is a "question and answer." This is the smallest learning transaction and could form the basis for constructing larger learning units.


Downes said...

> This does not seem to help us move forward.

Fair enough, but why do you remain unconvinced? For me, the model (which I first wrote about in 2004) propels the idea of free-standing entities - websites, applications, objects - communicating with each other, none contained int he wother, none a part of the other - which is very much the system of REST and APIs and the rest that has developed in Web 2.0 today. So from where I sit, the metaphopr has legs. Which is why I wonder what reason you have for saying it doesn't help us move forward.

> I remain convinced that the simplest learning unit

This may relate to the previous point. But I should be clear, I am not engaged in a pursuit to find the "simplest" learning object, nor do I see any particular value in that. And besides, one person's simplicity is another person's complexity. Consider, for example, the 'simple' photograph. Questions, meanwhile (as Heidegger reminds us) can be enormously complex entities.

Robert Hughes Jr, PhD said...

My use of the word "simple" as a basis for building a structure of knowledge on the web out of questions and answers (FAQS" was a mistake. Downes(and Heidegger) are correct that questions are complex. A more correct word would have been "fundamental." That is, the fundamental transaction of a learning exchange is a student's question and a teacher's answer. Unlike Downes I remain interested in finding a useful building block for constructing structures of knowledge for instruction that can be woven together in increasingly complex ways. Just as an encyclopedia can be built from a series of articles on vaious topics, I think that a learning environment can be build on a series of FAQs.

Mister Meta said...

The perceived value of modularity was a driving force behind the design of Unix. Underlying the decision to make software tools were the speed and capacity constraints of the machinery of the era. I believe that this was a compromise, landing between what people wanted and what they could get through clever optimization - some code, some re-use, not too much space use... Complete solutions like the ones we can now find on Sourceforge seem to be more popular. Rob Pike discusses the lack of traction of this approach in this presentation: