Using Archives for Education

DMC Ltd 3 La Belle Place Glasgow, G3 7LH Scotland Tel: (+44) 141 333 9400

DMC North America Inc Suite 201, 34208 Aurora Road Cleveland, OH 44139 Tel: (216) 498 3950

email: douglas@dmcsoft.com

Sometimes the power of even simple computer systems applied to archival applications seems immense: in a search of well-indexed and catalogued items every German oil painting from between 1950 and 1970 loaned to a gallery can be identified and displayed in seconds. On the other hand, a relatively trivial task for the human eye, selecting images which contain a particular motif is beyond the scope of most computer applications except in a few well-defined domains. A successful application obviously depends on providing the right kind of query tools to the user. In looking at what sort of queries a computerised archive should be able to handle we soon had to ask more fundamental questions. What is the function of an archive? Who should it serve and how should the different needs and expertise of different user groups be met? In answering these questions it became clear that such an archive has enormous educational possibilities but the traditional hypertext approach to navigating through such material is quite inadequate.

The issues discussed here arise mainly out of work on two specific projects, building an archive of exhibitions and events held at the Demarco European Arts Foundation in Edinburgh, Scotland and the TAMH project, an attempt to build a virtual museum telling the maritime history of the Tay Valley.

The filling of gaps, however, generated new problems. Although, a computerised archive detailing three weeks of round-the-clock activity, and much curatorial and administrative work beforehand, was a great advance on collecting dusty cardboard boxes of letters, catalogues, slides, negatives and video cassettes, it soon became clear that the archive could not be bounded by the three weeks of Festival activity. Of course, this is as it should be. Good galleries are as much about the people they bring together and the links they create as the artefacts they have on display at any given time. So, the archive material spread to include George Wyllie and how his submission to the Beuys in Scotland exhibition came to be created from a hospital bed, a meeting with a Latvian theatre group in Riga several months later and the Foundation director, Richard Demarco, discussing Beuys at one of the schools which performed at the Foundation.

The archive grew and, as it did, outgrew the simple structure which had been developed to present a `What's On' guide. At least, for certain audiences it outgrew that interface, many could find all the information which interested them within the initial structure. How to develop that interface for other users beyond the the initial closely specified domain is an on-going task and raises similar questions to the TAMH project.

The east coast of Scotland between Montrose and St Andrews has a rich maritime history from the Roman transport of troops and materials, through the Baltic trade of the 16th to 19th centuries, shipbuilding and whaling to the offshore oil exploration industry of the present day.

Telling this story, or parts of it, as many museums along its coastline attempt to do in physical terms, and the TAMH project tries to in a virtual museum, may not have immediately obvious links with gallery archiving. However, we began this project with the premise which, ultimately, became a conclusion of the Demarco project, namely, that a common database, a common archive, could service a wide audience with different perceptions and needs. In particular, we saw TAMH as a resource in which schoolchildren (from 6 to 16) could make inquiries about local history, from which tourists could select interesting day trips, laymen or scholars could explore cultural links between local ports and their trading partners, or postgraduate researchers could investigate patterns of trade over the last four hundred years.

The archive in this project is diverse and ever-expanding: it includes databases of individual mariners and voyages dating back to the 16th century; photographs of towns, vessels, paintings, sculpture, architecture, gravestones; reproductions of newspaper articles, official documents, ship designs, merchants' account books; and a range of films and videos old and new. Maritime history, by its very nature, involves big things: harbours, whales, ships, battles. There is not the space in individual museums to tell the whole story. A ship is unique: it may have a role in the history of several places but it can only be in one place at any given time. A virtual archive is the opportunity to bring all the resources together under one virtual roof. Indeed, given the precarious state of some of the physical records on which the archive was based, it was also thought that the facsimiles created in the project would be the closest many people could come to the source documents. Different target groups need different interfaces to the archive material. Different options are available to each of them and the information retrieved, or at least the depth of detail, varies. In effect, whereas the Demarco project was an attempt to build an archive from a gallery, this sought to build a gallery, or a series of customisable, virtual galleries, from an archive.

Hardware

Both projects are PC-based systems with user access to all parts by keyboard and mouse and, to some parts, by touch using a 17" touchscreen. Requirements of the delivery system are fairly flexible and the hardware has generally reflected the typical development platform at any given time i.e. when the Demarco project started the first version was demonstrated on a 486 DX66 PC with 8mB of memory. Now the applications more commonly reside on Pentium P75 machines with 16mB although the first configuration is still sufficient. The specification is based more on the response times one becomes used to than any physical limitations. 24 bit (16.7 million colour) graphics cards at a resolution of 800x 600 are preferred though, again, the applications will perform at lower resolutions. Either 16 bit Soundblaster-type cards for .WAV type audio or DSP2105 based cards for MPEG Layer II audio are used. Data may reside on CD-ROM or on a local hard disk, the latter providing faster access and the applications may be run standalone or in networked configurations.

To experiment with wider access, a World Wide Web/Wide Area Information Server (WWW/WAIS) version was also constructed using a Linux server and the Xing MPEG streamer. An illustration of a Netscape client-side access of this is shown as Figure 2.

Development Software

Both applications have a layer of proprietary flat-file data for fast and simple retrieval but the bulk of archive material is in Microsoft Access databases. This approach was chosen for two reasons. Firstly, the Jet interface simplifies communication with the database in terms of queries and data retrieval. Secondly, Access is relatively friendly in allowing field formats to be modified, or new fields to be added, during development. Although this might be frowned upon as poor analysis in database development terms it recognises the reality of changing user perceptions in a prototyping methodology.

The technology exists to embed multimedia elements directly in such a database but we chose to store only pointers in the database, for reasons of search efficiency (reducing database size), ease of editing (it is easier to examine directories of descriptive filenames than to inspect a few hundred embedded objects in a database of several thousand records) and flexibility of format (only certain formats may be embedded: keeping assets separate allows the developers to add filter software to support any new data type).

At the very earliest stage of developing a What's On guide to the gallery, a case could have been made for choosing a high level authoring tool such as Authorware, or IconAuthor, to build the application. Previous experience warned us about the design and performance limitations such systems impose and it soon became apparent that the components we needed to build would have wide applicability to other archival projects in the future. This suggested a toolkit approach: concentrate on building elements which were suited to this specialised domain, (MacKenzie,1991), and use these primitives to specify the design of larger systems along the lines of Gulliksen et al. (1993). For example a dialogue to enter two items for a free-text search of a database is likely to be available in a high level development system. However, if those two items are a surname and forename, an archival system would require a more specific element which would allow some proximity constraint to be placed on the search so that "John" and "Smith" would be recognised in the context of John Alexander Smith but not where John Brown and James Smith appeared in different parts of the same document.

VisualBasic and C++ were chosen as the principal tools for building these elements.

Data Representation

In storing audio visual data there is a trade-off between storage space and quality. A full-screen 24-bit colour image requires more than 1mB of disk space in most uncompressed file formats. Compression saves space but runs the risk of increasing display speeds unacceptably or, in the case of "lossy" compression, losing elements of value. Nevertheless, for still images we used JPEG compression with a high quality factor (even 8:1 compression represents a significant saving when several thousand images are involved) and a fast decompression algorithm displayed the JPEG images at an acceptable speed (under a second for a full-screen, full-colour image).

Moving images were encoded in QSIF MPEG format with synchronised .WAV audio. This provides for movie playback without extra hardware in a 320x240 pixel window (the relative size of this can be seen from the picture window in Figure 1). Video clips are usually between 1.5 and 3 minutes long. This was felt to be perfectly adequate in terms of quality and length. Should someone wish to see a complete video then it is better to use a VCR than a computer: the archive seeks only to give a flavour of what something was like.

Where audio was of particular importance, the music of the opera Agongo in a Damien Hirst installation, for example, low fidelity audio (11 or 22KHz mono sampling) was used to accompany the video and a separate 44.1 or 48khz stereo version, compressed using MPEG Layer II audio, included as an item in the archive.

Text was probably the most complicated data item because what makes a document important - appearance or content ? In some cases it depends on who is using the archive, in others both are of equal importance. The visual elements of a letter, an early newspaper report, the doodles on the frontispiece of a seventeenth century shipping log may be of as much importance as the words. The problems of settling on any one particular format have been noted by Heijne (1994) and, where there was any doubt as to which was the most important aspect, we followed her suggestion to store both a scanned image and ASCII text.

The methods chosen to represent data are, of course, crucial in determining how a user may search, or navigate through, an archive. It is in this area that the application of computing to archiving is both at its most powerful and, as a result both of poor design and lack of technology, at its most inept.

The first version of the Demarco project had one aim: to show what was presented during the three weeks of the 1994 Edinburgh Festival. As such, the questions a user might ask of the archive were straightforward: `What exhibitions were there of the visual arts?', `Give me more information on the Sarajevo exhibition', `Is there any video material?', `Show me some of the pictures', `What else was there from this part of the world?'. The means by which these questions were asked are shown in Figure 3, touchable areas of the screen with either a textual or iconic representation of their function. As the purpose of the application was only to give superficial information and the paths a user could traverse relatively few, making explicit links between items is quite justified. However, as this archive, or indeed any archive grows, both the types of questions users can ask and the types of user expand. The archive application can then take on a range of functions depending on what the users seek to achieve.

In the Maritime History project, there is still a `superficial information' level. Tourists using the application can specify a few things they might be interested in, some constraints on their methods of travel and TAMH will suggest some sites for them to visit in the area. As this is likely to generate a list of possibilities, the navigation options are still very limited and explicit enough to be hardcoded in a few buttons or touchable text: move from item to item in the list or go back to enter some new search criteria.

The size of the archive means there is also a `deep information' level. In one way or another, a user might ask how many voyages were made from Danzig to Dundee between 1610 and 1620. Now, the way the question is asked will depend on what type of user the system is configured for, as will the way the question is answered, and this is discussed in Building the elements below. The schoolchild might be given a list of dates, vessels and cargoes and the researcher this plus the actual entry from the Dundee shipping log. In either case they will learn that a fair amount of ironmongery and copper kettles were transported. What either user might want to do next is unpredictable. `How does this compare with voyages from another port/another time period/graphically with the last question I asked ?', `What sort of ironmongery?', `What did it look like?', `Does it still exist?', `Why copper kettles?', `Who were these sailors?', `Do any paintings of them remain?', `What did they wear?', `Who bought the goods?' and so on in an almost endless list. This diversity of possible questions cannot be supported by explicit links: there are just too many to imagine. However, all too often in multimedia applications, these explicit links are forced upon the user in badly designed hypermedia systems.

Despite the plethora of guidelines on how to design usable systems (see Kelly, 1993 for a selection) there are still many truly awful products with users `lost in hyperspace', (Edwards and Hardman,1989) or `drowned in associations', (Van Dam, 1987). Without a trace of irony, hypertext enthusiasts report that navigation works `best for information spaces that are small enough .... and familiar enough to users to let them find their way round' (Nielsen, 1989) or `simple hyper-systems tended to be more successful than complicated branching networks; particularly when the only way to change route through the information was by backtracking', (Jacques, Nonnecke, Preece and McKerlie, 1993). In other words, a good map describes an area so familiar you have no need to consult it; an even better one is of a tunnel with only one entrance and exit.

Hypertext has been plagued by bizarre claims that it can `physically represent information in ways that model the cognitive representations characteristic of critical thinking in ill-structured domains, perhaps human thinking in general', Swan (1994). Explicitly linked hypermedia in the simple domains where it has been shown to be effective is not a model of human thinking, it is a simple menu structure and nothing else. Where it has failed, it fails for the same reasons over-complex menu structures in other computer applications fail to work: the user does not know what to do next or where information is to be found. To make the further claim that modelling cognitive processes provides an effective basis for education compounds the nonsense and, following the terminology of J.S. Mill, has been aptly described by McKendree, Reader, Will and Hammon (1995) as the `homeopathic fallacy'.

If we are building an archive, not an educational programme, is this relevant? I think so. Few gallery or museum directors could plausibly argue that their exhibitions do not have an educational purpose. Whereas, at one time, exhibitions provided comprehensive documentation of one theme, showcasing a museum's artefacts in one subject area, increasingly exhibit designers are ignoring comprehensiveness in favour of representative items telling a story, Honan (1990). Yet an exhibition tells one story, from the curator's point of view. An archive has the potential to tell many stories. If we allow anyone to search an archive, as we may choose to do in a computerised archive, we must let them make their own stories. Indeed, the TAMH maritime history project sets out with the aim of letting every user be his or her own curator. We may offer different amounts, and different types of help, depending on the type of user but to take the view that `by giving users concrete representations of differing kinds of connections we will encourage them to think relationally about history' (Swan, 1994), describing Set on Freedom, an educational program on the US civil rights movement with rigid, explicit links is naive in the extreme. Surely no one who thinks of history as narrative, (Danto, 1985), can believe in a truly objective historical account, but to present users with a timeline with five or six selectable events attached to each year of it and to maintain that, with this structure, users are not being lead to a particular view of history but to a `rich understanding of historical periods', (Swan ,1994) defies credulity. Think of this in the gallery archive context. One might, without controversy, code explicit links from an image and description of Heizer's Complex One to items on Walter De Maria, Robert Smithson and other land artists yet the other links which are possible allow for perhaps more interesting stories, links to Stonehenge or Callanish; to Nevada as a weapons' testing ground with this bunker sitting on its edge; to nature in the Romanticism of Runge or Friedrich, or the pantheism of Klee or Marc or natural themes as totems in Beuys. There is no way traditional hypertext with it clumsy arrangement of `hot words' can cope with this number of links so some alternative navigation strategy must be used.

Building the elements

The above criticisms notwithstanding, there are effective hypermedia applications covering large domains. Their success, it seems to me, is based on the fact that they do not force a limited view upon the user by presenting explicit links but rather rely on the user seeking information through implicit ones (Microcosm (Davis, Hutchings and Hall, 1993) or Perseus, (Morell, Marchionini and Neuman, 1993). Implicit links require the user to be active. Not active, as is the case in much so-called `active learning' to the extent of pressing a button but active in thinking. This notion seems to provoke horror in educators, `Students are not historians.', Swan (1994) tells us, `They lack both the knowledge base and the methodological skill to "do history".' A critic of the implicit links in Perseus wrote, `A student using Perseus is not likely to come away with a sense that someone has intended that he learn something.', (Eiteljorg et al., 1992). Translate this critique to the physical gallery or museum and we will be employing curators with electric cattle prods to keep visitors on the preferred route.

I find Swan's concept of `doing history' a depressing one. History is a story if it is anything and there are very few people unable to understand a narrative. If we are going to teach historical skills surely the most important one is how to ask questions. In TAMH, where the user is offered the ability to click on a word and search for information relating to it (any word on a page, not just selected `hot words') there is no guarantee that a useful list of related topics will appear. Similarly, where we attempt to parse a user's free text question based on keywords, the answer to the question may not be the one the user expects. Indeed, the parsing may not even interpret the user's question correctly. A failure of technology? Perhaps, but is it not just a reflection how things are in museums and in interpreting history generally? If, in response to a question, the questioner is offered a pathway, this is the beginning of an educational process. Simply providing an answer satisfies the questioner and kills his or her interest right there. Physical museums are becoming less rigid, `enabling people to think for purposes they have defined themselves', Sledge (1995). In the words of Katherine Lee they are beginning to `escape the tyranny of our truth telling: museums are not God', Sledge (1995). It would be tragic if the next generation of virtual museums failed to learn these lessons from their physical counterparts.

Of course, it is impossible to ignore the difficulties users may face in traversing implicit links, particularly in our case where we set out to serve diverse audiences. Rather than force users down particular paths an attempt is made to offer constructive help. The system can be configured for different levels of user so even the initial appearance will vary from, at its simplest, a menu of categories, to, at the "super-user" level direct access to a range of databases. Analysis of user needs for different groups indicated many components unique to these particular groups. Professional researchers or archivists needed a search mask which could search one or more of the available databases, using, in SQL terms, complex combinations of OR, NOT, AND, <, > and = plus proximity constraints for search terms. Tourists looking for information on a particular exhibition needed a simple keyword selector and forwards, backwards through a list controls. Schoolchildren needed prompts on how to perform similar searches changing only one or two variables. All needed some personalised help on what they might look at next based on what they had requested before.

These components then became building blocks for the different user domains, forming, in the terminology of Gulliksen and Sandblad (1995), primitives, interface elements and forms in a domain-specific style guide (DSSG). Working with these elements in a prototyping methodology allows each to be tested on users and refined before it enters the toolkit. Working only with the elements in the toolkit ensures a proven, consistent interface.

Searching

Being able to search fruitfully is the most basic consideration in computerising an archive and the most difficult objective to achieve. None of our projects has a perfect answer to this problem. Then again, neither does anyone else.

Storing texts as both ASCII files and scanned images, as described in data representation above, allows free text searches to be carried out to identify a document even if it is the appearance of the document which most interests the searcher. For example, a Seaman's Discharge Certificate might contain the date, sailor's name, port of embarkation and date, in the description of the image. However, if a user searches by using the name of the Captain who signed it, it will not be found using the image descriptor. This is where the ASCII representation of the content will allow a match to be made and the searcher may still select the scanned image of the document to view if it is the layout used by a particular shipping company in a given period which is of interest, for example, or the comparison of signatures. There are many performance considerations which become increasingly important as the archive grows. Free text searches on large numbers of documents may take a considerable amount of time. This may be acceptable to the professional researcher who has a very specific query but less so to the casual user looking for occurrences of a name. Should all texts, irrespective of length, be stored within the database to simplify searching or should there be pointers in the database to external documents to reduce the size of the database for other, more common, searches? What is the most sensible way to index text in documents? How efficient would it be to compress text and try to convert text input for searches to the tokens used in the compression dictionary? We do not yet have answers to these questions but hope that optimal strategies will be developed as these projects progress.

Searching audio and pictures is quite another matter. Ideally, we choose a motif, the stag in Beuys' work, for example, and ask for all the images in the archive to be retrieved. Every image in our archive has, among other things, a title, a description and a series of keywords describing it. Some thesaurus-like functions are also present so that searching for `stag' would also match on `antler' or `Hirsch'. Given the importance of this motif to Beuys it is likely that the keywords and descriptions together would allow every relevant image to be found. Unfortunately this will not always be the case.

If we follow the distinction between `things', lions, jellyfish, whatever and `stuff', grass, sky etc. made by Picard and Minka (1995), `things' seem to be good keywords to identify pictures in a textual search. However, try this on a Caravaggio or a Poussin and there are an awful lot of `things'. Try a Pollock and its all `stuff'. Work has been done at MIT in the Photobook project, (Picard and Minka,1995), on computers automatically identifying `stuff' in photographs by recognising properties such as directionality, periodicity, and randomness. Using a set of 98 colour photographs they demonstrated a learning system which picked out leaves, grass and buildings in some examples then propagated this through the rest of the system allowing users to view the decisions and make negative examples. Apply this system to almost any set of ten paintings in a variety of styles and such a system provides nothing of value yet we can, without any specialist knowledge, identify the grass in the picture in fractions of a second. Shape-based recognition algorithms are similarly helpless in searching complex images.

Keywords, for now, are the best we are going to get and they are not without their difficulties. Firstly, Picard and Minka's `annotation by fickle users': cataloguers will describe things differently at different times. Secondly, how deep need a description be? An operating table or surgery is an adequate description of portions of a painting to many but someone researching the portrayal of surgery in particular is interested in the individual instruments no matter how insignificant they may be to the main theme. Thirdly, widely different items may come under the same categorisation, an organ, a stained glass window and a flying buttress may be all be described as `church'.

Our solution is to recognise the power of the eye in categorising based on whatever search criteria the user has in mind. Artist, location, description, keyword, whatever constraints are applied by the user in a search, will reduce the number of possible images. The function of the program is then simply to display the possible candidates as quickly as possible and allow the user to mark the ones which are required. Where it is meaningful, allow users, to select from thumbnails, more images can be on-screen at any given time and display time is reduced which is of particular importance if images are being transmitted over a modem link.

A computerised archive is a rich resource. With the right interface design and search mechanisms it can be far more than a mere repository of data. It can be an aid to gallery management and administration but it can also serve as an important teaching and learning tool for a wide audience from schoolchild to professional researcher. At its best, it can be an individual gallery and museum to every user, where that user is a curator, exploring and inventing links; comparing, contrasting and rejecting and, in some cases, gaining virtual access to some items which would not otherwise be seen either because of their fragility, their size or their physical location. However, if the educational value of the resource is to be realised, the navigational tools we give users must be more powerful and flexible than the simplistic and rigid links which current hypertext interfaces offer.

Danto, A.C., (1985). Narration and Knowledge. Columbia University Press. NY

Davis, H., Hutchings, G., and Hall, W. (1993). A framework for delivering large-scale hypermedia learning material. In Maurer, H. (ed) Educational Multimedia and Hypermedia Annual. AACE. Charlottesville, VA

Edwards, D.M., and Hardman, L. (1989). Lost in hyperspace: cognitive mapping and navigation in a hypertext environment. In McAleese, R. (ed) Hypertext: Theory into practice. Blackwell. Oxford

Eiteljorg, H., Hamilton, R., O'Donell, R., Pearcy, L.T., Wiltshire, S. (1992). Perseus Review. Bryn Mawr Classical Review, 3.5.4

Gulliksen, J., Johnson, M., Lind, M., Nygren, E., and Sandblad, B. (1993). The need for new application specific interface elements. In Salvendy, G. and Smith, M.J. (eds). Proceedings of HCI International `93. Elsevier. NY

Gulliksen, J. and Sandblad, B. (1995). Domain specific design of user interfaces. International Journal of Human-Computer Interaction, 7(2), 135-151

Heijne, M. A. M. (1994). Handling full text electronic documents: a report on the Dutch SURFdoc project. Journal of Information Networking, 2(2). 77-90

Honan, W. H. (1990). Say goodbye to the stuffed elephants. New York Times Magazine.

Jacques, R., Nonnecke, B., Preece, J., and McKerlie, D. (1993) Current designs in HyperCard: what can we learn? Journal of Educational Multimedia and Hypermedia, 2(3). 219-237

Kelly, A. E. (1993) Designing instructional hypertext for use in lecture note review: knowledge engineering and preliminary testing. Journal of Educational Multimedia and Hypermedia, 2(2). 149-176

MacKenzie, D. (1991). Developing CBT Courses for End User Training. Proceedings of the 33rd ADCIS Conference, 345-351

McKendree, J., Reader, W. and Hammon, N. (1995). The `Homeopathic' fallacy in learning from hypertext. Interactions, 11(3)

Morell, K., Marchionini, G., and Neuman, D. (1993). Sailing Perseus: Instructional Strategies for Hypermedia in the Classics. Journal of Educational Multimedia and Hypermedia, 2(4). 337-353

Nielsen, J (1989). The art of navigating through hypertext. Communications of the ACM, 33(3), 296-310

Picard, R.W. and Minka, T.P (1995). Vision texture for annotation. Multimedia Systems, 1(3). 3-14

Sledge, J. (1995) Points of View. In Bearman, D. (ed) Multimedia Computing and Museums, AIM, Pittsburgh, PA. 335-346

Swan, K. (1994). History, Hypermedia, and Criss-Crossed Conceptual Landscapes. Journal of Educational Multimedia and Hypermedia, 3(2), 120-139

van Dam, A. Keynote speech. Hypertext `87