One of the first tasked tackled in CDLI’s history was the issue of content development. We did not enter into that area cold. Leon, who was initially in charge of content development had, at that point, over a decade of experience in developing content for the web and had considerable experience in developing for print as well. Besides constructing foundation documents and curriculum guides had had been one of the initial leads in developing the handbooks for the legacy model of distance education. By then I had already developed one web-based physics course and one web-based Education course. I had also authored or co-authored approximately 40 physics and math textbooks and teacher resources as well. The other content developers had considerable experience as well. Camilla, Ed and Andre, for example, had been developers of the Legacy model content for French, Math and Chemistry, respectively.
Perhaps, most importantly we were aware of the limitations that existed and worked to try and ensure that these posed no major barriers. To properly set the stage recall that in 2000 there was no YouTube, FaceBook or Twitter. Content Management Systems (CMSs) such as the WordPress (which wasn’t even introduced until 3 years later in 2003) were either nonexistent or very crude. We started with these assumptions:
- The majority of our content would be written in HTML.
- There might be some use of video, but it would have to be low-quality and compressed owing to the lack of broadband connections.
- The content experts would do the majority of their technical production as well so we would use templates.
- Developers would be loaned a PC configured with development tools, which at the time consisted of Microsoft® FrontPage™ (now Expression Web), Corel® Draw™ and Adobe® Acrobat™.
We first acquired a server to host the content that was under development, a ‘dev server.’ This was a fully-functional IIS-based server but was not intended to host the content for broad consumption. It was, rather, a safe holding ground for content as it was developed. Once ready, developed courses would be copied over either to our main web server or to the content area of our Learning Management system (LMS) which was, at the time, WebCT. Each content developer would be given access to a course folder on the dev server and all prepared content was expected to be uploaded there.
Next, we met as a team of developers and discussed our needs and ideas for class learning activities. Based on this, Leon prepared a generic course development template.
The basic building block was the course. The curriculum used in any given course would be exactly as described in the curriculum guide document issued by our sister unit—the program development division. This meant that we were not in the business of Curriculum design/development but, rather, in the business of Instructional design/development.
In any given course, the topmost organizer was the Unit. Typically these would be described in the curriculum guides. Sub-units were referred to as ‘sections.’
The basic and most important organizer was the Lesson. This was intended to be a complete learning experience that encapsulated one or more specific learning outcomes. We divided each lesson into five components, and the content templates had five tabbed pages:
- You Will Learn: A list of the curriculum outcomes for the lesson but re-worded so that they would be understandable to students. Curriculum outcomes from guides are written for teachers and often contain jargon; we fixed that to the extent we could.
- You Should Already Know: A list of items that students were expected to know before starting the lesson. We did not necessarily try to reteach this. Mostly we just listen the items and, perhaps, linked back to the lessons where they would have been addressed, if appropriate.
- Lesson: The actual learning content. Typically this consisted of text and graphics. In my course, grade 11 physics I included objects created using Macromedia® Flash™ as well.
- Activities: As the name suggests, these would include additional items the student would do. In my physics course, for example, these tended to include practice questions and problems.
The navigation structure used in the templates was based on HTML. We were careful not to use any server-side assists such as the MS FrontPage Extensions that could have been added. While these would have made the job of creating the templates much easier in the short run, in the end they would have made server maintenance impossible and would also killed interoperability with other systems.
We enforced good practice. Each course had its own folder. Within that were nested the remaining levels of organization. This means that, in the end, every lesson had its own folder and we required all developers to ensure that all assets used in a lesson (audio and video files, images and such) were to be placed in the lesson folder. This meant that each lesson stood alone and that moving it would not result in broken links and images. Best of all, this also meant that moving the content in and out of the LMS was straightforward.
It also might be of interest to the geeks among you that we started using CSS right away. All content formatting for the entire enterprise was based on a single CSS file. This meant that we could later update the look and feel of the content by just editing that one CSS file.
Here’s a few things we warned content developers about:
It’s also worth noting that not all content developers played by the rules. As someone charged with administering, and of course, correcting, this, here are two things I found particularly troublesome. First, not everyone placed the objects where we asked them to. It would not be unusual, for example, to find images used by any particular lesson in the root ‘images’ folder for the course and not in the folder for that lesson. This meant that if we updated and copied that lesson folder back to the LMS later on the image would be broken as the link would no longer be valid. How many hours did Ken Penney and I spend checking for this! The second annoyance was the insistence by some in getting fancy with the formatting and straying away from the template. For Ken and I this meant three things:
- We would have to look at what was, sometimes, some pretty ugly stuff. Just because Black and Yellow contrast well doesn’t mean you should drop our colour schemes and use that instead!
- We would lose time dealing with hard-to find inconsistencies. Just because the lesson looked great back on your PC doesn’t mean that it will look as good later on. My biggest beef: people writing in MS Word and then pasting it right into FrontPage. The geeks among you will know that this results in a boatload of inline styles which cannot be overridden by the main CSS and which stubbornly resist your efforts to fix it until you…
- …lost a fair bit of time stripping away ALL of the formatting added by the developer and then just going back and doing it all over again yourself. This takes a lot of time and while it’s the most efficient way of getting rid of all the formatting crap it also gets rid of the stuff you needed to keep—you lose headings, superscripts and subscripts, for example and have to go back in and restore them.
So, for our stock HTML-based content, this was the process the developers were supposed to go through:
- Spend the appropriate amount of time developing the course structure. As manager I expected this to take several weeks. In the end I expected a written document which listed all the units and sub units and then lessons. For each lesson I expected the list of specific curriculum outcomes addressed, along with a brief, one paragraph description of the instructional plan for that lesson.
- That course structure would be examined carefully and developers would be warned that they needed to get this straight. Appropriate changes would be made before proceeding.
- Leon, and later Myself or Ken would use the course structure plan to create a development template on the dev server. This template would contain folders for the units and folders containing ready-to-use pages for all of the lessons. These would be appropriately titled and linked. At this point, major structural changes would only come with great difficulty.
- The developer would be given access to the course folder on the dev server and would proceed to create the course. From time to time Leon or I would check on the progress.
- When the developer indicated they were done we would schedule a review of the content, lesson by lesson. A report detailing suggested changes would be given to the developer who then had three choices: (a) make the changes as suggested, (b) make a different change; one they we agreed was better or (c) do nothing—if this was chosen, the developer was expected to defend this choice.
- With the course finalized, the course folder would be locked from further access and the content would be copied over to the main website and copied into the appropriate course in WebCT.
- If further edits were needed later on, these would be done on the dev server and the copying process repeated. That is, the ‘master copy’ was assumed to be the one on dev.
By 2004 we had 30 full courses developed. While the material was prepared primarily for the distance educations students we also copied the full content over to our main website and made it available to all students and teachers in the province.
|Acad. Math 1204/2204/3204/3103
Adv. Math 2205/3205/3207
Art & Design 3200
Art Technologies 1201
Biology 2201/*(3201 came in 2005)
Canadian Economy 2203
Canadian History 1201
Career Exploration 1101
Comm. Tech. 2104/3104
|English 1201, 2201, 3201
Experiencing Music 2200
French 2200, 3200, 3201
Integrated Systems 1205
World Geography 3202
List of courses offered in 2004-05. Note course numbers ABCD: A(1-3) means g10, 11 or 12, B=#course credits, C=0 means no mods from curriculum guide, D=way to distinguish 2 similar courses. Note also that Comm. Tech. was taught as one linked 2-credit course instead of as two single credit courses.
Overall our user experience with the content was spotty. In some cases the online materials were used often and in other cases not. In the interest of brevity, here’s what we concluded:
- CDLI Students only used the content if the eTeacher used it and referred to it in class.
- eTeachers who had a hand in developing content tended to user it; this, in turn meant that their students used it too.
- Non CDLI teachers and students tended to make great use of it. Sometimes it was used as the basis for lessons, sometimes it was a supplementary, especially in classes where more than one course was being taught at a time and sometimes it was used as homework or review.
- The original 5-tab template was later compressed down to two. We found that the students rarely used the ‘You Will Learn’ and ‘You should Already Know’ tabs so in later versions of the template we compressed the five down to two: “Get Ready” (which listed outcomes and prerequisites) and “Go to Work” (which had the lesson activities and assessments). Here’s a sample Chemistry lesson.
- Many students, when asked, told us they wished it was less wordy and that there was more use of multimedia.
Next: In late 2002 we discovered how to use Techsmith’s® Camtasia™ and about a year or so later Adobe® Captivate™ and started developing a new kind of learning content. We enjoyed great success using the Multimedia Learning Objects, or MLOs as we came to call them.