Signal when you’re through, please
A few notes on designing the distance learning course: As I’ve said elsewhere, the course was designed and first taught in 2001, which is important to note given the pace of IT development in the education field. I was working then in the Division of Continuing Education at Emerson College, which at the time had a very popular web design and management certificate program. This was during the brief period of time in which it looked like web skills were going to be a marketable skill, rather than a commodity to be outsourced. I had some background in computers, and had taught myself a fair amount about relational database design (insofar as FileMaker 3.0 was a relational database). Still, around the millennium, I couldn’t shake the feeling that technology was leaving me behind, so I made the decision that I would learn HTML. I taught myself on train rides to work with an O’Reilly book, and later audited the web certificate program. This decision, and training, provided the skills I needed to build the course.
We made the decision to experiment with distance learning in early 2001. Emerson’s IT situation was, I imagine, similar to that of many comparable colleges. They had an ancient VAX system that handled student information, which was painfully difficult to get information into and out of. Emerson had just adopted the BlackBoard course management tool, which was not able to communicate with student information system. The continuing education students, too, had mixed technology available to them. Some used the school’s labs as their primary access, others home computers, but most used their work computers. In the first group of students to take the course, quite a number used dial-up connections. This situation produced many of the constraints that shaped the course.
One clear example was the decision to create the course materials as a stand-alone web site rather than entering the materials into the BlackBoard system. This was done for two reasons: One, because management of that volume of text in BlackBoard was awkward because the web interface was slow and there was no “universal replace” option; and two, since the student information system didn’t talk to the BlackBoard system, students were registered manually, which meant they might not have access to the course management environment for a week or two into the course. Having a separate site meant it could be located outside of the BlackBoard authentication system, and students could access it freely. This became important when the College made a sudden switch to the WebCT system, which was painful for almost every instructor involved, but was not a problem at all for me, since none of my content was in the system. Interestingly, this decision also had implications for the eventual open sharing of the materials—since I knew I was going to post them in an unprotected environment, I went out of my way to avoid (for the most part) including any third-party materials, so I had little to remove when I started the OpenFiction project.
A second set of decisions driven by the constraints involved the use of HTML and e-mail as the primary communication tools. Though I probably couldn’t have articulated it at the time, the constrains enforced (and I believe still enforce) a doctrine of “least effective technology.” In many ways, mediation when it comes to learning means “something that gets in the way of,” so the less of it you have, and the more reliable it is, the better the learning experience would be. Even if we had the budget to invest in Flash animations and the like, I still would have designed the class as I did, because at the time, HTML and e-mail were really the only two rock-solid web communication technologies available. In later iterations of the class, I experimented with instant messaging, and we used the BlackBoard bulletin board somewhat, but neither was sufficiently developed to be of great use. All of this had implications for how the class was conducted, which is fodder for another posting.