Developing Multimedia: A Method to the Madness
by RONALD D. McFARLAND Nova Southeastern University Fort Lauderdale, Fla. Meet Ray and Faye, two faculty members meeting to develop a course. Too much content and too little time leads to the following conversation: "Let's put some of this content on the computer," says Ray. "Great idea! We can also add sounds, animations and video!", exclaims Faye. Ray then shouts, "Wait a minute! I have an idea! Let's make a CD–;ROM and it can be part of the course requirement!" At this, Faye leaps to her feet and yells, "Yeah, that's the ticket!" The ticket to where? Are you sure you want to go wherever "there" is? The process of multimedia development can be exciting, fun and challenging, with half the fun being in getting "there." However, if you do not plan how you are going to get there, it can be a ticket to a ride full of bumps, bruises and unpleasant surprises. The development process employed by the Educational Technology Laboratory at the Medical University of South Carolina appears to provide a fairly smooth ride. So far, the production team has a track record of on–;time delivery with products meeting clients' specifications. For example, the team's latest project was the development of a CD–;ROM designed to encourage middle school students to explore environmental careers as a possible vocational choice. The program contains video, sound, animation and interactivity built around a "super her'es" theme. In addition to client satisfaction, the products developed in the Technology Lab have performed well during evaluation. For example, the CD–;ROM mentioned above was evaluated by over 600 middle school students and 95% stated they enjoyed the program and were able to master its objectives. No Secret Tricks The Lab's production team has no secret tricks in their goal of develo¼ng computer–;based multimedia for instruction, research or presentation. The staff consists of a director, a programmer and a graphic artist. The entire team meets with a client to first, plan the project, and then intermittently throughout development. The process from start to finish is a real "package" deal. The lab's multimedia development team follows several basic guidelines: Analysis and design is finalized prior to actual development on the computer; Formative evaluation begins immediately (e.g., Is there agreement between the needs assessment, goals, objectives and analyses?); A scope of work contract is negotiated and signed. (This contract specifies the responsibilities of the development team as well as those of the client.) Timelines are adhered to, but not at the expense of quality; and Constant communication is maintained between development team and client. Multimedia Development Process Goal Development: After accepting a project, the team works with the client to focus their goals. Fuzzy language such as "develop an appreciation for…" or "increase understanding in…," etc., exist only in initial meetings. The team seeks to find out exactly what the finished product would look like if the user were, for example, "increasing his or her understanding in… ." Making the goal measurable is the only way to know if the user got "there" or not. Needs Assessment: Next, the client and team conduct a needs assessment to determine what the client wants the computer program to "do" versus what the team has the capability to produce. If there is a discrepancy, discussions may center around to¼cs such as : Feasibility of client request (Can it be done technically?) Time involved (Can it be finished on time?) Money (More media equals more cost.) Re–;examining goal(s) (Should the project be more focused?) Analysis: Analyses are conducted for the target computer's hardware, software to be developed, the audience and the objectives. Analyses of various components (hardware or software) may occur at the same time a needs assessment is conducted since one may, and often d'es, heavily impact the other. Suppose, based on objectives and audience analysis, the client determines that narration should be provided in various portions of the program to assist with difficult word pronunciations. Digitization of this narration will require additional disk space. This factor may also alter the number of objectives, or hardware and/or software requirements. Outcome of these decisions may require negotiations between the client and the team regarding purchase of additional hardware or other issues. Once the analyses, needs assessment and goals are in agreement, a scope of work contract is signed by client and team. This contract outlines precise responsibilities and timelines, as well as specifications of the final product. It is always considered a working document and reviewed as often as needed. Changes can be negotiated by the team or client at any time, but an agreement must be reached by all sides for changes to occur. Design: During design, the team works with subject matter experts to determine appropriate content and to generate ideas for presenting and explaining that content. Flowcharts are produced reflecting the objectives, specific content and interactivity of the program. Once flowcharts are completed, detailed storyboards are written to reflect the program's interface. Storyboards are also evaluated for agreement with goals, objectives, hardware and software capabilities, etc. As the storyboards are written, specific media components that may be needed become more apparent. These include clip art, videos, photo–;graphs, sounds, etc. Collecting this media occurs during design and continues through production. Production: The production phase follows storyboarding and includes not only programming but digitizing video, photographs and audio, if needed. In–;house testing by team members, the client and volunteers may indicate the need to re–;examine various analyses, needs assessment, flowcharts or storyboards. For example, if the client finds that too much content is presented prior to practice opportunities for a user, the objectives, flowchart and storyboards are re–;examined. If evaluation indicates that a couple of images are not of high enough quality for the purposes of the program, software and hardware requirements are re–;examined. Whatever the need, the team works with the client to resolve the problem. Resolution may occur through re–;evaluation of the goals and objectives or renegotiation of the scope of work contract. Formative Evaluation: Formative evaluation occurs throughout the process: Whenever the goal and objectives are re–;examined; when the content is matched with the objectives; when the needs assessment is compared to the goal, etc. Formative evaluation also occurs when the computer program is evaluated by sample audiences, content experts and others. Of course, these evaluations may indicate a need for the team to re–;evaluate the goal, needs assessment, content or any other part of the development process. For example, if users have a difficult time navigating the program, the flowchart created during the design stage is re–;examined; changes may also be reflected in the storyboards. If subjects find the activities tedious and boring, the team returns to work with the content expert(s) to increase interest and motivation. Changes in content will often change the project's flowcharts and storyboards. Formative evaluation affects every stage of the development process. Results of formative evaluations may indicate a need to review hardware and software specifications, leading to renegotiation of the scope of work contract. For example, if the target computer gives error messages on lack of memory, or if the program will not run at the speed hoped for, hardware and software analyses may need to be re–;examined. If the client and team decide additional hardware will be required for the program to run, the scope of work contract must be renegotiated to address financial responsibilities. Keep in mind that the more detailed the analysis at the beginning of the project, the less time will be spent on hardware and software issues later. Final Production: After testing, testing and re–;testing, as well as continuous reviews of all stages of the process, the final product is produced. Once the product is "in hand," evaluation takes place again. Results could send the team on their way to deliver the product to a client or back to the lab to fine tune certain portions. Perhaps the team finds the final product (a CD–;ROM) is not performing as expected on the target computer . A program running from a computer's hard drive behaves quite differently than the same program on a CD–;ROM. At this point, decisions can affect the entire design process. For example, if the client decides to remove certain features, such as videos that are requiring long load times from a CD–;ROM, the content, objectives, scope of work contract and other steps in the process may need to be changed. Decision making in the development process is like throwing a rock into the middle of a pond: the ripple effect can go on and on. However, decisions that result in changes to a program should not be avoided. Sometimes the "waters need to be stirred up." But balance this with the fact that changes are also time consuming. Therefore, careful decisions made at the beginning of a project helps keep the waters calmer later and prevents unnecessary delays. Perhaps the following suggestions will help keep decisions that cause major changes to a minimum: The more detailed all analyses, the greater the chances that fewer changes will need to be made later in the development process. Know the exact specifications for the target computer (processor speed, disk space and access time, RAM, etc.) Test, test and re–;test the program on the computer for which you are develo¼ng. Involve as many people as possible in the evaluation (intended audience, subject matter experts, programmers, people off the street). Final Thoughts The development process outlined in this article has provided team members with a shared sense of role expectations and responsibilities. Clients benefit from the process for the same reasons. When everyone on the team understands the processes and knows what is expected of each other, conflicts over assigned tasks and/or procedures are kept to a minimum. When all team members know the direction they are headed and want to get there together, the ride is also smoother and faster. Less time spent on conflict resolution means more time devoted to the actual project. A developer's commitment to follow the process used by the Educational Technology Laboratory at the Medical University of South Carolina is not going to solve every problem encountered on the road to multimedia. However, finding a development process that works in a particular situation is crucial; a well–;planned process significantly increases the chances for a smoother ride. Mary Mauldin is the Director of the Educational Technology Laboratory at the Medical University of South Carolina. E–;mail: mary
[email protected]
This article originally appeared in the 02/01/1995 issue of THE Journal.