Learning Objects


Curriculum units can be made smaller and combined with each other, like standardized mechanical building blocks, into a great variety of programs—custom-made for each learner.

—Ralph Gerard, 1969

Break it into a thousand parts,
Yet the part is still heart-whole.

—After Shakespeare, As You Like It, 1599

Definition: The Vision of Reusable Content

A new model for digital learning—one in which learning content is free from proprietary "containers," can flow among different systems and be mixed, reused, and updated continuously—is inching closer to reality. At the center of this new model is the learning object, the modular building block.

—Tom Barron, 2000

A learning object is a chunk of course content that can be reused in another course. It can be a paragraph, a page, or an entire lesson. An "object," in systems talk, is a "component" and learning objects "modularize" courses so that they can be re-assembled into new courses faster and cheaper. Thus learning objects function like instructional components or modular building blocks for the world of courseware. When properly designed, they constitute the fundamental "atomic particles" of the curriculum, its core components. As we will find out, however, not all courses are created equal; some contain learning objects, but many do not. Here are two examples of learning objects:

  • Company A recycles a process called "Steps in Selling" from a course called "Introduction to Selling" into another course called "How to Close the Sale." The process won't change, so it can be reused in the other course with no alterations.

  • Company B reuses an ROI formula from a sales course called "ROI-Based Selling" in another course called "ROI-Based Performance Consulting." No change to the formula is necessary; it can be recycled as is.

In both cases the chunk of content is lifted from one course and recycled in another, in a plug-and-play, drag-and-drop kind of "learning universe."

Origin and Rationale

A set is a collection of definite, distinct objects, which are elements of the whole.

—Georg Cantor, German mathematician, inventor of set theory and godfather of object-oriented programming, 1874

Code objects let you create applications quickly, easily, and visually, including drag-and-drop control and codeless creation.

—Microsoft advertisement for its object-oriented Visual Basic, 2000

The origins of learning objects lie in the object-oriented programming movement of the 1970s and 1980s (also called structured programming). The dream of object-oriented programmers was to write code in clearly demarcated and indexed paragraphs called "objects," which could then be recycled into new programs. The vision was a compelling one, and by the early 2000s, learning strategists, information architects, and course designers caught the spirit and starting promoting the concept as a faster and cheaper way of designing and redesigning courseware. The goal was to create reusable, recyclable content, analogous to programmers creating recyclable paragraphs of code.

Perhaps the best way to describe how learning objects function is to think of them as layers in a hierarchical system, the overall system being the curriculum. The different levels or orders of the system correspond to the size or granularity of the "learning objects." If we use the analogy of a book, this becomes quite clear:

A Book Analogy

The Curriculum

Systems Theory

Entire book

Course

Superset

Chapter in book

Lesson Module

Set

Page in chapter

Page

Subset

Paragraph on a page

Paragraph

Element

Don't Confuse the Two Types of Learning Objects: Content vs. Code

When "objects" made their unobtrusive journey from backroom programmers to front-office knowledge designers and information architects, they subtly shifted their ground of reference: They went from being "code" objects to being "content" or learning objects. This has caused a considerable amount of confusion as well as set false expectations in the industry.

To explain the difference between code and content, let's take as an example a sales course written in Microsoft Word. If you're a programmer, there will be a host of code objects (subprograms) in the Word program that you could reuse (if you labeled them properly). But if you're a learning designer, there will be at most only a few concepts, checklists, and processes that you will be able to salvage in terms of content. Code is recyclable because it is explicitly designed as a set of discrete, highly structured elements: it is modular and its subsets are capable of being dragged and dropped into another course. For example, here is a chunk of Visual Basic code that is a recyclable programming "object" (it tells the program to shut down when the user clicks "exit"):

  1. Private Sub cmdExit—Click ()

  2. Unload Me

  3. End Sub

You can copy and paste this piece of code ("sub" stands for subroutine or subprogram) into your next program, and it will still perform exactly the same, for the three lines are a self-contained subprogram. Text, on the other hand, functions quite differently. Take as an example the plain sentence:

start sidebar
Technology Standards and Interoperable Learning Objects

Learning objects need to be shared among different databases and various learning management systems, and thus standards for their platform "interoperability" are absolutely essential to their proper functioning. Steps are already being taken in this direction. Programming languages such as XML—extensible markup language—and government standards such as SCORM—the sharable "content objects" reference model—are already working towards this goal. The vision is that all course content will be free of proprietary "containers" and will be able to flow freely from one course to the next. In systems terms this means an open architecture with cross-platform inter-operability.

end sidebar

When you're with a customer, always be sure to qualify them first.

Will you recycle this sentence verbatim for the new course? Probably not. You may recycle a job aid associated with this point, such as a checklist of qualifying questions, but this particular sentence (representative of much text in a course) will probably be rewritten. Attempting to label, classify, store, and retrieve this and similar sentences is simply not worth the time and effort involved. Rewriting, (rather than recycling) is in many cases the more efficient and economical route to go. And a great deal of content falls into this category.

Words and code are not the same. If words were as discrete, specific, and modular as code is, we would be writing software programs in words. Words and sentences, however, are not stand-alone components; they are always contextually embedded in the discourse itself, anchored through syntax, narrative flow, and a semantic web. Thus text is seldom recyclable as is, and usually requires rewriting. To make this point clearer, let's take a look at the contrasts between words and code:

Word Objects

Code Objects

"learning" objects

"code" objects

data (content)

programs (containers)

embedded

independent self-contained subprograms

contextual

context-free

flow of sentences

discrete sections of code

In short, you can't merely grab content objects as "bleeding chunks" (as one critic put it), and hope that they will fall effortlessly into place in some new course. The whole reason for updating a course is generally to update the content, which means rewriting it. Although this point may seem obvious, many companies, caught up in the zealous pursuit of learning objects, seem not to understand it. There is a fundamental difference between content and code. The occasional pieces of content that can easily be recycled (a logo, a corporate mission statement, a company process, etc.) are often apparent to the point of being trivial, and there is no need to mount a heavy theory of learning objects to implement their recycling. When it comes to the more complex content, however, companies need to clearly determine whether it is appropriate to recycle, or whether recycling would take more time and money than it is worth.

How to Build Learning Objects

Now that we've issued all the warnings and laid down the necessary distinctions, here are the steps necessary to implement learning objects.

The Six-Step Process for Building Learning Objects

1. Craft

(Note: This step creates learning objects from scratch as you are building the course. If you built a course without learning objects in mind and are now trying to determine if there are any learning objects in it, go directly to Step 2.) First, you must craft the course. This step is often overlooked, but the actual writing of "componentized" courses is a different art from writing normal courses. Learning objects will be easier to recycle if your courses have been planned and written this way. The writing should be in discrete (separate) paragraphs ("objects") and in the appropriate style. Here are some rules of thumb for writing recyclable paragraphs:

  • Write in a standardized corporate style so that the pieces will fit better together and the style won't jar. Think of the way the digital telephone operator pronounces numbers when you call information, using a flat robotic voice, so the numbers will mesh. Think "standard, neutral tone" of writing.

  • Be brief, perhaps less than 250 words or one page. Having said this, it is a given that we all have our own definition of how long a learning object is.

  • Pretend you're writing a "hyper-linked" story, meaning write each "learning object" page as a stand-alone. Think in terms of discrete chunks, not narrative or logical flow.

  • Always remember that the whole point of learning objects is to recycle elements in order to save time and money.

2. Choose

Next select the parts of your course that are most likely to be reused. Definitions, processes, and company checklists are among the information types that are "less volatile." Products and services courses are less likely to have stable content.

3. Chunk

Chunk the selected course parts into layers and components of layers, similar to a hierarchical outline (don't be confused by the technical words for this phase—decomposition, deconstruction, componentization, and modularization—they all mean the same thing). In doing this, you will be determining at what level of granularity learning objects will be defined. Some companies refer to lessons and modules as learning objects, others to paragraph-level or even Webscreen-sized chunks. Obviously the size of a "learning object" lies in the eye of the beholder. Take your pick and stick with it.

4. Classify

Next classify the components, labeling each of them appropriately in accordance with the naming conventions that you set up in conjunction with your IT department (and their indexing system for the database). Learning objects must be meta-tagged—listed in a master index under keyword, subject matter, media, audience, and so on (these are equivalent to the fields or attributes listed in a database)—if they are to be readily retrievable in the future. The entire process is a form of knowledge management.

5. Configure

Set up the database schema (outline or model) for the ready storage and retrieval of the components.

6. Catalog

Finally, import the components into the system ("populate the database").

Conclusion: Getting Real

This is a utopian goal: travelers should approach it with caution.

—Walker and Hess, Instructional Software, 1984

Learning objects will work for you, as I have said, if you proceed logically. To help set you on the right path, there are two strategies you can adopt as you follow the six-step process above, namely the inverse law and the 10-percent solution.

The Inverse Law

This strategy derives from an old saw: "'Faster, cheaper, better'—pick any two!" This is particularly true for learning objects, for if they theoretically create curriculums "faster and cheaper," they probably won't create curriculums that are also "better." The new courses, made from recycled parts, may be sufficient, but their quality will probably be that of, say, generic off-the-shelf courseware. This may be appropriate for some courses, but not for others. Implementations of learning objects necessitate a simplification of courses and usually will imply a lowest common denominator in terms of quality; expect this, and you will not be disappointed.

The 10 Percent Solution (and the Usual Warnings About Techno-Utopianism)

This strategy consists of telling yourself that you'll be happy if you can recycle 10 percent of your courses. It would be foolhardy, for instance, to expect content to remain so stagnant as to be 50 percent recyclable for next year's courses. As you proceed with the recycling process, keep a rough log of what percentage and what types of content you actually do rescue from past courses, continue to correct your expectations, and celebrate the small triumphs. And be sure to push back on any techno-utopians in your organization by reminding them that it's easier to create object-oriented code than object-oriented content (and ask them how they're coming with their own object-oriented programming efforts). Get real, have fun with learning objects, and don't let anybody push you around.

start sidebar
What's in a Name?

Learning objects go by a variety of names, including the following:

  • Content chunks

  • Content objects

  • Info-nuggets

  • Infotrons

  • Instructional components

  • Instructional objects

  • Knowledge components

  • Knowledge objects

  • Knowledge quanta

  • Learning nuggets

  • Learning particles

  • Repurposed content

  • Reusable information objects (RIOs)

  • Reusable learning objects (RLOs)

All of these refer to the same thing.

end sidebar

Fastpaths

1874

German mathematician Georg Cantor invents set theory, including the notion of "objects"—which will become the theoretical basis of object-oriented programming a full century later.

1966

Ole-Johan Dahl and Kristen Nygaard: "Simula: An Algol-Based Simulation Language," Communications of the ACM 9 (1966): 671–678. One of the first articles on the need for object-oriented programming languages. Authors' "algol" language was a forerunner of such object-oriented languages as C++, which was developed at Bell Labs in the 1980s. This "object orientation" would pass directly into the thinking about learning objects in the 1990s.

1969

Richard Atkinson and H. A. Wilson (eds.): Computer-Assisted Instruction. One of a number of (still very relevant) structured programming books on CAI from the 1960s and 1970s. Contains the 1969 article by Gerard, "Shaping the Mind: Computers in Education," from which the motto at the beginning of this section is taken.

1970s

Growth of object-oriented programming (paralleling a related wave of object-oriented "new math" teaching at the time).

1976

Franklin DeRemer and H. Kron: "Programming-in-the-Large vs. Programming-in-the-Small," IEEE Transactions on Software Engineering, June 1976, pp. 80–86. One example of the many articles in the 1970s promoting structured, recyclable programming, whose ideas are still absolutely relevant and applicable today. Programmers should work with standard components, programming in the large, with a decreased need for programming in the small; they should program on the level of the "forest," not individual "trees."

1982

Anthony Wasserman and Steven Gutz: "The Future of Programming," Communications of the ACM; reprinted in Walker and Hess (1984). Compelling argument for reusable learning objects in programming.

1983–1985

Object-oriented programming gains headway; the language C++ is created at AT&T's Bell Labs.

1984

Decker Walker and Robert Hess (eds.): Instructional Software: Principles for Design and Use. Like the Atkinson anthology, still relevant today.

1990

David Schneider: Microsoft QuickPascal: An Introduction to Structured and Object-Oriented Programming. For programming types only; helps explain the theory lying behind learning objects.

1990s

Object-oriented databases are developed (as opposed to relational databases). The decade also saw the development of more object-oriented programming languages beyond C++, namely Mac's Hypercard, Microsoft's Visual Basic, and Sun's Java.

1990

Won Kim: Introduction to Object-Oriented Databases. For programming types only; helps explain the theory lying behind learning objects.

2000s

"Learning objects" are promoted as a faster, cheaper way of designing and developing online courses.

2002

David Wiley (ed.): The Instructional Use of Learning Objects. Useful, if academically-oriented, articles on learning objects by various hands.

See also Electronic Performance Support Job Aids Knowledge Management




The 30-Second Encyclopedia of Learning and Performance. A Trainer's Guide to Theory, Terminology, and Practice
The 30-Second Encyclopedia of Learning and Performance: A Trainers Guide to Theory, Terminology, and Practice
ISBN: 0814471781
EAN: 2147483647
Year: 2002
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net