Sometime during 2002 Mike Mooney and Perry Ward at Memorial’s PDCS showed me a Polycom videoconferencing unit they were evaluating. Up until that time they had mostly been using Intel Team Stations for videoconferencing but had discovered some of the products from that company and had decided to evaluate them. Their initial findings were positive and they shared what they had found with me. I was quite intrigued as well and they arranged it so that I could also have a look at the equipment they had obtained.

Frank and I had a chance to take a good look and our initial impression was very favourable. We had several issues that might be solved through the use of the equipment. First, CDLI’s management team was divided approximately half and half between St. John’s and Gander. While we were able to conduct most of our live meetings using vClass, the software we were using for our synchronous classes we had a need for video and, at the time, good video was not supported. In addition, the Labrador School district had much the same issue with two separate board offices separated by hundreds of kilometres of dirt roads. In both cases we had to spend considerable time and money in travel between the two centres.

We discussed this among ourselves and decided to tender for four units. We placed one in each of the four locations: St. John’s, Gander, Goose Bay and Labrador City. It took a bit of configuration to get them up and running but once we did the effect was immediate. The frequent trips stopped; not because people were ordered to stop traveling, mind you, but because people decided for themselves that most of the trips were no longer necessary. As Frank Shapleigh says, “I considered giving up my Costco membership because I wasn’t driving to St. John’s every other week for work anymore.”

Once we got comfortable using the systems for meetings between members of the leadership team we began thinking in terms of what new pedagogical tools we now could bring to bear. We immediately thought of the art courses we had and of the then fledgling experiencing music course we were developing. Good quality two-way video and audio meant students and teachers could now see what one another were doing. The experiencing music course had a small performance component and it was obvious to everyone what were the benefits to both students and instructors in this area. Likewise in art the instructors now could provide instant feedback on technique rather than doing it indirectly by looking at finished or partially finished pieces. So much better to see how things were done rather than looking at the end results!

We therefore began outfitting the student endpoints with videoconference units, starting with Art and Music sites. Soon after, Tech. Ed. was layered in and from there we continued to the remaining sites until, eventually, every distance education school was equipped.

Stubborn technical issues came early on. Videoconference units are not the kind of things you plug in, turn on, and expect to function, just like that. It took a lot of work getting the systems to work reliably.

“But what about Skype,” you ask. “All I have to do is install the software and get a user account. From then on all I have to do is call people on my contacts list and it works.”

True enough, but there are several things about Skype:

• The video is generally crappy and unreliable.
• The audio is generally crappy and often garbled.
• It is generally not permitted on enterprise networks owing to the many security risks it brings.

To get videoconferencing working on networks you have to get the IT managers onside.

• The system has to be given a fixed IP address on the network. This may be done by statically assigning it internally or by dynamically assigning a fixed IP based on the unique Media Address Control (MAC) that every networked device has. What’s more, each IP address on the virtual private network (VPN) has to be mapped to a bona fide, Internet-facing IP address so that equipment outside that VPN can communicate with it.
• The firewall on the network has to be made aware of the system and has to correctly pass the network traffic intended for the videoconference unit. This generally involves  ‘port mapping’ or IP mapping. If that’s not complicated enough, many VPNs actually use more than one firewall. Getting videoconference traffic successfully through a pair of firewalls can be very tricky.
• When in use the devices use a large amount of bandwidth and the network has to be designed to give priority to the audio and video streams when necessary.

In theory, doing those things is straightforward enough from a technical perspective. Firewall and router settings are just table entries and systems administrators can do them easily enough. In reality, though, it’s just not that simple. School districts are all separate entities, each with their own policies and procedures. Furthermore there are other organizations that need to be in on It as well such as post-secondary schools that also may need to use the system. Some of the technical services are managed by third parties and, unfortunately, many of the interconnections between those district based VPNs can be through the public Internet (also known as the wild, wild west). In reality, getting the settings done took a lot of time and effort. There were quite a few growing pains encountered along the way. The various computer networks are segmented so throughput across the networks was often difficult. Worse, getting videoconference traffic from one network to another often resulted in one-way or low quality transmissions.

Generally the distance education classes went reasonably well enough because both students and teachers needed it to work and stuck with it until it did. The issues were solved and things stayed that way. Unfortunately, many of the early events we undertook that primarily involved adults did not fare so well. The adults had much less tolerance for fault in the early stages and, when they encountered the early growing pains, they were left with the impression that the system did not work. Many, unfortunately, gave up on it and never came back, even though the technical issues have been solved for years now.

In time, most of these issues have been solved. Some still remain. The two schools served by satellite-based Internet find the quality is not great. Since the signal must be bounced on a two-way trip of to a satellite located about 22,000 km above the equator there will always be a delay of approximately 0.8 seconds for the video to make the round trip. This makes the conversation a bit stilted. Our sites on frame relay do not have a whole lot of bandwidth to spare and find that videoconference sessions tend to result in general network congestion at the school so we only use it sparingly at those sites.

Videoconference units are, by default, point to point. That is, you can only call one other site. This poses a problem as many of the useful applications for teaching are multipoint in nature; that is, the instructor generally likes to combine several sites.  For a considerable extra cost many, but not all, videoconference workstations can be upgraded so that they can connect to more than one endpoint. Three plus one (3 + 1) is a common multipoint configuration. A videoconference unit that is 3 + 1 enabled is capable of connecting to three other units. In such an arrangement the users see all four locations arranged ‘Hollywood squares’ style. Usually the 3 + 1 unit is configured so that if one site speaks for an extended period then its video grows to occupy all of the screen and remains this way until that location goes silent and someone speaks at another location. When this happens the system reverts back to ‘Hollywood squares’ unless that speaker goes on for an extended period.

At first we equipped the instructor sites with units that were 3 + 1 capable so that they could bridge in as many as three different locations at a time. Generally this was good enough but not always. Some classes were comprised of more than 3 school sites. When this happened the instructors would have to break the class up and bring them on in parts.

In time we were able to purchase a videoconference bridge. This was a device whose purpose was to combine multiple sites so that the users’ own equipment did not have to do it. The first unit we purchased was able to work with any number of combinations up to a total of 32 sites. At maximum capacity, for example, we could run a large class with 32 sites or, more reasonably, 4 classes, each with 8 sites online and so on.

We rarely ran the ridge with large groups as our teaching model did not leave us with classes comprised of large numbers of sites. Typical classes have around 20 students and the number of sites is typically between 3 and 7. Very large sessions were something we used for special occasions. Some examples included:

• Schoolstock: a yearly ‘battle of the bands’ event held for several years in  the mining town of Buchans. This was a day-long event and schools went to Buchans from all over the province to compete. On that day we would move the school’s videoconference unit to the gym and have it set to show the bands who were performing. We would leave the bridge open so that schools that sent bands could call in and listen to their bands or even talk to people at the site.
• Lights, the Canadian performer (and others on different occasions) have generously given their time and visited a videoconference studio where we connected her to our bridge. She gave a class to all of our music students.
• Education Week openings have been done live using the videoconference bridge. The opening ceremonies have been dispersed among a large number of participating sites and the rest, who did not play a speaking (or singing) role have been connected via one-way webcast.

In time, the original bridge began to show its age. The original one could not handle any content besides video (we could not show computer content such as slides, for example) and was not High Definition compatible. Last year we replaced it with one that added both those missing features and which also had a higher connection capacity. It was also considerably smaller. The original bridge was about the size of a ‘bar fridge.’ The new one is about the size of a typical PC.  We have observed the overall performance on the new bridge to be much better—video is clearer and smoother.

And time marches on. Desktop video clients, such as Microsoft® Lync™ are now sophisticated and reliable enough to be used for many of the kinds of purposes we have. Presently the CDLI is in the process of implementing its own Lync server and hopes to integrate it, using the current bridge, with its installed base of dedicated room-based videoconference units.  Desktop clients are are a good choice when it’s just people talking to people but the larger room-based systems still are best when we want to work with groups or see finer details—watching a student playing guitar, for example. The future is ‘looking’ bright.

Next: Yes, of course, CDLI students do science labs.

The CDLI’s implementation procedures depend, to a fair extent, on support from people at the school where the students are located. In the original pilot we worked with the concept of an mTeacher (mediating teacher) being one of the school’s teachers located onsite and who would also help out with the implementation. We imagined the role as consisting of providing basic support such as the supervision of tests and ensuring that students were adequately monitored while online.

During the spring, near the end of the pilot year I held a series of focus groups attended by the principals and mTeachers for the pilot. Doug Furey, who was serving as a program specialist assisting with the pilot in one of the districts and who was also completing his Masters of Education was visiting Memorial at the time and also asked if he could sit in on the meetings.

After the meetings got underway it became clear that not only had much been learned along the way but, much remained to be learned. To say the least, those meetings were enlightening, bringing forward problems, and as it turned out, solutions to many of them. One thing that became apparent was the range of tasks that the school found itself having to deal with. These included:

1. Selecting students for the courses and getting them registered.
2. Ensuring that appropriate space in the school was provided for the students when they were online. Regardless of whether this was part of the F2F class or a whole different room, the students needed a place.
3. Liaising with CDLI; learning what was up and what was new.
4. Supervising tests and labs.
5. Ensuring that students were on task
6. Communicating with eTeachers whenever there was an issue with Teaching and Learning that was affecting the students.
7. Providing basic training on how to get online for the first time and on how to use the tools.
8. Providing onsite tech. support. This included things like preparing trouble tickets regarding connectivity downtime, boxing up damaged equipment and unpacking and then setting up replacement equipment.

I recall that time like it was today!  I took notes of what was required on a flipchart or a whiteboard and after the list was complete it was similar to the one above but in a different order. One of the principals remarked that it was an onerous one and that eLearning at the school did come at a cost. The principal went on to say, though, that this was not to be negative—the tasks got done but we really needed to find a more organized way to do them. Another principal then followed up by noting that, based on the skills of his available staff members he has actually farmed it out. Others then weighed in to say that they had done essentially the same. Together then we looked at the required tasks and looked to classify them. The list above is fairly close to the one we wound up with in the end and based on it, Doug Furey suggested that we actually stop thinking in terms of mTeachers and, instead, focus on mTeams. That was it! With that said it all became so obvious and we quickly came up with a working description of what comprised an mTeam. It had four components.

1. Administration: Typically done by the principal or designate, this consisted roughly of tasks 1-3 above, namely registering and selecting students and ensuring that they had an adequate, supervised space.
2. Coaching: Typically done by an onsite teacher this consists of tasks 4-6, namely student supervision and liaising with the eTeachers as needed.
3. Peer Support: Typically done by a more senior fellow student, this included some aspects of coaching as well as the basic training.
4. Technical: Typically done by the district technicians with help from onsite student tutors.

In subsequent years CDLI embarked on a series of mTeam training sessions. These were done for new schools and, periodically, to refresh existing schools as personnel sometimes moved on and besides, the procedures and tools were evolving anyway. These were generally held on regional basis in district offices and were attended by Frank, Bob, Me, the nearby eTachers and some of the district’s technical staff and program specialists.

Not only did these serve as valid conduits of information from CDLI to onsite staff but, just as importantly, the flow of information was two-way and mTeam training sessions often resulted in the unearthing and subsequent solving of issues.

Next: Other technologies and abilities have been added along the way. We’ll look at how video and videoconferencing has been layered in.

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.
• Test Yourself: A short self-assessment. In many of the courses, including Physics, this would be an interactive multiple choice powered by an open-source Javascript engine we’d come across.

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.

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.

In August of 2002 Leon Cooper retired. And I still have not really forgiven him! Leon was more than a friend; he was also a mentor who worked patiently (most of the time) showing me quite a few things but, most of all, the value in applying an analytic problem-solving approach to the professional challenges we all meet. Oh, and he’s still a very dear friend.

When asked to work with Leon on the succession plan and the new hiring procedure I informed my director of my intention to apply for that one—as I felt it was a better match to my abilities and interests. The director then modified things and instructed us both to get to work on replacing me instead as I would be assuming the role of the program development specialist soon so we needed a new program implementation specialist.

We underwent a similar, analytic, procedure as we had employed successfully in the hiring of eTeachers. Bob Hipditch, a former HS program specialist for Math and Science with an extensive background in the administration of distance education was the successful candidate.

And I do not mind admitting that he was better at that job than I had been. Best of all, those of us on the direct administration team at the time, Me (Program Development), Bob (Program Implementation), Frank (School connectivity and equipment) and Dale (Back-end systems), all reporting to Wade, the director, complemented one another. While, individually, none of us possessed all of the skill, together we had what was needed. And we trusted one another. But it did not stop there. We know/knew who we really worked for: our students. So, as a team we set out to support them as best we could.

At the front line, of course were our eTeachers, our distance education instructors. We started by choosing ones we felt were best suited to the job; those having these traits: empathy, dedication, subject matter knowledge and skill with teaching. Notice I didn’t say ‘technical wizards’ or something like that? While it’s true we did not want people who were just plain stunned (colloquialism; means ‘stupid’ but in a lighthearted way) when it comes to technology we knew those skills would come with training. The other important factors, though, were not so quick and easy to develop if they don’t already exist, so they were the ones we sought. That tradition of dedication to our students continues to this day.

While drafting this, as you might expect, I want back through my files from the school years 2001-02 and 2002-03. Note the ‘snagit‘ from the PowerPoint slide below, which was taken directly from the opening session I gave to the initial eTeacher meeting held back in June 2002, in preparation for the first full school year. It was, and is, my ‘bottom line.’

Our teachers continue to embrace those rules too. No doubt each one has a few extra as well.

Just in back of our teachers lie other various layers of support systems. Let’s start with the actual equipment. Rather than assuming that the schools would provide it we decided to create a standardized student workstation and provide these as needed to the schools. The actual number provided to a school was the same as the maximum number of students would be online in any given class period. In any class, then, each student had their own computer, with their own login. Of course, in a different class period, a different student might be using the same machine, but they would never be shared within any given class period. We purchased ‘business class’ computers as we required the added durability and reliability. We did not regret that decision; once working the systems tended to remain that way.

To set them up we used a disk cloning process. That is, we installed all of the necessary software on one computer and configured it appropriately. With that done we cloned that disk drive to all of the other systems—a process that was much faster than setting each system up manually…a little trick we learned in early 2000 from Sheldon Pittman, tech. with the Eastern School district. Not only could new PC’s be brought online quickly, but totally messed up computers—and that happens—could then be easily restored by re-cloning the drive.  As for saved student work—it was supposed to be stored online in the LMS anyway. Frank prepared the disk image and oversaw the shipping of all systems to the schools. The districts’ technicians imaged the machines and created the student logins.

An ‘all-in-one’ printer/scanner with a document feeder was also supplied, one per site. These were networked and could be used by students to print off work, as required. More importantly the auto-feed scanner was used to scan in handwritten student work which was then uploaded to the WebCT dropbox. That’s how our students ‘turn in’ handwritten submissions. We also supplied all the necessary networking equipment and cabling. Toners were also supplied, but on a limited basis; we provide what is required for distance education and not what may be used for other purposes.

The synchronous classes are for interaction so in the early years we also supplied each computer with a graphics tablet. As time went on and we realized that not all courses required them we moved back to supplying them ‘as needed’ instead. We supplied each student with a headset-microphone so they do not need to be shared–with basic health and hygiene in mind.

We supplied other special purpose equipment. For example we used digital interfacing equipment in many of the science labs (at the time it was a Vernier LabPro with Logger Pro software and various sensors including ones for motion, temperature, sound, pH, air pressure, heart rate, etc.). These were put into a kit which was shipped to schools. We continue to do this today and as our course range has broadened so, too, as has the equipment. Today, for example, we even have a piano course (we’ll get to that later on in the series) and, guess what–we loan the schools the instrument required. Same for tech.ed. See here for a related story about setting up the CNC router at the remote community of Francois.

We also took responsibility for the Internet connectivity at our schools. During the pilot year we contacted all of the providers and invited them to propose connectivity options for our schools. Only one provider responded and, so, on a pilot basis we set up one district’s pilot schools with the proposed solution. Though copper (not fibre), it worked out very well, supplying the site with adequate speeds and excellent reliability. For the implementation year we expanded this to the extent possible and in that year we actually upgraded 62 sites to ‘frame relay.’ Four of the sites could not be upgraded that way so we supplied them with a new, better, 2-way satellite. Yes, Frank’s boots stomped on more school roofs! In the following year we increased the number of ‘frame relay’ sites to 79, the number of satellite sites to 11. Three more got DSL and the two remaining schools came online courtesy of a wireless shot from the nearest location that had high speed. It was a quantum level of improvement! In those two years the CDLI schools finally had high speed, reliable connections.

The back-end systems were located at Memorial University. At the time CDLI was 100% funded by the provincial government and STEM~Net was receiving the majority of its base funding from the provincial government as well. STEM~Net offices were located at Memorial so it made sense to keep the majority of the servers there. WebCT, on Dr. Bruce Mann’s request, had been set up in late 1996 and had since enjoyed steadily growing use and popularity within the university community. Thanks to projects such as Vista it was doing the same in k12. The server stayed and was expanded and updated as necessary. The Tutor’s edge application, mentioned in the previous post, had started off on a trial basis as a hosted service from Calgary. The trial was hugely successful and in October of 2002 the self-hosted version (by then known as vClass–it’s now evolved to be Blackboard Collaborate) was installed in a new server at STEM~Net. Dale managed these and other systems. Although the applications themselves have changed, and the size and complexity has grown, he continues to manage all our back-end systems today.

We continued to use the STEM~Net help desk system for our tech support. Students experiencing difficulty would contact our toll-free line. Many issues could be corrected there and then as a lot of calls really boiled down to (a) equipment/software settings that had been messed up by the user, and which could be fixed by a ‘talk-through’ or (b) a damaged headset which needed to be replaced. Other calls (connectivity issues or damaged equipment, for example) would be redirected to Frank, the ISP provider or the district technicians, all of whom treated these calls as ‘urgent.’

Next: CDLI also developed a huge inventory of learning content in its early years. We will take a look at some of that content and the processes by which it was created.

After a productive pilot year, CDLI moved to implementation in the 2002-03 school year. I was still in charge of program implementation but now it was province wide, not a pilot. During that year, as in the previous one, we had both distance education models working in tandem. The pilot schools now went into year two of the web-based offering and the remainder started their first year with that model. Students who were already using the legacy model continued with it. Overall that year we had 17 courses using the new model and 4 using the legacy one. The list was growing:

• Math, grades 10-12, academic and advanced streams
• Grade 10 Science, Grades 11&12 Physics and Chemistry
• Grades 11&12 French (3 courses)
• Art, Writing, Canadian Hist. Enterprise Ed., World Geog.
• Tech. Ed.

The CDLI was created as a division of the DOE. The school administrators among you may find this a bit unusual. Departments of Education do not normally deliver education; they focus, rather, on governance, and leave the tasks associated with program implementation to school districts. In this case, though, it made sense to create CDLI in the way that was done. As a DOE division: (a) funding became fairly straightforward (b) CDLI was able to combine schools across district lines as needed and (c) online teachers—we call them eTeachers—had a provincial reach. In effect CDLI became a provincial virtual school.

Only school districts could hire teachers so CDLI adopted a cooperative practice with the school districts in which teachers were seconded to work for CDLI from their existing permanent jobs. The recruitment process was a competitive one as follows:

• We created a general profile of what traits we needed in an eTeacher. These will be discussed more in the next post.
• The initial application process was constructed as an online database. Using a secure online connection prospective teachers would complete a professional profile and would respond to a variety of questions. Together with Leon and, later with Bob (see the next post) we would score the responses and, based on those scores, would devise a short-list of candidates.
• We would contact the school districts and seek permission to interview those on the short-list. The interviews were all conducted via telephone, regardless of location, in order to place all candidates on the same level field. The interview consisted of a fixed set of questions, accompanied by scoring guidelines. One of the Assistant Directors from the school districts sat in on the interviews.
• For each short-listed candidate, three referees (which the candidate provided on the application) were contacted and asked to rate the candidate on a scale of 1 to 5 on several criteria.
• Each of the three components carried a weight. In the first year, for example, the application carried a total of 70 points, the interview 55 and the reference check 15. The scores were totaled for each candidate and short-listed candidates would be rank-ordered according to the score.
• The director would then approach the school districts and ask permission to second the highest ranked candidates for each job. Typically the district would respond with a ‘yes’ which would be conditional on its ability to appropriately back-fill the chosen candidate. If not the next highest candidate would be sought, and so on.
• There is a provincial collective agreement governing teacher jobs in my province which also includes pay scales with bands that depend on both years of service and education. The eTeachers are paid according to that scale, the same as F2F teachers. Seconded teachers, though they work for CDLI are still in the employ of their school districts and retain seniority and other benefits with that district.

Through this process the CDLI was able to assemble a team of dedicated, skillful teachers who quickly acquired the necessary technical skills. As you might expect, the pedagogical skills and strategies took longer. It’s a process that requires ongoing dedication throughout the whole career. Fortunately we had the benefit of (a) the great amount of knowledge and skill we had amassed through 13 years of the legacy model and 8 years of STEM~Net and (b) the wealth of information we had obtained through the previous pilot year. Many of the pilot teachers and some of the ‘legacy model’ teachers were successful applicants to CDLI so they brought their skills with them.

We adopted a policy of endeavouring to place the teachers, physically, where they were at the point of secondment; that is we would rather our eTeachers remained in their home communities. While we fully understood the advantages—collegiality mainly—of centralizing our teaching force, at the time it was much more important to maintain a strong footprint all across the province. There was much work to be done and our best bet was to keep people close to our sites so as to ensure that we were truly a part of the rurality we served.

We intended to build a culture of eLearning so we started by emphasizing teamwork. People worked in groups. We supported one another. We found ways to ensure that we could have F2F meetings several times per year. We also DID eLearning. Our teachers did NOT teach F2F. Their online students were our students, period. They got our best efforts, not the scraps from the educational table. We met, regularly, online, using the same tools that we used to teach our students. In short we walked the walk, if you’ll pardon the cliché.

The hiring process for the initial eTeachers had actually been carried out in the spring of 2002, as the pilot year wound down. The faculty gathered for the first time in June 2002 at Memorial University. There they underwent training in the LMS (WebCT) and the synchronous tool (vClass). They also met as subject matter groups to discuss and develop new approaches to teaching and learning.

They were also given their class schedules for the following year. The process of developing these had not been an easy one. Recall that CDLI worked with all districts. Scheduling is a district matter and school opening and closing times sometimes vary by community. Fortunately, because most of the CDLI schools had also been part of the Legacy model there was some degree of uniformity regarding start and end times as well as the class schedule model. Wade, our director, had engaged in extensive rounds of meetings with the school boards around this matter and, by then, had achieved a decent level of agreement; enough that we could proceed.

Still, the job of scheduling 19 instructors, teaching a total of 21 courses into 73 small schools located in 10 different districts was extremely challenging. Here’s what I did:

• For a time stopped answering the phone and replying to email. I had to focus solely on this. During that time Leon and Wade took the brunt of the emerging issues rather than me taking my share.
• Began with a blank 14-day calendar. Each day had five class periods. Overall the time slots were labeled A through H (Later we dropped H and just used A-G). This meant, for example, Day 1 had periods A through E, Day 2 had F G A B C and so on.
• Combined the districts so that there were only 5 different schedules needed, not ten.
• Started with the most populous group. This happened to be the districts occupying what is now the Nova Central district.
• Applied basic logic: students taking grade 10 math, for example could be assumed not to be taking grade 11 math (for the most part) so these mutually exclusive courses were scheduled in the same class slot. Likewise for Physics 11 & 12, Chem 11 & 12 and so on.
• Repeated until all the courses were scheduled in for that pair of districts.
• To create the schedule for the next set of districts all that was needed was to walk the first schedule ahead by one slot. That is, courses offered in slot A for the first pair of districts would be offered in slot B for the next pair, and so on.
• With the district schedules created all I had to do was turn them inside out and prepare individual schedules for each eTeacher.

Finally, the district schedules were sent to each school and I waited for the calls and emails. There were quite a few. The majority were from schools who could not make the distance education schedule work for their particular school owing to some circumstance particular to that site—maybe students did, for example, have to take grade 10 and 11 math together for some reason. Perhaps a staffing situation created a clash. There were various circumstances that could warrant a call. For the most part these were dealt with by allowing that school to enroll some students in classes that would normally be offered to some other district. If, for example, the school could not work with the fact that, for them, Gr. 11 Physics was supposed to be in slot C then they would be given the go-ahead to register for different time slot—perhaps it was offered in slot B for a different district so the students went to that class instead.

It’s worth mentioning that around then I got out of using voicemail on the telephone. I would typically start the day with the message manager full at ten messages and the email inbox clogged with maybe as many as 100 inbound emails regarding registration and general enquiries. I’d start in by returning the voicemail, first in first called back. After several calls it would become apparent that this was not about to end anytime soon as, after clearing 3-5 calls, the box would still be full! People would be trying to reach me while I was returning other calls. Same with the email. It was not always fun–sometimes, often actually, I’d get the snide comment that “There’s no point in calling/emailing Maurice, he doesn’t return them.” Ha–not exactly the case… They would be returned but sometimes it took a while.  This got fixed later on as we moved to automate the registration procedures and as people got more used to our workflows.  As for the voicemail I switched it off and had caller ID turned on. In addition I had the phone set so that after four rings the call would be redirected to  our administrative assistant who would take a message. I figured that it was always better to get a voice, not voicemail. Still do!

There was also the fact that my province spans two time zones. Northern Labrador uses the Atlantic time zone (UTC-4 hours) but the rest (southern Labrador and Newfoundland) uses Newfoundland time (UTC-3.5 hours). The number of students from Labrador is small for some courses—not large enough to make up a single class—so some classes had to have students from both time zones. This was problematic because we couldn’t just dictate that the Labrador schools change their opening and closing times! Here’s what I did: In the classes that combined students from both time zones I was careful not to schedule the instructor in the period just before or after that class. This allowed the class to run 1.5 hours instead of the 1 hour norm. So, what happened was that the Labrador students joined first and were there with the instructor for 30 minutes. After that 30 minutes they were joined by the rest of the students. Half an hour later the Labrador students finished. The class therefore was: (a) 30 minutes tutorial for the Labrador group (b) whole class instruction (c) 30 minutes tutorial for the remaining group. Complicated—yes, but workable—yes, too.

The eLearning team was built for the first year and the schedules were set. In the fall of 2002 the real work began: full implementation!

Next: We knew the task ahead would not be easy so we took care to provide a full range of supports for our learners. These will be described in detail.