Note: This article was originally published in The Technology Source (http://ts.mivu.org/) as: Jo B. Paoletti "Wanted: Course Revision Without Pain" The Technology Source, November/December 2003. Available online at http://ts.mivu.org/default.asp?show=article&id=1034. The article is reprinted here with permission of the publisher.

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.]