The Web Document API   Table of contents   Indexes   Electronic Information Commerce

 
 

Application Solution for the Graphic Arts Industry


 
Jennifer   Yang
  Digital Graffiti
42 Mary St.
Hamilton   Ontario  Canada  L8R 3M9
Phone: 1.905.308.9634
Email: jyang@digitalgraffiti.com Web: www.digitalgraffiti.com
 
Biographical notice:
 
Jennifer Yang
 
Jennifer Yang is the project director for Digital Graffiti, located in Hamilton, Ontario, Canada. For the software project, she worked on the metadata structure and the documentation. She completed a Master’s in English (University of Toronto) and a Master’s of Library and Information Science (University of Western Ontario).
 
ABSTRACT:
 
Production problems were encountered by a graphic arts company attempting to manage and track digital and non-digital items. The SGML importable and exportable solution will be described.
 
 

Introduction

 
Production problems were encountered by a graphic arts company attempting to manage digital and non-digital items. Despite 75 years in the graphic arts business, the graphic artists at Superior Interactive Communications were still constantly looking for elements that were misplaced or used in so many different projects and in a variety of formats. An effective system had not been developed to avoid wasting time searching for parts of a project. For example, a photograph could be scanned in a couple of image file formats, changed a bit, and used in several different places. Being able to find the proper item, quickly, was challenging. To solve such a problem, a user-friendly piece of software was created, importable and exportable from SGML.
 
 

Managing Assets

 
The software both managed assets and was easy to use, which was especially important considering the end-users were not programmers. Physical pieces of art and computer files were tracked on an equal footing – in other words, a database was created and maintained of useful information for both physical and soft assets that a graphic arts company would need. By tracking them both together, a clearer idea would be presented to the user of what items are available, without having to search both a computer and a separate filing system. This in itself saved a great deal of time. Physical assets were considered items not stored electronically. These included art/graphics, photographs, transparencies, slides, blueprints, books/print materials, motion pictures/videorecordings, 3-d artifacts such as exhibits, costumes or props and sound recordings/music. Soft assets were considered digital files – any image, sound, video, application, or text file.
 
 

Extension of Windows Explorer

 
More specifically, the methods used to manage both the soft and physical assets built upon users’ existing knowledge, again making it easy-to-use. Integrated with Windows Explorer, the file management system in Windows 95, the software worked on users’ prior knowledge of how to move, copy, and delete files, making the learning curve zero. In order to add an asset to the database, a user simply had to drag and drop a file into a green folder (called an archive folder) within Explorer. Creating the folder itself was as simple as creating a regular Windows folder. Once the file was within the green folder, information about it could be added into the database. The user could do this by going to the properties sheet (right-clicking on the managed asset to bring up the menu and then choosing Properties). The properties sheet for every file managed by the application was extended.
 
 

Cataloguing Structure

 
The way the properties sheet was extended again reflected the importance of both being able to manage assets and do so easily. The database or cataloguing structure conformed with the guidelines of the Anglo-American Cataloguing Rules, Second Edition. This was done for several reasons. Since the AACR2 is the de facto cataloguing standard, it is a familiar guideline upon which to base a data structure. Anybody who has ever used a library, either a library automation system or card catalogue, would already understand the data structure because the user would recognize the data structure and its fields. Minimizing the amount of time required to learn the software and making it as user-friendly as possible was an important feature of the software. Secondly, the AACR2 standard is taught in all library schools and prepared under the direction of many knowledgeable organizations such as the American Library Association, the Australian Committee on Cataloguing, the British Library, the Canadian Committee on Cataloguing, the Library Association, and the Library of Congress. Building upon such expertise, the guidelines are therefore very complete and designed for practically any situation. The database structure provided a number of fields which would give hints about the kind of information it would be useful to have – a kind of template. Although the guidelines were very complete, they did not adequately address computer files, however, so modifications were required.
 
 

Thumbnails

 
Some of these modifications were improvements associated with the software. For instance, the database structure for soft assets was not extremely detailed because thumbnails of image files and the first frames of videos were included. Users could very easily browse through their managed assets, as a result. Furthermore, applications were automatically integrated with the software when installed, so within an archive folder in Explorer, a user could simply double-click on the file and launch it within its application. For example, a user would see a thumbnail of an image file and could double-click on this to launch the image file within Corel PhotoPaint.
 
 

Physical Asset Management

 
A further, time-saving addition to the database structure was the inclusion of a barcode field, to manage physical assets. First, however, the user had to create an electronic proxy to the physical asset and place it in the archive folder within Explorer. These could be a scanned image of a piece of art, a wordprocessed file for print, a digital photo of a 3-d piece, a sound file for a sound recording, or a video file for a videorecording. By scanning a barcode in the field, the user could associate it with a physical asset and attach it to the object. Later, the user could scan the barcode to bring up the database information for the item.
 
 

Avoids Duplication of Work

 
Another aspect to the management of assets was the creation of an effective search mechanism, which helped avoid the duplication of work if something otherwise could not be found. Duplication of files was also avoided, however, through the use of project folders. Like the green, archive folders, project folders looked the same as regular folders in Windows Explorer, except for being blue. Although a project folder looked as though it contained files (or proxies to physical assets), the assets in a project folder weren’t really there. They were actually links to the assets in different archive folders. The files in a project folder could really be in one archive folder or many archive folders. A project, for example, could be a printed brochure, an advertisement, a web site, or even a television commercial with its various props. The purpose of project folders was to gather files together for a particular project, while at the same time avoiding duplication. If a logo was used in six different projects, it didn’t have to exist in six different places or be created six different times. The logo only needed to exist in one archive folder. If the logo changed, users would only have to change the logo file in the archive folder, and it would be changed in all the project folders – because the project folders’ logos pointed back to the original archive folder logo.
 
 

SGML Importable and Exportable

 
SGML compatibility in general was an important aspect of the project. SGML compatibility offered greater internet compatibility, since it was expected that users would wish to share their data across the web for commercial purposes. Graphic artists, for example, might wish to place their work on the web to promote it. Catalogues could also be easily placed online.
 
SGML furthermore permitted project management, an important part of a graphic arts operation, by permitting hierarchical organization of pieces by client, project, and unit, and the creation of back-ups and a delivery schedule.

The Web Document API   Table of contents   Indexes   Electronic Information Commerce