Learning Object Development
This section is devoted to the development of Learning Objects (RLOs), to answer the standard question, "I've got an idea for a Learning Object, so how do I go about producing one?". It's aimed primarily at content authors, and is divided into the following subsections:
- Documents: Various forms (proposal, specification, peer-review, etc) used in the production process
- Examples: Examples of completed specifications which have been used to produce Learning Objects, so that you can see how the Learning Object comes out of the specification
- Learning Objects lifecycle: A brief description of the stages in development of a Learning Object
You can download various forms used in the Learning Object development process from this page. For guidance on how to use them, see the Production Guide.
Below are some example Learning Object specifications and links to the Learning Objects that were developed from them, to give you an idea of how one has led to the other. Specifications are often 'non-standard', in that the author hasn't used a standard form, or perhaps has used a form but has added files with images, data tables, additional information and instructions, and so on. This is particularly the case for authors with graphical imaginations, who often find it easier to draw their own images, either electronically or on paper, than to describe them on paper.
It's important to note that the specification is never detailed enough to develop a Learning Object from, regardless of how much developer and content author try to tie things down before development starts, and that much of the final Learning Object is negotiated between developer and author(s) during the development stage, a process known as 'iterative development' in software development circles. 
 However, the textual content of the Learning Object should be nailed down after Stage 1 Peer-review, not least because this is the basis of the recorded narration and any textual changes would require re-recording of that part of the narration, which in turn requires getting the 'voiceover artist' back into the recording studio and trying to set up conditions as close to that of the first recording as possible so that the new recording doesn't sound markedly different from the original.
Learning Object Lifecycle
Each School Learning Object goes through at least the following stages:
- Concept. Author(s) have idea for the Learning Object, but no specification has yet been written.
- Specification. Specification is in writing, or has been written and is awaiting review.
- Specification peer review. Specification has been written and is under review.
- Awaiting development. Specification has been peer-reviewed, and the Learning Object has been placed in the development queue.
- Under development. Learning Object is being produced in software by the developer.
- Learning Object peer review. The Learning Object has been produced in software and is undergoing peer-review. It may be placed online for use at this point to allow for student feedback, a sort of 'beta testing'.
- Released. Learning Object peer-reviewed and officially released for use.
In addition, some Learning Objects go through a stage of student review pre- and/or post-release.
The lifecycle isn't a straightforward linear progression from one stage to the next, but is rather a highly-iterative process involving constant dialogue amongst developer, content author, and 'mentor' (see below). For instance, the first peer-reviewer may identify errors in the content, and/or suggest content changes to improve the Learning Object, which would then be fed back into the specification document. During development, the developer might propose a particular feature which would necessitate changing the specification, or might identify a feature in the spec which can't be implemented technically. After release, bugs and errors might be found which would require the Learning Object to go back to the development stage (usually such errors are minor and don't require the Learning Object to be further peer-reviewed). And so on. This process is known as "iterative development".
There are usually three roles associated with the lifecycle:
- Content author. The person(s) who write the actual educational content of the object, who are subject experts, and who write the specification, often in consultation with the developer.
- Developer. The person(s) who implement the Learning Object specification in software.
- Mentor. The person(s) who guide the Learning Object through the development process, ensuring that reviews are carried out, technical checks made, and so on.
As with the lifecycle, this represents an 'ideal' situation. In practice, there may be one or more people in each role, and roles may be conflated. Viv Rolfe, for instance, was both content author and developer for her liver and kidney series of Learning Objects.