Willy Lee, The Minneapolis Institute of Arts, USA
Abstract
Over the past few years there has been a fair amount of talk about the reuse of content, but how can we plan our projects to provide for the reuse, not only of content, but also of applications and tools? This mini-workshop will examine the planning processes behind The Minneapolis Institute of Arts's collection area programs and how these led to the development of a toolset that allows for the rapid development of new programs.
Keywords: planning, reuse, content management
Introduction
Museum Web sites are all the same. They do all the same things in all the same ways. Beyond that, they often present the same application in a handful of slightly different ways. How different is an exhibition preview from a permanent collection viewer? How often do we need to present a series of related images? By identifying the core similarities of these applications, we can create basic applications that can be quickly customized to play new roles.
This is not to be confused with simple content reuse. Content reuse is a well-covered topic. For more information about how to reuse article texts, images, and other assets, consider content management systems, server side includes, or even basic authoring tool features like Dreamweaver's library function. These tools will help you take the same assets and use them in various ways on your site, such as having the same description attached to a work of art in two different sections of your site and allowing you to edit it once to change all appearances of this text.
The Minneapolis Institute of Arts's Application Reuse
At The Minneapolis Institute of Arts, we recognized this pattern of similar projects early on, but failed to leverage it to the fullest. We would often find ourselves copying the entirety of a project to a different directory and simply making edits to the older project to fit the new projects needs. This manual process was simple to manage and worked with little technical heavy lifting.
Years later, as we grew more proficient in application design and server side scripting, it became clear to us that by breaking similar features out into self-contained applications, we could quickly reuse the programming with much less technical work and move this function to non-technical staff.
How To Plan For Reuse
Two Keys To The Planning Process
The two concrete parts of the planning process that this paper refers to are the specifications document, referred to as the spec, and site wireframes. The spec is a plain text document written without much technical detail. Using clear statements, it spells out the goals of the site along with the details of some of the features the site must have. The site wireframes are diagrams that roughly show the parts of the site and how they relate. Many wireframes are simply pencil sketches of the pages of the site with a quick site map attached.
Identifying Similarities And Specifying What Is Different
The first step is simple. Find as many similarities as possible in the projects you are already pursuing. Do all of them have a way to send an e-mail reminder? Would it help if they did? Does it make sense to create a single way to manage that? In many cases it does. Not only does it reduce the work that you may have to do, but it also provides a consistent way for your users to interact with a feature. This often does wonders for site usability. It often helps to wireframe out a few different instances of the application and note what stays the same. These concepts get transferred to the spec in must and should statements like the ones below.
- The application must provide the end user a method for viewing a number of thumbnail images with basic label copy.
- The thumbnails and the title text must link to a page to view the image larger accompanied by longer descriptive text drawn from the collections management system.
- Detail pages should contain navigation to the next and previous items as well as back to the thumbnails.
The flip side of this is spelling out what should be customized to each application. Specificity rules the day. It sounds banal, but one person’s obvious statements always seem to be news to someone else. Examples follow.
- The application must allow the museum to select for all colours including the background, text, and all links. The application should also include a method for inserting custom background images.
- The application must allow the museum to select the URI that is returned upon completion of the task.
- The application should allow the museum to specify a css file for the application to further refine the display of content.
Possible Mechanics Of Customization
css and xhtml
One of the easiest ways to customize common pages is css and xhtml. By separating content from display, you can build a site that has the same information but different displays for different communities. So one set of styles could be used to deliver your standard Web page, while another could format it for use in a screen reader. Besides accessibility, this can branch into pages for print or even mobile phones.
Forms, URI Parameters, And Simple Scripting
Using a simple scripting language like php, ColdFusion, or ASP, developers can create easily customizable applications by simply passing environment information in form fields, URIs, or cookies. With great care, this method can also be used with JavaScript.
Flash Applications With External Media
Macromedia Flash can also be designed to behave this way. Applications can draw their text in from databases or external files. External image files can also be drawn in as needed. By creating applications that use these eternal files, it becomes much easier to repurpose these applications for other uses.
Looking forward
By planning for this kind of reuse, museums can get much more out of money spent on contractors or time spent by in-house staff. Often the small amount of additional time spent on these features pays off ten-fold later on.
Cite as:
Lee W., Planning for Reuse, in J. Trant and D. Bearman (eds.). Museums and the Web 2006: Proceedings, Toronto: Archives & Museum Informatics, published March 1, 2006 at http://www.archimuse.com/mw2006/papers/lee/lee.html