The Collection and Management of Assets in the Production of a Multimedia Program on Yeats

Introduction

Developing multimedia titles necessarily involves the collection of information in a variety of formats: text, still and animated graphics, photographs, video and sound. If the scale of a project is large, managing such resources, or 'assets', can be problematic. This paper describes one approach to the cataloguing and management of assets which has general applicability to the multimedia title development process. As such, it should be of interest to any involved in electronic publishing.

The work referred to in this article was carried out as part of a larger multimedia guidelines research programme, as aspect of which is the production of a teaching resource on the life and works of the Irish poet, W.B. Yeats. The resource is being designed as an introductory program, suitable for use in second- and third-level English Literature courses. The production of the tool for cataloguing and managing resources was a by-product of the initial stages of this work. The research catalogue will be published at a later date in both paper and interactive versions and will be useful in the production of future multimedia, radio or television programmes relating to Yeats.

Because of the need to manage large numbers of multimedia files and the relevance of this topic to title production generally, a multimedia asset research and management database tool was developed.

Brief Description of the Multimedia Title-development Process

Because multimedia publishing is a young field and commercially sensitive, the published literature on multimedia production processes is not yet substantial. Some key published references are Bunzel (1994), Hoffos (1992), Howard (1992), Mallon (1994), Philips (1992). And, as in film and television, most multimedia title production operates in a 'seat-of-the-pants' fashion,Ñdevelopers often responding to each project's requirements in an ad hoc manner, according to the development team's composition and experience. It is possible, however, to break down the production process into a sequenced structure of key tasks, even if many counter-examples will be found in practise.

As in film and television, the multimedia title-development process can be divided into three phases: Planning, Production and Post-production.

Planning
• Framing the brief
• Producing a treatment
• Researching assets
• Copyright clearance: approaches to archives or stock houses (specialists in the sale of audio, photo, video clips for general use)
• Scripting and Storyboarding
• Product specification
• Commissioning talent
  Production
  • Collection and translating assets
  • Originating assets (graphic, sound, video)
  • Programming
  • Designing product packaging
  • Writing support materials
    Post-production
    • Program editing
    • Prototype testing
    • Prototype evaluation
    • Mastering and reproduction
    • Support materials reproduction

Phase 1: Asset Research and Program Design

Who will use the database? The project research assistant, program designer, graphic designer, audio-visual designers/production engineers. Who designs the database? The project manager/interactive designer and research assistant. Who is responsible for maintaining the database? The research assistant. How will the database be used?

• The research assistant will use it to record and catalogue assets identified as relevant to the program design/subject area.
• The research assistant will need to respond to requests from the interactive designer, graphic designer and other production designers for particular assets or asset types, or assets relevant to a particular human subject or topic or year or place.
• The research needs to be able to log information relating to the acquisition of an asset from a third-party archive or agent. This should include names and addresses and contact lines of an artefact holder and copyright owner, incl. cross refs. to separately-filed communications with that party.
• The database should be easy to use and contain an on-line help facility.
• The facility to generate printable, editable lists of assets grouped under user-selectable categories should be included.
• The catalogue should be readily translatable into print form.
• The catalogue should link assets which have been digitised, so that assets referenced are easily consultable.
• The catalogue should be publishable in printed and interactive versions, to facilitate future media background research on the subject, W.B. Yeats. The interactive versions should be consultable on a standalone desktop computer, i.e., distributable on disc, and accessible over the internet as a HTML WWW document.
• The catalogue should be sufficiently generic to speed the creation of similar multimedia asset catalogues in future projects.
• The cataloque should reference the source of an asset.
• The catalogue should employ a reference system which allows each item to be identified by a unique number and/or letter code, and by the type of asset (whether textual, graphical, photo, animation, sound or video).

Navigational and other features

To enable the user to

• Browse items sequentially.
• Access graphic, motion video, and sound files
• View files in 16-bit colour
• Randomly access items via category headings.
• Randomly access items via category contents.
• Find text strings input by the user.
• Create new index screens.
• Delete existing index screens (confirm to delete)
• Group and sort items variously

Design for Managing Assets within the Production Environment

The Final Design

Figure 1

Fields and options at left of screen:
• Reference. A reference code for sorting purposes.
• Type. Whether the asset is a photo, a graphic, a sound, a video or an animation file.
• Title. A descriptive title for the asset.
• Iconic image. A small image to give an idea of the content of the file. In the case of the sound files, there is no image.
• Make link. Pressing this displays the file at its full screen dimensions.
• Source. To indicate who supplied the asset.
• Date. The date of origination of the asset. When broadcast, or created by the original copyright holder.
• Copyright holder. To indicate who currently holds copyright on the asset. Note that the copyright holder and the source provider may be different.
• Notes. A catch-all field.
• Cross references. References of other assets contained in the database which relate in some way to the current one.

Options at bottom left of screen:

• Contacts. This jumps to a database of all the people and organisations contributing materials to the project.
• List. This displays a list of all the assets.
• Files. This displays a list of all correspondence files from asset providers.
• Exit. This quits the program, after first displaying a dialogue box, "Are you sure you want to quit?"
Options at top right:
• Delete card. Removes the current card from the database. Because the action of deleting a card can not be undone, a dialogue box appears: "Are you sure you want to delete this card?"
• Find. A dialogue box appears which invites the user to "Enter the name of the text string to look for". The user can enter up to 32 characters. If the string is located, the program takes the user to the card containing the string; if not, an alert message sounds.
• New Card. Click to create a new card with blank text-entry fields. The card is inserted into the card sequence immediately after the current card and, once inserted, the user views the new card.
• Left arrow. Quickly jump to the previous card in the sequence. This arrow is concealed if at card number one.
• Question mark. Displays a scrollable text field which describes the buttons and text fields in the same fashion as this explanatory text.
• Right arrow. Quickly jump to the next card in the sequence. This arrow is concealed if at the last card in the sequence.
Fields and options at bottom right of screen:
• Program reference. This refers to a reference code assigned to an asset file in the program's storyboard and product specification document.
• Link to file. This display the programs storyboard diagram, enabling the user to visualize where in the interactive program the file is used by cross-referencing the program reference code.
• Digitised. Has the asset been converted to digital form yet.
• File name. The file name under which the file is stored digitally is not the same as the title name. The title name is descriptive of the content of the file. The file name must conform to a file naming convention devised by the interactive designer and conforming to file naming conventions on, in this case, the Macintosh computer.
• File format. The file type,Ñwhether the file is a PICT image, a MOV or Quicktime movie, or an AIFF or SND sound file.
• File size. The size in Kb of the file. This is useful later when it comes to adding up all the file sizes to check if the finished program will fit onto its target distribution medium.
• Program caption. This will be a text string which may or may not appear alongside the image in the final interactive program.
• Credits (acknowledgements). The message which is to appear in any final program Archived. Whether the file has been back-up. This is a note to remind the team that a copy of the file should be stored as a safeguard in case the original file is damaged.

This article has concentrated on highlighting these problems and suggesting how best to avoid them. The multimedia database management system described has been designed to serve the needs of a particular project, the life and works of Yeats; its approaches and lessons, however, apply to the production of any multimedia title involving large numbers of assets.