Reflections On The Multimedia Authoring Process:
Use of MPC, Steps to Authoring, Platforms, Metaphors,
Languages, and Still Images
by Brad Ryder
for
MCTE 626, Authoring Systems Design
Prof. George Fornshell
School of Computer and Information Sciences
Nova Southeastern University, Fort Lauderdale, FL
TABLE OF CONTENTS
I. MPC Rationale
II. Authoring Process
A. Concept
B. Design
C. Collecting Content Material
D. Assembly
E. Testing and Distribution
F. Personal Experience
III. Authoring Platform Description
IV. Authoring Interface
V. Authoring Languages
VI. Graphic Images
VII. References
MPC RationaleMultimedia systems, in the form of personal computers, are known as MPCs. Many students use MPCs to learn while having fun, and have been doing so for many years. For instance, in a "game" called Geography Search (Tom Snyder Productions), students set sail for the New World. The computer gives information students need to determine where they are and what they must do next. Since this data shows up for only about 10 seconds, the game creates interactive classrooms as students get to talking to each other to solve the problem [Dockterman, 1995].
However, using the MPC system for authoring, perhaps to complement the "fun and play" of interactive titles, can enhance a student's learning experience. By getting down to the research and critical thinking skills needed to create a multimedia program, a student engages in active exploration and creative application. A program called Alphabonk Farm (Headbone Interactive) allows users to combine photographic images, illustrations, poetry, and music to create offbeat animals and farmyards through inventive play [Dyrli & Kinnaman, 1995].
To create the kinds of screens, cards, graphics, videos, and sound that will make for an appealing and interactive multimedia title, an author must use an MPC-compliant computer system. If not, the presentation will fall behind in the quality expected by even the most basic MPC standards. The new MPC3 standards call for a minimum of a 75-MHz Pentium processor (or equivalent), a quad-speed CD-ROM drive, 8MB of RAM, a 540MB hard disk drive, wave table audio, and video-ready graphics. Many vendors, including Packard Bell Inc., IBM, and Compaq, are shipping systems that meet the MPC-3 specification [Crothers, 1995].
Imagine trying to create MPC-compliant graphics with an outdated drawing program, or trying to incorporate high-level sound when you can only use your PC speaker to hear the results. Although there is some expense, no one who is serious about learning or teaching multimedia authoring should be without an MPC-compliant system.
On the other hand, it's possible to get acceptable video from low-end gear for a low-budget CD-ROM or in-house tape for distribution on VHS cassettes. This depends on standards and budget--and on the author's expertise [Heid, 1996].
Of course it's one thing to advocate widespread use of MPC authoring to teach students, still another to make the dream come true. As recently as last year (1995) the biggest drawback was the availability of computers of any kind. While 85% of school librarians had access to a multimedia computer, the number in the classroom lagged behind. Just 32% of teachers responding said their classes had access to a personal computer. Only 20% had computers with an Internet connection, while 17% had on-line services available to classes [Robertson, 1995].
When it comes to learning authoring on an MPC system, students seem to have a better chance at home than in school. However, 25 worldwide telecommunications companies recently created a forum to promote and produce globally accessible, interoperable multimedia applications, and to adopt standards [Sykes, 1996]. With this kind of awareness and concern, the future may be more promising.
In multimedia authoring, as with any creative endeavor, the author needs to do some planning. Without a good concept of the project, it is difficult to proceed to the other stages, for where does one go? In the concept stage the author needs to identify the target audience, the type of application to be used, and the purpose of the presentation. Most of the conceptual planning takes place separate from the authoring application, since it involves writing up a treatment, outline, or proposal about the project. This is a critical process, for if an idea is to be made into a successful consumer CD-ROM title, it must be translatable into a product that fits into 650MB of digital storage, and which can be "assembled by people using existing tools, and finished in a finite amount of time for a finite amount of money" [Rosebush, 1996].
This is where the author actually begins working with the authoring software. Most good tools provide a way for the author to lay out a design: outlining, storyboarding, flowcharting, and scripting. There might also be a slide sorter feature, allowing the author to preview the various slides or screens and move them around. Without such a feature the author must cut and paste, whereas a slide sorter allows drag and drop, greatly facilitating the design process. A program such as MediaForge by Strata Inc. allows drag-and-drop techniques for placing graphics, digital movies, and audio files [Heck, 1995].
In the design stage the author begins to think about the content material: text, database files, audio, video, and still images. Some authoring tools allow the creation of dummy names even before the actual element exists. The dummy names serves as a place marker so that the graphic or sound or whatever can be included later. If this feature is not available, then the author must make a list separate from the authoring program.
Once the design stage is complete, or in many cases even as the design is being done, the author can begin to gather the content material for the presentation. There are many places to obtain such material, depending on what the presentation calls for. If photos are required, then the author must get the photos scanned or perhaps developed in a digital format. A place called Seattle Filmworks can process any film into a digital image that can be converted and used in a presentation.
Other visual matter might include clip art, original art, or video. Clip art can be found on one of the hundreds of clip art libraries available. See nearly any software catalog. Original art is drawn by the artist, either on a digitizing tablet or on paper and then scanned. Videos are brought into the presentation by a complex process using a framegrabber card, time base correctors, professional cameras and video players, and then digitized into .avi or some MPC-compliant format. The sound components can be recorded through the computer's sound card and stored as .wav files. [Note: My source for this information is personal experience, discussions with friends who do this kind of thing, and the various reading I've done on the subject, none of which I can cite formally.]
This is where all the preparation, design, and content gathering come together. The author places the design components graphics, video, sound, text, databases, etc. in one directory and uses the authoring software to link them to the presentation. Some authoring tools do the assembly as you go. However, the components must be where they should be, the names can't change, and they may need to be correctly scaled, cropped, and sized (although this can often be done within the authoring tool).
Assembly is usually done one screen at a time. Some tools (any good ones) allow the author to see all the slides or screens at once and double-click on one to select it. If a dummy name or placeholder was used for a component, and that component is now in place, it may show automatically. Sometimes the link will need to be refreshed or updated.
Before distributing your presentation, run it a few times. Test the links and make sure they go to the correct place. Test the presentation on a variety of platforms; don't assume your users will have the same system you do. You may want to try some systems that don't, or just barely, meet MPC specifications. Not that a good multimedia presentation needs to run on just any computer, but to find out precisely what the minimum requirements are. This may need to be specified in the distribution literature.
My only experience with authoring multimedia was a presentation I created while employed at Crockett Log Homes in Westmoreland, NH. In a professional multimedia production environment, the tasks are divided and assigned to people who create content and people who integrate content into the product. People who create content include writers, photographers, graphic designers, illustrators, animators, videographers, game design specialists, user interface specialists, songwriters, musicians, sound effects people, and video editors. People who process this content into the product include editors, proofreaders, scanner and color correction specialists, video digitizers and QuickTime experts, sound editors, scripters, hyperlink installers, and programmers [Rosebush, 1995].
Although the concept came from the company's president, this was basically a one-man project, so I functioned in as many of the above roles as needed. We put together a basic marketing presentation showing log homes in various stages of completion. We included a sound track of the president talking about his company. We used original artwork, photos, very little clipart, no videos. The presentation was strictly linear, with the different home options being shown one at a time. Our goal (which we did not achieve while I was there) was to create an interactive presentation so the viewer could choose which option he'd like to see and not have to sit through the whole presentation.
Overall, given my limited experience at the time and the limitations of the software (Microsoft's PowerPoint), I believe the end result was quite satisfactory.
Many systems are now suitable for developing good multimedia applications. While chip speed continues to rise, and the pressure is always there to upgrade, it's still possible to do multimedia authoring using dare I say it? a 386 computer. This is provided that it's a DX chip running at a high speed (at least 40 megahertz), and that the system is not slowed by other factors such as a sluggish hard drive or a poor video card.
Still, faster is preferred. Multimedia mixes different media elements sound, text, images, animation, and motion video which really loads it up. To improve its multimedia capabilities, multimedia upgrade kits are available for 386 or better IBM-compatible computers. Kits include a sound card, a CD-ROM drive, and a selection of titles. Some also include external speakers, a microphone, headphones, and a joystick [Shields, 1995].
For an author who uses still images in his presentations, a frame grabber may be needed. These let you snatch a still image from a camcorder or video sources such as videodiscs or tapes. Once grabbed, these images are incorporated into the presentation just as is any other image. A company such as Digital Vision (Dedham, MA) is one source of reasonably priced video digitizers and frame grabbers, with products for both Macintosh and Windows platforms [Shields, 1995].
While on the topic of video, the new MPC3 standard has specified MPEG as the "new standard' for video playback in multimedia PC technologies. Many graphics add-in cards are being bundled with MPEG decoders, and millions of MPEG-ready machines are being sold. MPEG will soon be made available as a free add-on to Windows 95 and Windows NT [Crothers, 1995].
Finally, if motion video is something you'd like to include in a presentation, there are video capture cards and editing tools available, although they are not inexpensive. One example is the MegaMotion card by Alpha Systems Lab (Irvine, CA). It allows for two video inputs, one live (e.g., direct from the camcorder) and one compressed, and displays four different moving images simultaneously in windows on the screen. It is bundled with Adobe Premier software for video editing. The suggested price is $1095 [Shields, 1995].
An author has several interfaces to choose from when developing a multimedia presentation. These different interfaces try to provide a familiar frame of reference for the author, known as a metaphor. Some authors might feel quite comfortable doing all the coding for their application. It is more likely, though, that the author would prefer some simplification of this task. It's also likely that the author is going to need to switch from one application (such as a graphics program) to another (the assembly application). This is where the interface is important.
These days most of the popular operating systems have multitasking capabilities. That is, the author can be working on one thing, then switch to another application (usually with a mouse click or by pressing a couple keys) and see the results of his work. This top-level interface is significant no matter what authoring tool is being used.
When it comes to the presentation package itself, the author can choose from various metaphors, such as the slide show, the book, the timeline, and the icon, to name a few. Perhaps the most versatile interface is the book metaphor, which allows the author to see his presentation on screen in the form of a book. Pages can be lifted to see other pages, and on each page there are a number of multimedia objects which can be manipulated. The book metaphor allows the author to create interactive links, to link from one page to another or to other books. This is an improvement over the slide show metaphor, which doesn't do interactivity well.
Or at least it hasn't until recently. A program called Special Delivery is a multimedia authoring tool that professes to make it easy to create "powerful, interactive multimedia." It uses an interactive slide metaphor and graphical interface, so the author can express ideas without scripting languages, timelines, and flowcharts [Anonymous, 1995].
As far as tasks are concerned, the book metaphor is helpful in the design and assemby stages of authoring. In the Toolbook authoring environment, most handling of multimedia objects is done with the mouse, such as drawing objects, choosing colors, and placing text objects. The author has a tool palette, a command window which allows the author to type in code as needed, and some aids for writing scripts.
A tool called MediaForge has a flowchart to help new users keep track of a production's flow and content. It asks the user to create an empty framework of various backgrounds and scenes. These appear in a clear tree diagram window (the Project List), which also defines the logic of the presentation. A good interface also includes a way for the author to collect and gather all the referenced multimedia files. Then, although it's not strictly an interface consideration, the program should provide some easy distribution, or publish, feature [Heck, 1995].
Anything done on the computer involves programming of some type. The level at which the programming is done is what varies. Low-level programmers who can write and debug machine or assembly language are quite valuable. It's also these programmers who create interfaces to these low-level languages that allow practically anyone to write and develop programs.
My limited experience with low-level languages is mostly with the DEBUG program (an assembly language). Although I still have no idea how typing in those strings of numbers accomplish anything on the computer, I have been able to follow directions and create a couple of programs of my own. One was needed when my printer driver wasn't working correctly. I contacted someone at Compuserve who told me what to type, so I did. When I saved and executed the debug program, the driver worked perfectly.
On another occasion, when I was toying with the idea of learning to program using DEBUG, I found some sample programs and had some fun typing and compiling them. One, as I recall, caused the CLS (clear screen) command to do strange things. Instead of just clearing, the screen would wipe from left to right, or right to left. There were other programs that did bizarre tricks, such as turning the display upside-down, for "lots of laughs" if you wanted to give a friend heart failure.
Finally I decided not to learn low-level languages. I turned to the higher level program, BASIC, and wrote several programs for my own use. One was a grading program. Since at that time I was teaching four or five courses a semester, it was helpful to have a program in which I could type all my students' names, project grades, plus weights for each project, and come up with a final grade. Since BASIC had to be interpreted each time it was run, it was not too fast. When QBasic came out I spent many hours converting my lengthy BASIC source code into modules. Then I compiled the code, which allowed the program to run faster. Unfortunately I somehow lost the code for this program a few years ago.
Another program I wrote in BASIC was for scheduling softball umpires. The City of Keene's recreation department agreed to use the program in its beta version, and the first year there were occasions when it scheduled the same person to umpire at two different fields at the same time. This wasn't hard to fix in the source code, but it had a few umpires who hadn't checked their schedules ahead of time scrambling to find a replacement for that night.
What happened when I moved from the low-level language to the high-level language is akin to what is happening with authoring tools these days. Since it would be very difficult to write programs using low-level languages such as DEBUG, some other interface was needed. The programmers came up with programs where each line of code (statement) actually was interpreted by the computer into low-level language that it could better understand. Once computers became graphically intensive, it was possible to have programs like VisualBasic that utilized this feature.
Now the question is, which development tool to use? There are two options: authoring systems and programming languages. An authoring system does what high-level programs were designed to accomplish: they make programming simpler, essentially eliminating programming from the development process; they allow non-programmers to create multimedia applications. Programming languages such as C, C++ and Pascal can be used for custom applications; they are flexible and powerful, but involve many lines of code. In-house training and educational applications and presentations, however, are usually developed using authoring systems. Authoring systems and programming languages are not mutually exclusive. A good authoring tool will allow the use of programming languages [Strauss, 1995].
This is the area I feel most comfortable and familiar with, since in the past few years I've been working as a graphic artist. And in the only real multimedia presentation I ever created (at Crockett), I got very involved in the selection, positioning, scaling and cropping of all the images, as well as the transitions from one to another. Also, since I started designing web sites, I've had to learn about the graphics that work best (JPEGs) on the World Wide Web and how to incorporate them.
Most photos used in multimedia applications have been scanned into a digitized format. Once digitized, the manipulation of the image depends on the software used. Professional graphic artists wouldn't think of being without Adobe Photoshop and Illustrator, or Aldus Freehand, or Corel Draw. With these you can take a photo and enhance its brightness and contrast, its color, its gamma correction, for instance. Or filters can create special effects such as posterizing or embossing.
Internal resizing can be tricky. A 800x600 pixel image can be presented the size of a postage stamp, or a small 120x70 pixel image could be blown up to a full page. There's a trade-off involved when determining the size of a graphic. In the first instance, the image would be clearer but the size would make for long decompression or downloading times. The smaller image would show up quicker but have lower resolution.
There are certainly many features to consider when buying an authoring tool, but a major concern should be the creation, capture, manipulation, and use of still images. Try to get a program that allows flexibility in the use of various formats. IconAuthor supports 34 graphics formats, and Quest 5.1 supports 31, while MediaForge supports only eight [Petersen, 1996].
Anonymous. (1995.) Special previews: Special Delivery 2.0. Technology & Learning, 15, 5, p. 68.
Crothers, B. (1995.) MPEG puts Intel's Indeo to the test. InfoWorld, 17, 41, p. 42.
Dockterman, D. (1995.) Interactive learning: It's pushing the right buttons. Educational Leadership, 53, 2, pp. 58-59.
Dyrli, O.E., Kinnaman, D. (1995.) Part 4: Moving ahead educationally with multimedia. Technology & Learning, 15, 7, pp. 46-51.
Heck, M. (1996.) MediaForge 2.0 appeases multimedia programmers and authors. InfoWorld, 18, 25, p. 151.
Heid, J. (1996.) Gearing up for multimedia. MacWorld, 13, 2, pp. 151-153.
Petersen, S. (1996.) Buyer's guide: Multimedia authoring tools. PC Graphics & Video, 5, 5, pp. 52-53.
Robertson, J. (1995.) School daze. Electronic Buyers' News, Issue 948.
Rosebush, J. (1995.) A guide to multimedia production staffing. CD-ROM Professional, 8, 7, pp. 32-42.
Shields, J. (1995.) Do-it-yourself multimedia. Technology & Learning, 15, 4, pp. 26-32.
Strauss, R. (1995.) The development tool fandango: Deciding the authoring system versus programming language question. CD-ROM Professional, 8, 2, pp. 47-55.
Sykes, R. (1996.) Forum to promote multimedia standards. InfoWorld, 18, 12, p. 46.