Beyond Data Driven: The Development of Mystic Seaport’s Website

James Blackaby, Mystic Seaport, Connecticut, US

Abstract

Mystic Seaport was faced with redesigning an old website that had grown to an unruly 10,000 files representing more or less 2,000 separate web pages many of which were accessible only by luck or through the use of a site search engine. In addition, there was considerable pressure to make collections resources available online, to develop the online store and e-business opportunities, to serve potential visitors and tourist markets, to develop new online educational opportunities, and solve a long list of institutional ills, respond to a number of strategic plans, and capitalize on many perceived opportunities. The problem was not uncommon.

The solution was to approach the entire website from the point of view of the basic information architecture of the museum, the perceived users of museum information (based on a variety of audience surveys), and a set of realizable information management goals. Institutionally, the website becomes a manifestation of a lively information architecture encompassing collections, programs, products, customer management, the calendar, and publications. In some cases, existing information management solutions were applied more or less directly to the web. In others, new solutions utilizing the web were developed.

Keywords: information architecture; web site redesign; user requirements; information management.

Introduction

Like lots of web sites, the one at Mystic Seaport has gone through stages – on line brochure, medium for educational outreach, repository for seldom referenced (but no less significant for that) materials, collections access point, newsletter.  And, it has gone through the usual management structures – the enthusiasts in the basement who would attempt to do anything that anyone thought to ask for to the open contribution structure where everyone could put what they wanted on the web.  And, like lots of web sites that are now getting close to being ten years old, Mystic Seaport’s had devolved into a chaos of good intentions, bad ideas well executed, good ideas poorly executed, incomplete thoughts, old material, structures that depended on particular software solutions and sophisticated scripting and macros.  Nothing surprising, but nothing that was going to cure itself either.

At the millennium, the site had roughly 10,000 files on it – about half of which were images.  The various pages represented the interests of the roughly 100 passionate subgroups within the organization who saw their materials as what should be easiest to find and most interesting to all – the boat builders, the planetarium, the education department, the communications department, the volunteers who put pictures of themselves on the web,  the purpose statement for the museum and the list of trustees, the calendar, links out to donors, funding agencies, other museums, the indexes to journals now out of print, the chantey singers, the store, the restaurant’s catering opportunities, the online catalogue, and on and on.  These were organized loosely around the organization of the museum – collections, education, administration, etc.  The site had become a snake-pit, and following the example of Odysseus with Medusa, it was decided that the way to get rid of it was to hold a mirror up to it so that it could self-destruct.

That decision was the easy part to contemplate.  The delete button is a powerful tool, and it happened that the museum was in the situation of changing servers and platforms, so there was the possibility of starting with a clean slate.  The hard part was thinking about what to do next.  There were some basic requirements.  The site had to:

1. serve all of the current content providers, but it had to have the means to grow
   
   
2. self-maintaining – neither the initial technarchy nor the subsequent anarchy had served
   
   
3. interest  those of us who saw it ten times a day as well as the one time visitor
   
   
4. provide access to all

We started with a vague idea of where we wanted to go, and we gathered together the skills that we thought we would need – politic coordination, some programming skills, some content skills, and a designer who was willing to participate in the discovery process.  The importance of all four of these elements coupled with a big scoop of imagination and willingness to try things out cannot be underestimated.  Each has contributed to the success of the project.  The steps were to assess and identify, plan and design, establish conventions, realize tentatively, and finally reflect on what happens next.

Assess and Identify

Initially, we did no more than to inventory our current website, try to do some analysis, talk to staff members and interested parties about what they were happy with, what they wanted more of, what worked, what did not, and to look hard at things that we could do to make the whole website work better.  This was not a terribly formal process, though it involved making massive databases, thinking about links and maintenance of links, finding natural collaborations among parts, and doing what we could to put all of the content users at ease about the process and our willingness to accommodate them.

We discovered several things:

• There was little consistency in the naming, placing, or formatting of digital elements.  Popular images of the museum were stored multiple times in multiple places in multiple resolutions.  Pages that had been maintained by staff members no longer at the museum had often just been “papered over” as one might do with wallpaper in the kitchen.  For the most part, these seemed to disappear, though occasionally links to the old pages would surface.
• Everyone’s area of interest was the most important, and the world could be turned in such a way as to realize that interest was probably the center of the universe.
• Though we had lots of information about who our audiences were through visitor surveys, marketing studies, long range plans, mission statements, and the other paraphernalia of running a museum, the website was organized not around our visitors or their experience but around our museum’s organization chart.
• No one really had time to devote to the website.
• Everyone saw the website as the answer to their prayers.
• Everyone who used the website relied heavily on the site search engine because over time, the site became navigable only to those who were familiar with where things had been tucked away.

From this experience, our belief in developing a more centrally managed structure using databases, addressing the creative development of content, and thinking about our audiences was supported.  We determined to organize around the needs of our audiences and to simplify.  After all, the visitor coming from Boston with a family would want to know about the Chowderfest and did not probably need to look up anything in the on-line library catalog.  The researcher trying to find the history of a vessel in the Connecticut Customs House database was probably not going to need to have easy access to ordering a tote bag on line.  Our hope was that users would be able to figure out who they were (and so navigate the site) much sooner than they would infer our institutional organization and its relationship to our current navigation.

Plan and Design

The next phase was to plan, but from the outset, we incorporated a designer in our thinking.  This was more expensive than simply calling a designer in at the end to put some decorative trim on our site, more time consuming, and more fraught with peril, but it meant that our whole team moved forward with a single view of where we were trying to get.  (For a brief commentary on web design that was helpful in explaining to those unfamiliar with the process what we wanted to do, go to http://www.blackaby.com/web_design/)

We roughed out a structure based on who our visitors seemed to be that was drawn from all of the studies, web usage, our own intuition, and consideration of what an electronic visit even meant.   Among our important ideas in this regard was that the physical visitor to a museum moves from visual impressions to people who intervene to help with understanding to underlying data structures (accessed in one way or another by either the visitor or the person they are interacting with) that may be digital.  The virtual visitor starts with the digital content, moves into an array of data, and may venture beyond through people to experience.  This pattern – from experience towards data or data towards experience – is as true of the visitor encountering an object in an exhibit and reading the label created by a curator based on catalogue data as it is of the selection of an item in the museum store and the subsequent transaction with its impact on inventory systems and finance.

We took the overall structure we’d developed to the staff for their comment and contribution in a series of public meetings.  This led to some preliminary design ideas, and those too were taken to the staff in a series of open meetings.  We did not invite the staff to comment on the particulars of the design (though of course, they did) but rather on whether or not the design fulfilled our basic functions – to let visitors know where they were, who we were, how they would navigate, and to provide interest.  By keeping these conversations open and the focus on the function of the pages, we were able to avoid micromanaging the designer for the most part but could still provide useful design related input.

Along with a set of design modifications, a rough site outline was put up  internally on the web so that any changes in the overall structure could be commented, so that people could see where their content was going to appear, and so we could think about directions for future growth.  After looking a some very beautiful computer generated site plans (see particularly the book by Paul Kahn and Krzysztof Lenk, Mapping Websites. RotoVision, 2001), we settled for the reality of sticking 3x5 cards to the wall to begin laying out the site as it currently existed so that we could shift things around to where they were going to be.

Establish Conventions

The site as it existed was a well meaning hodgepodge that had hints of conventions established or ignored, understood and applied, or misunderstood and misapplied, or else not.  Some order was imposed through the use of server generated templates, but file naming conventions, site structure, page structure, the size and form of imagery reflected a broad understanding of the digital world.

A primary concern was digital imagery.  Internally, we had naming conventions for physical photographs – whether of objects or of events, installations, or documentation of the museum and its people.  Besides that, we have more than a million physical photographic items in the collections which all have their own identification systems normalized through the imposition of catalogue numbers.  For digital materials, however, there was no such consistent practice.  Sometimes a digital surrogate was given an identifier related to its source.  Sometimes it participated in an array of ordered identifiers imposed by media or process (such as the 100 images from a Photo CD or the sequence in which pages of a book were digitized). Sometimes the file names were descriptive and the file structures for the imagery provided some kind of intellectual order (such as a series of newspaper articles scanned and given names for the date and headline and then placed in a file structure that had the names of the newspapers as the folder names with all of those folders arranged in a general folder that identified the subject of the whole array of material).  Sometimes thumbnails had different names.  Sometimes thumbnails went in different directories.  And so on.  These were all interesting ideas, but together they were chaotic, frequently repetitive with no easy way to identify repetition, and very difficult to maintain.

We established the following conventions for managing imagery:

1. If there was a unique identifier (preferably one that was computer generated and sequential) for an image that could take the form of a simple number, that was to be used as the root of the image name.  Museum objects took this from the computer generated id number (NOT the catalogue number which is neither constant nor simple nor something that lends itself to multiple iterations in the case of an object with many digital views that need to be stored).  Library objects took the computer generated “bib number” from their MARC records.  Photographs taken by the staff of the grounds, events, and so on, had the convention of using the year and a sequential number through the year (1956-375 was the 375^th image taken in 1956).
   
   
2. When such a unique identifier could be discovered, then such imagery was to be named with that element as its root with the addition of a letter if that was necessary to assure unique values throughout the museum and any leading 0’s to make names of consistent size.  So, for example, the root image name for all museum objects is the letter m with the id number padded to six places, as in m001234.
   
   
3. All of these images were to be stored in a directory array on a server that had as its internal arrangement folders named for the first four characters of the file name.  Thus, the image with the root m001234 would go in the folder names m001 along with ones having roots like m001976 and m001333.
   
   
4. The highest quality digital surrogate that was stored was named with its root plus a hyphen and the letter q.  A “regular” sized image – one of more or less 600 pixels in its largest dimension – was named with the root plus –r.  A “snapshot” – one of more or less 275 pixels in its largest dimension was named root-s.  And, a thumbnail was named root-t.

There were variations and complexity to account for multi-page works or multiple views of a single object, but the result has been a system that allows you to infer the path and file name for any standard sized image by knowing no more than the root part.  A library object with the bib number12785 would have as its thumbnail ../L012/L012785-t.jpg,

For all of those images that could not be handled so neatly, or for those images created casually for the web, the same –q, -r, -s, -t convention obtains to describe size, but the imagery is simply stored (as it usually was before) within the body of the website in directories called images directly below the html pages they refer to.  This imagery is treated entirely as being fugitive.

More complicated was developing a kind of “grammar” for page designs that was based on looking backwards at the materials that we had up on the web and forwards towards what we imagined the design for run of the mill pages to be.  This grammar established that we had a limited set of building blocks that might be combined to make any of the pages that we might want.  The basic units were a text blob, an image, a caption, and a secondary text blob.  The basic formats were vertical, in which case you could have those four elements (though one did not have to have all of them) arranged in two columns, and horizontal, in which case the four elements could be repeated with variations.  The purpose of developing this grammar was to begin imagining how we might generate the web site from a database if we wanted to.  We would at least have a common way of saying, “No – that page is too complicated for us to bother doing  -- it is not ‘grammatical.’”

This grammar was developed along with basic grids for page layout that were established by the designer that followed very traditional magazine layout principles.  These allowed a kind of flexibility, but within bounds, and so far our fears about enforcing a kind of uniformity that would make the site dull have not been realized.  As the site grows, the grammar may change a bit, but for the moment, having this structure has meant that development and management during development have been extremely rapid.

Realize Tentatively

From the point of getting the functional aspects of the design worked out, the site arrangement worked out from the point of view of file naming and organizing, and the basic grammar of the pages, work has proceeded quickly down an increasingly (and happily) slippery slope.

We did some valuable usability testing with nothing more complicated than a paper mockup of buttons and Xeroxes of screen shots using some of the museum’s volunteers and a few people off the street.  Our goals in the exercise were simple – did the vocabulary we’d selected express, could they figure out where they were and where they wanted to be, was the technology of menus and rollovers beyond naïve users.  We made some slight adjustments as a result of this, but more importantly, could proceed with a higher level of comfort.

A working mockup of the site was developed for presentation to staff and trustees to get feedback and thoughts.  This started largely as a bare-bones effort with a fair amount of variation within the design parameters, and few of the more complex databases represented in the structure, but those have gradually been added in as we’ve had time to look at the site and fine tune our practices.  Things like consistently skipping a line after subtitles, establishing how back buttons are to work, dealing with secondary windows that need to open have been addressed in this phase.

The significant result of this aspect of the project, however, has been to really move to the point of thinking about the underlying information structure that maintains the site and the ways that we can take the naming conventions, the grammar, and the structure of the site back to the sources of the information that populates the site.  One challenge that we’ve always faced with the site was that of managing to update it appropriately.  The site is too big to be data driven throughout (though there are certainly many portions that are or can be.)  Some information only existed on the website, some information on the website was repurposed from other museum publication formats, some was extracted from other places.  There was little uniformity, and little in the way of policy or consistent practice that assured that content updated in one place would be updated elsewhere.  Out of this examination of our content, a preliminary information architecture for the entire museum has been developed.  Of course, at this time, much of it is tentative, but having an understanding of what that architecture might be has been influential in shaping what we perceive to be our future steps with the web site and the museum’s systems as a whole.

A Basic Architecture

Simplified greatly, the museum web site can be seen as related to six basic kinds of information – collections, publications, the calendar, products, information about people, and information about our offerings.  One might add information about resources to this mix, but the basic six elements seem to serve to describe the site generally.  A museum lecture and online registration form, for instance, is a combination of information having to do with our offerings, information drawn from a calendar, and information collected from the visitor to the site about themselves. 

Realizing these basic building blocks make up the website has meant that we can address the maintenance of the site not from the point of view of simply keeping the website going – an effort that is difficult and one that seems to lead inevitably to the kind of total revision that the website has required every couple years.  If, instead of maintaining the website, efforts are made to maintain the sources of the information that go into the website that are a part of our normal business practices (there does need to be some kind of calendar, there will be descriptions of offerings, customer data has to be gathered somewhere, collections data does exist), then the creation of an ongoing website has more to do with figuring out how to extract data from those basic sources rather than anything else.  Of course, some of these sources are easier to get to than others, some of them already exist, some of them might easily exist or be tweaked slightly, but some don’t exist an perhaps never will.  Given that, the website can be made to be responsive to those aspects of the organization that can be normalized in ways that invite extraction.  That at least simplifies the issues of maintenance.

What Next

At this writing, the website is about ready to go live for internal review.  This means that all of the pages that are to be in it will be there for data owners to check.  It does not mean that all the tools for maintaining, extracting, and so on are in place, and it may mean that more pages than we like are “hand made” rather than being generated from data structures.  But, the fact that we have a basic page grammar defined, that we know where we might be extracting the data for those pages should or could come from, and that we understand the goal is to create an institutional information architecture that can support the web (and other activities, as it turns out) means that we can begin to move towards a responsibly organized site.  We expect to be live to the public within a few weeks, and we feel comfortable knowing that by focusing our energies on the internal information architecture of the museum and the tools necessary for maintaining that we will also be creating the wherewithal for maintaining the website.

The next phase of the project has more to do with looking out to the museum to think about where we can work more sensibly and effectively with cognizance of our information structure.  The web is the occasion for this effort and perhaps the most obvious beneficiary, but the economies of things as simple as having a standard way of managing digital imagery or having a central calendar or course offering database will have significant impact on all aspects of the museum.