Multimedia Lessons: “If There’s a Hard Way to Do Something . . .”

by Eric Hibbison

from Inquiry, Volume 1, Number 2, Fall 1997, 50-56

© Copyright 1997 Virginia Community College System

Return to Volume 1, Number 2


Abstract

Creating multimedia lessons on computer for a poetry unit in ENG 112 can be complicated. Eric Hibbison’s experience led to some useful suggustions for developing such lessons.

The following report describes purposes, methods, and conclusions from two years of working with an authoring software called Toolbook and an ancillary software for doing multimedia lessons more economically than in the multimedia version of Toolbook. This project has been supported by VCCS Professional Development Research Grants and logistical in-house at support J. Sargeant Reynolds Community College.

Why Would Any Faculty Want to Use Multimedia Lessons?

According to a 1996 article in Cause/Effect, one series of answers to this question emerged at two Virginia universities. These answers go with using asynchronous learning, especially for distance education and for dealing with nontraditional students. Although aimed at technology in general, the answers certainly apply to multimedia lessons in particular.

Technology can benefit learning when it

Like many faculty who are looking for a better way, I wanted to use multimedia lessons to ease the pain of reluctant students who were studying poetry in my introduction to literature classes (ENG112). One of my main assumptions in this course is that nothing in a famous work of literature is accidental because the hallmark of professional writing is revising to enhance the theme of the work. This runs counter to the assumption of the reluctant student that getting the gist of a work is good enough; nothing more is - or can be - required. Replacing this “good enough” assumption with a new value is one of the sticking points of the course; perhaps, I hoped, a supplemental multimedia lesson completed before a work would be discussed in class could make the class discussion richer and ease the way for the “not accidental” assumption to take hold. A recent posting to the AAHESGIT listserve includes the consideration that faculty turn to technology to get past just such sticking points because the right technology combined with the other learning methods in the course can offer a better way to reach some students (Ehrmann and Gilbert). Multimedia seemed to offer me a more engaging way of increasing students’ depth of understanding of individual works.

Over the past two years of working with Toolbook, I’ve moved through the following list of purposes for making multimedia lessons:

In short, as I got to know the software and had students try out initial lessons, my ambitions enlarged. Such growth should be part of anyone’s “learning curve ” if setbacks can be overcome.

A Mad Method

To meet these purposes, I basically started with lesson plans that worked well to push my students toward that “nothing is accidental” assumption. Initially, then, I took three sonnets for which the students of previous years had shown some interest and for which they could be led to see the artistry, or craft, put into the works.

My first creative surge led to drafts of lessons that displayed one sonnet on each page of a lesson and led students to visualize the metaphors in the text by using appropriate photographs downloaded from the World Wide Web and CD-ROMs. I recorded two ways to read selected lines, incorporated these readings into lessons as sound files that students could click a button to start, set these variant readings into the page students viewed with text that emphasized the variations, and asked students to select the most sensible rationale for reading the line with one variation or the other. Each multiple-choice answer in the first two lessons bore a note that popped up when a student clicked the letter for the answer. Each pop-up note either explained why the selected answer might not be the wisest choice or amplified the target answer with a more advanced consideration¾sometimes after a pat on the back with a “yes” or “of course” or other interjection of approval.

To illustrate the fine points of rhyme, I color-coded the rhymes by placing differently colored “fields” over the words at the ends of the lines on one copy of the sonnet and made the fields transparent. To involve students in analyzing the rhythm of each sonnet, I put the usual hatch marks above most syllables in yet another copy of the sonnet and animated three selected hatch marks so that students could select which of three syllables they thought would likely be emphasized in a line. (Overly) detailed analysis of sound effects in the two training poems was accomplished with more color coding, which students could click on and off to focus on one effect at a time.

After initial trials of the lessons¾as extra-credit projects¾dozens of revisions were made over several months. For instance, background pages were added on the origin of the sonnet, the Italian pattern, biographical sketches and paintings of Petrarch and Shakespeare, satire, and on the “courtly” tradition. In addition, the mouse tutorials from Windows 3.1, a connection to Notepad for making notes and answering questions, and a page on how to navigate through the lesson were added to each lesson. Since the lessons were to be used in an open computer lab, all sound files were made optional because the students might not have earphones or speakers set up with the computers they were using.

Figure 1: “Before” - The earliest page style was cluttered and opened with music that could not be blocked out.

In short, a lot of creative effort was expended over the first year of this project to make, beta-test, and revise these three lessons, getting them ready to be required work for the course. This creative surge and the next one, making three lessons on short stories, ended with further training in the software and consulting work by the trainer to make the lessons into a series and measure student use of the lessons.

One problem that delayed development was my insistence on complicating the design of the lessons rather than simplifying it. It took a long time and some specific experiences for me to separate complexity of design from sophistication in learning. The “stick” for me was seeing one student and one colleague¾both intelligent and somewhat familiar with Windows¾stop at the opening screen of a lesson and ask aloud, “Now what do I do?” The “carrot” turned out to be a redesign accomplished by the consultant that included every element and every word of my lessons in a cleaner, much more easily understood format¾a format which used two methods of popping up information that I had tried unsuccessfully to program into lessons myself. Studying the consultant’s programming gradually made these methods viable.

Figrue 2: “After” - The most recent page style is less cluttered and offers optional sound files, e.g. a reading of the sonnet.

Hitting the Wall

In fall 1996, the three poetry lessons were required parts of the course. Students were given two months to use each lesson on one of three available “multimedia” computers in the campus LRC. Each lesson had a worksheet that asked students to check what actions they did for each subtopic (page) in the lesson and to list selections from what they learned, including noting the best page and the worst with a rationale about their selection. The third worksheet left space for answering the 25 quiz questions and explaining any for which the student did not feel relatively certain of the answer. One third of my two classes completed the worksheets before class discussion of the sonnets; another third completed the worksheets after that day. Another third never completed any lessons, but these also did not do any of the dozen extra-credit or substitute assignments open to all my students. During this semester, the consultant (who had also been the trainer for the two training visits to the college for a group interested in learning Toolbook) was setting up the lessons as a series by installing a registration page, adding tracking programming that gave students credit for completing a lesson only if they clicked on all of the subtopic pages in the lesson, and arranging for the recording of quiz answers for the third lesson.

One reason for the slow progress through the lessons was lack of computer skill in the students, but another reason was logistical problems with the meager capacity of existing equipment. During peak hours of use, each multimedia feature in the lessons would lock up the 486 computers¾sound files, pop-up fields, and forget the one video in the lessons. Now, MMX computers have arrived to supplement these computers, and I have gained access to all of the 486 and higher computers in the lab, even those without sound, so that if the eight multimedia computers are occupied, my students can still use all the visuals in the lessons even during peak hours.

So What Have I Learned?

After making dozens of pages, hundreds of fields for text and photos, and linking dozens of hotwords to pop-up fields, along with embedding the occasional programming command, and having a few dozen students use the lessons, I’ve reached some conclusions about the ways a project like this one should proceed. Here’s a selection of the most important.

1. Good in-class lessons can become better multimedia lessons¾clearer, more detailed, with more background, and with more student control over the pace of learning.

2. However, if students’ online efforts are not monitored, they will ignore the challenging parts of lessons, considering themselves “finished” much too soon, having only the gist of an idea and very little depth. Few students strive for mastery.

3. Turning a group quiz into an individual, online quiz can cause less dedicated and under-prepared students to think more carefully, but denying them the feedback of peers and teacher on the quiz still leaves them free to make unfounded assumptions and inconsistent answer patterns. (Despite warnings to check all answers against the “main idea” question near the end of the quiz, few students reviewed their answers for consistency.)

4. Programming is needed to constrain students’ tendency to “finish” prematurely before learning as much as they are supposed to learn; programming is also needed to record answers and score online quizzes, as well as track students’ progress through lessons. (Higher priced authorware supposedly includes such features.)

5. Students need a way to ask questions about the software and the content of lessons. Having a technician on site who knows Windows can help with software questions; having e-mail access between the student’s workstation and the teacher could be handy, but it would not be immediate enough. Pairing students by content ability might be wiser than pairing them for computer experience to work through lessons together, provided a fair division of labor can be worked out. In my classes, the students better prepared to handle the content were often, but not always, also more experienced with computers and more likely to have computers at home.

6. Planning and carrying out such a project should include as many design features as possible up front; evolving a design causes a great deal of revision time to be spent on making features consistent from page to page and lesson to lesson. In addition, it takes effort to avoid having only print on screen; documenting the source of photos and sound files, whether they are copyrighted or public domain, can be accomplished by copying to Notepad or another word processor the Web address or software source of quotations, photos, sound files, drawings, charts, etc., and making the source note a separate .txt file stored in the same subdirectory as the graphics file. Permissions should be sought asap for inhouse use, Web site use, and use if the lessons are placed on a CD-ROM.

7. Early testing is mandatory for finding out how students are reacting to such lessons to find out, for instance, whether students generally prefer to control sound files or to have sound playing when they turn a page, whether they will use pop-up hints, what pages they will want to skip, and whether they enjoy and can learn from such lessons or prefer the social interactivity of the classroom to the keyboard and mouse interactivity of a computer lesson.

8. Surveying a class anonymously to find out what would compel them to work on such lessons outside of class time in a centralized facility where you are not present to answer questions on the spot might help design ways to integrate the materials of multimedia lessons for the next semester’s course.

9. The “learning curve” for software, I’ve noticed, is such that learners often like to have every key stroke and mouse click prescribed in the early going, so that they can make something without mistakes. After a while, as confidence and know-how build together, the learner will want to take over more and more control. This seems as true of faculty who face building multimedia lessons as it is for students working through them. Patience is required during the early, diligent work on the basics of using any software.

10. Software systems can be volatile, requiring months of troubleshooting problems as they arise, but logistical support may evolve with the growing use of particular software, including multimedia lessons. Plan to develop an effective working relationship with the campus computer center staff and with early testers of lessons if you want to make and use multimedia lessons.

Confidentially, the 100-150+ hours it has taken to get to the current (4th) version of these lessons would not have been attempted without the incentive of grant support for most of it. So I will end with two mottos that have been rung through my head from time to time during this project: “technology is only fun when it works,” and “technology development takes time.” (Does anyone remember how primitive version 1.0 of their favorite word processor was?)


Works Cited

Ehrmann, Stephen C. rmann@aahe.org, and Steve Gilbert ilbert@clark.net. “AAHESGIT #45:NUTN Clarification.” AAHESGIT@LIST.CREN.NET 13 March, 1997: 9:12am

Gloster, Arthur S., II, and Steven A. Saltzberg. “Multimedia and Asynchronous Learning: Changing the Support Model for Information Technology Services.” Cause/Effect 19.4 (Winter 1996):27-29, 34-36.
At http://www.cause.org/information--resources/ir--library/html/cem9646.html. ©1996 by CAUSE. Quoted by permission of CAUSE, the association for managing and using information resources in higher education.

 


Eric Hibbison is one of the founding 107 faculty and staff from J. Sargeant Reynolds Community College and, this semester, is project director for the VCCS Courseware Project to bring ENG 112 online with interactive and multimedia resources. Visit his Web page at http://www.jsr.cc.va.us/PrcH&SSDiv/hibbison/hibbbiop.htm