Teaching online has been a deeply transformative experience. I have become a learner again as I redesigned my courses from the ground up, an exciting and rewarding process. This article is about the hard lessons that I reluctantly learned in this process: that as a course designer I need to contain my pioneer enthusiasm, plan more carefully, and cooperate better with software and IT support staff. The catalyst for this learning experience was my institution's adoption of course management software four years ago, which forced me to change the way I organize, construct, and revise courses.
I am an early adopter of new technologies, especially in the humanities. My dissertation, completed in 1980, was a computerized content analysis of cartoons about fashion; in the mid-1980s I was offering computer workshops to museum collection managers (on an Apple IIe). Online teaching and learning have been part of my classroom since 1994. In terms of software terms, my classes are in their fourth generation—having developed from Internet-enhanced (UNIX-based e-mail) to Web-enhanced (online syllabus, readings, and discussion) courses, and thereafter from completely online (using customized HTML pages and assorted freeware) courses to their present incarnations supported by course management software (CMS). Of all these experiences, the adoption of CMS had the biggest impact on how I work, altering my entire approach to course design and revision.
After many years of writing and speaking about how to apply new technologies to teaching and learning, I believe it is time for a critical look at changes in course development, especially as it has been affected by the widespread use of course management software. While my experience has been with WebCT, conversations with colleagues who use Blackboard or other systems suggest that my observations are not unique to any specific software. We need to shift some of our creative energies to the challenges of maintaining and revising courses, particularly within the context of changing software environments. It is especially important that everyone—faculty, support staff, and software developers?¢‚Ǩ‚Äùbe involved in this discussion.
The Transition to CMS-enhanced Course Design
Before my introduction to the Internet, my teaching style would have best been described as improvisational. My pre-class outline consisted of a list of objectives and possible activities or discussion topics. If a compelling news event occurred, I would often suspend the course plan to focus on the topic. It was not unusual for me to change the order of topics in the syllabus as late as halfway through the semester. Moving online therefore felt comfortable, even natural. As long as I was developing the course using a mixture of my own HTML pages and available applications such as listserv, e-mail, and chat, my approach to course design actually changed very little. It took me fifteen minutes to learn the basics of HTML on my own, and not much longer to master simple tasks such as resizing images in Adobe PhotoShop. Revising and uploading a Web page or e-mailing an article to students took less time than waiting for the photocopy machine to warm up. Major course revisions and new course creation, usually completed over the summer, were pleasant, intellectually engaging tasks. In short, my flexible approach to course development was a perfect match for the tools available to me as an online pioneer.
The eventual jump to a completely online version of one of my courses, AMST 212, was not taken lightly, since I knew it would require re-designing the course from the ground up. Every aspect of the course had to work asynchronously for an independent learner. Fortunately, this project coincided with the opportunity to participate in the Web Initiative in Teaching (WIT), a distance educator training program sponsored by the state university system of Maryland, which provided me with time, training, and a learning community of my own. My initial proposal did not include using course management software, which was just being introduced on a broad scale. I had experimented with a few of these software packages, and was unhappy with what looked like a steep learning curve and rigid course structures; I had little interest in relinquishing the ease of design and the control of my accustomed methods. But my home campus, the University of Maryland, adopted WebCT in the summer of 1998, just as my project was beginning, and I decided to try it. There were many factors in my decision: greater security for student work, having the time to learn the system, and a sense of obligation to campus colleagues who looked to me for mentoring and advice about teaching online.
The Challenges of Adjusting to CMS Upgrades
With four years of experience using WebCT, my observation is that while CMS software can simplify the tasks of course creation and management, course revisions can still be a significant workload problem.Table 1 tracks my development of AMST 212 from August 1998 to August 2000, focusing on the impact of changes in WebCT as new versions were rolled out. I have distinguished between content-related tasks (i.e., researching new readings and other resources), learning-related tasks (i.e., designing ways to actively engage students with course materials), and CMS-related tasks (i.e., site creation and maintenance, and preparing technology-related activities). I omitted tasks such as testing links, updating a syllabus to include new dates, or minor editing of handouts because they require minimal time and can be assumed to be routine, even when a course is not being revised.
The initial conversion to the online format consumed about 200 hours over the course of three months. Most of that effort was devoted to the task of laying out a complete course, including discussion topics, readings, and assignment descriptions at a level of detail that I'd not before attempted. Interestingly, using a CMS actually made that task easier, although the learning curve was steeper than my 15-minute crash course in HTML. Revisions for summer and fall of 1999 took less time; the obvious reason was my growing familiarity with WebCT. I now realize that a more significant factor was that all three iterations of AMST 212 were created using the same version of WebCT, so that my initial learning curve was still sustaining me.
However, in the nine months between fall 1999 and fall 2000, when the course was next offered, the university upgraded to new versions of WebCT not once, but twice. The first upgrade introduced a drop box for turning in assignments, which connected assignments to the grade book and provided an integrated mechanism for instructor feedback—improvements which many users had suggested. If the upgrade had been my introduction to WebCT, I would have been thrilled with the drop box mechanism. Unfortunately, I had been delivering and grading written assignments in a completely different (and very involved) way. Thanks to my own inclination towards designing clever and unorthodox solutions, I faced extensive revision of the existing assignment descriptions and instructions, in addition to the task of creating assignments in the drop box area. I made minimal changes to course content, but still spent over 40 hours that spring on revisions, nearly all related to the new assignment tool.
Over the summer of 2000, WebCT rolled out a new, dramatically different, version. I participated in beta testing of WebCT 3.0, thinking (correctly, as it turned out) that it would give me a head start on what would probably be major revisions in my course for fall. While I loved the new interface and navigation features, once again I had to make major revisions to AMST 212 to fit the upgrade. One common problem came from the instructions I had embedded in the course content, such as step-by-step directions for completing a task. There were many of these, since I had incorporated technology lessons into each of the assignments. For example, the first few essays were to be posted in the student presentation area as hypertext documents, viewable by the entire class. In the instructions for each essay, I had embedded the steps for posting the paper in WebCT. Similarly, I had embedded references to WebCT tools and processes throughout the text of my course content (e.g., "Click on the Quiz link to the left of your screen"). These revisions took about 100 hours to complete, and once again I had minimal time to make content changes. This bothered me; my course usually draws heavily on recent events, and many of my readings and examples were growing stale.
Course management software has improved considerably in ease of use; user suggestions such as "a simple and powerful tool to support the submission, review, and return process" (Foreman, 2001) have been incorporated in the latest versions. Yet with an infinite number of improved versions on the horizon, I wonder if there isn't a better way to do course design. After all, like most instructors, I have a limited amount of time to devote to course revisions, including finding new readings, rewriting assignments, or even adding entire new sections to my courses. Course management software needs to make it easy not only to put a course online but also to revise that course?¢‚Ǩ‚Äùrepeatedly. What will I do differently next time? What is on my wish list for my courseware administrators and the software designers, marketers, and trainers at WebCT? (Once again, this wish list is also applicable to their counterparts at Blackboard, Lotus Notes and elsewhere.)
The revision bottleneck is not strictly a software problem; it is also a marketing problem, a training problem, and a problem aggravated by individual course design choices. Helen Parke and Steve Ehrmann of The Flashlight Program found that most colleges and universities were focusing their CMS evaluation efforts on teaching and learning issues, whereas course maintenance and revision were not on the horizon (Parke and Ehrmann, n.d.). It is time to put course revision on the agenda. Software designers and campus IT support staff need to better anticipate the work necessitated by new versions. Educational software producers need to understand that educators do most of their revisions between semesters, especially over the summer. It would also be helpful if course management software producers had a sufficiently clear idea of how teachers in different disciplines use individual tools (chat, quizzes, bulletin boards, etc.). Understanding how we use various CMS tools will help them anticipate the impact of updates. Version changes that can be expected to require significant course revisions should not be introduced too frequently. Why adopt WebCT 2.0 when version 3.0 was already looming on the horizon? Training new users is important, but as the user base grows, it will be even more important to provide training and support for existing users facing extensive course revisions. Ideally, better scheduling of upgrade releases and more attention to transition instructions and training can reduce the difficulty of CMS-driven course revisions.
Instructors also bear some responsibility. Unused as we are to collaboration, particularly with those in the private sector, our first reaction to technical problems is likely to be the invention of an idiosyncratic solution. These unique, personalized solutions will not solve the larger problem and can easily backfire when a new version is released. Working with customer support, trainers, and product developers and helping them understand the users' viewpoint will eventually result in software improvements that don't divert course development time to site maintenance.
Similarly, it is clear that I bear considerable responsibility for my situation. No one forced me to beta test the latest version, and in fact I had the option to teach the course in fall 2000 using WebCT 2.0 with the revisions already done that spring and focusing on content updates instead. Why didn't I? I can plead ignorance of the extensive nature of the latest changes (and I truly had no idea how long the summer revisions would take). But the simple fact is that part of my "early adopter" personality is a lamentable inclination to leap before I look. In the heady days of the mid 1990s, that tendency is what kept me on the cutting edge; it was only a matter of time before I paid for my exuberance. My other mistake was in developing a complicated and idiosyncratic solution for a weakness in the first version, which accounted for half of the spring revisions. Had I thought about it, I would have realized that WebCT was not likely to come up with a solution that would dovetail with my approach. A better solution would have been keeping it simple?¢‚Ǩ‚Äùstaying with an existing method from my Web-based course, or even dropping back to earlier technology. E-mail submissions in ".doc" format, for example, would have been easier for my students than posting HTML files in the student presentation area in WebCT. Links to the student handbook might have worked as well as my customized, step-by-step tutorials, and would have required minimal revision.
Today's open source tools, designed to be compatible with the major CMS platforms, may also offer a solution. These user-created tools offer greater flexibility, particularly for anyone who finds his or her teaching inhibited by the sometimes-rigid structure of a CMS. Yet because open source tools often entail their own frequent modifications and upgrades, instructors may encounter many of the same challenges that proprietary systems currently pose for their work. In this area at least, it still remains to be seen whether open source software can offer a more convenient supplement or alternative to systems such as WebCT or Blackboard.
For the present, beta testing of CMS upgrades should pay more attention to course revision tasks, and training materials need to address the needs of continuing as well as new users. If transitional training materials are not available from the software manufacturer, campus-level support staff may need to institute their own in-house beta testing by experienced users in order to anticipate training challenges. Some compensation, in the form of a course release or summer stipend, would also be appropriate, given the potentially enormous time commitment. When I beta tested WebCT 3.0, I was on a summer appointment with the university's teaching technology group. Although testing the course revision process was not initially part of my assignment, being paid for my development time was a pleasant novelty, and I have tried to repay the Office of Information Technology with my time and expertise freely given as a faculty mentor.
CMS upgrades do not always have to be difficult. Even in the transition to WebCT 3.0, some features continued to work well (or better) without requiring any adjustment or revision on my part. For example, improvements to the discussion and mail features in WebCT added several new capabilities without any disruption to my existing folder structure, in a course space that in was continuous use. Similarly, changes to the quiz tool have required no revisions on my part since the earliest versions of WebCT. In the case of more substantial software changes, however, the transition process can require correspondingly substantial investments of time and energy that prevent instructors from focusing on other aspects of the course. A greater awareness of this problem on the part of instructors, support staff, and software producers will hopefully result in better strategies for minimizing the pain of course revision.
Conclusion
Overall, the challenges of incorporating new technology have rarely outweighed the benefits for my classes. My university's decision to adopt course management software encouraged faculty to move courses online and helped focus the previously scattered efforts of the information technology support staff. With each new release, today's CMS is many times more powerful and sophisticated than the first generation. I cannot imagine a first-time user starting from scratch, as I did in the mid 1990s. All I ask is that the same creative minds turn some attention to course revision and maintenance. More and more, the challenge for online educators is not getting a course online but keeping it there. Everyone involved needs to start paying more attention to course revision as a critical task and to work together to develop software that supports the revision process, rather than complicating it.
[Editor's note: This paper is modified from a presentation at the 2001 WebCT conference in Vancouver.]
References
Foreman, J. (2001, January/February). Trading mules for tractors: The pros and cons of adopting a course management system. The Technology Source. Retrieved January 19, 2003, from http://technologysource.org/?view=article&id=374
Parke, H. & Ehrmann, S. (2002). Institutional studies of the educational uses of web course management systems. Retrieved January 19, 2003, from http://www.tltgroup.org/WCMS/ LitReview/Abstracts.htm
time management gameshidden object gamesmatch 3 gamesdownloadable pc gamesword games
