Palantir.net is pleased to announce the recent launch of the new Drupal Web site for the Indianapolis Museum of Art (IMA). One of the nation's leading art museums in its development of new media content, the IMA is committed to using cutting-edge museum technology as a means to engage and educate its visitors.
We collaborated with design partner Studio Blue and the IMA’s marketing and technical staff to develop a highly functional and visually engaging site that incorporates many of the hottest “Web 2.0” technologies like folksonomic tagging, blogs, podcasts, YouTube integration, and AJAX-style visual effects. The use of Drupal 5 was instrumental to the success of this highly ambitious project.
During the development of the main IMA site, Palantir also simultaneously built the Drupal-based Web site for the IMA's Roman Art from the Louvre exhibit. This site, which was also designed by Studio Blue, leverages the design of the main Museum site to provide users with information about this high-profile exhibit, including picture galleries, a collection of IMA-produced "Webisodes" in a variety of video formats, and a Google Maps mash-up that allows users to view the origin point of various artifacts in the collection.
How do you build a “Web 2.0” museum site?
In late 2006, we were approached by our longtime creative partners at Studio Blue to participate in the development of the IMA’s new Web site. The IMA wanted to elevate its Web presence with an innovative, non-traditional site that allowed them to better communicate directly with its audience. During the discovery process, which went through the spring of 2007, we worked with Studio Blue and the IMA to identify the client’s needs and existing resources and develop a project plan that would bring together the design, content, and technology. It was during this time that the decision was made to use Drupal, which after our positive experience with the Washington University Arts & Sciences site, seemed like a logical choice because we knew it was flexible enough to meet the Museum’s needs. Drupal also appealed to the IMA because it was an open source product and it had been used to build another site they liked, the Science Museum of Minnesota’s Science Buzz.
Throughout early 2007, we worked closely with Studio Blue as they developed the front-end design concepts and content documents for the site. The final Photoshop design files were first translated into HTML by George DeMet. After structuring and proliferating the site’s content, Colleen Carroll then adapted these HTML designs into a completely custom theme for the site, with other members of the Palantir team providing support as needed. Larry Garfield was the project’s technical lead, responsible for Drupal architecture, module development, and custom programming with support from other members of the Palantir team. The Roman Exhibition site was launched in July 2007, and the main IMA site was launched at the beginning of October.
The IMA site is built around four page regions: Explore, Connect, Calendar, and Gallery. Each region has both a closed and expanded version, depending on where in the site the visitor is. On the home page, all regions are in their "closed" form. On all other pages, the Explore, Connect, or Calendar regions expand to show the page content while the other regions remain closed. Each closed region, though, could have a number of different context-sensitive forms. They could use their default front-page version or display an image relevant to the current page.
The solution we devised was to make each closed region a custom block, while the open region is the page content area. We then defined a series of image pools as taxonomy terms, and created "image nodes" using the CCK imagefield module that could be assigned to one or more pools. On any given node, then, the admin can select any given pool for three image regions (Gallery, Connect, and Calendar) or even a specific image. If a pool is selected, custom block handling code selects one image at random.
In order to keep the site feeling new and fresh with dynamic content without ruining performance, the page cache is cleared nightly. That keeps the front page calendar up to date as well as ensuring that subsequent visitors to pages on the site get a new look every day without degrading performance.
Most of the site's unconventional layout is handled via blocks. In all, the site includes 11 block regions. Path-sensitive page templates, one each for the Explore, Calendar, and Connect sections, handle the rest of the site's unique look and feel.
The IMA site includes access to over 64,000 pieces of art in the museum's collection. Rather than trying to import 64,000 nodes, the IMA provided an API for their collection through a system called Mercury. We built a wrapper in Drupal for that system that supported searching the entire collection, and then used a lazy-loading mechanism to create a stub Drupal node for artworks as they are viewed. Although the data for each artwork is pulled on-demand from the Mercury system without being cached in Drupal, creating a node for each artwork allowed us to easily leverage node-related functionality such as comments, links, custom block references (as above), and so forth.
Each artwork page features catalog information on the artwork as well as two sizes of image. A third, larger image is available via an Ajax popup. Users can also read and post comments and tag artwork using a folksonomy system designed specifically for museums.
The IMA is a leading partner in the Steve.museum project. Steve is an open source folksonomy-style social tagging system developed specifically for museums. The idea is to allow visitors to the web site to tag artwork with terms meaningful to them. That gives visitors a sense of ownership in the site, as well as providing the museum with a rich research tool to see how the art-viewing public categorizes a piece rather than how a curator does.
As with the Mercury system, Palantir developed a thin wrapper around the steve system to expose it on artwork nodes. Authenticated users are able to add both new tags and popular tags from other users to any artwork, using either an in-line or pop-up form. New tags are reflected immediately both on the artwork and in the site-wide tag cloud. Steve is also used on the Roman Art from the Louvre exhibition site.
jQuery to the rescue
Despite the large number of visual effects on the site, almost none of it uses Flash. The only place Flash is used on the site is to wrap video files from YouTube and other sources. All other visual effects are managed through careful use of jQuery. We upgraded the site to use jQuery 1.1.4, which opened up a number of useful jQuery plugins to us. By far the most useful were the Dimensions plugin, which has now been incorporated into jQuery 1.2, and jqModal.
There are a number of popups on the site in various locations. Most of the "passive" popups, such a the footer links, use jqModal. More interactive popups, such as the tagging popup and the comment form on artworks, use an iframe and custom page handler. The use of an iframe makes handling forms within a popup easy, since there is no need to intercept the form submission. It also makes variable-size popups easier, as the iframe provides a scrolling interface where necessary.
jQuery made the visual effects especially easy to implement. The static "chunklet" video thumbnails present on each page, for instance, were a simple matter of an animated gif layered over a thumbnail picture, and hidden on-hover using jQuery. The same animated gif is used for all video thumbnails but anchored to a different corner of the image. That gives the impression of different static effects for each thumbnail while keeping the page load small.
Besides the obvious benefits in accessibility and search engine optimization, this approach made development easier as well. Throughout development and even after the site launched, we were able to swap out different effects and interface concepts with relative ease. The entire site was designed for maximum compliance with section 508 Web accessibility standards.
Events on the IMA site are handled using the Date CCK field module. Because events could frequently have irregular schedules, though, we also added optional "custom date" and "custom time" text fields. If used, the theme layer then uses that string in place of the actual date on display. That way, site admins are able to enter multiple dates for an event, and then give it a custom date label of, for instance, "every Tuesday and Thursday in November except Thanksgiving".
Another challenge was the need to share events between the main IMA site and the Roman Art from the Louve exhibition site. RSS was too inflexible for our needs, so instead we took advantage of the fact that both sites are hosted on the same web and database servers. We configured the necessary Views on the main site, and then wrote small custom page handlers for the Roman Art site. The custom page handlers initialize the theme system, switch to the main site's database, load and render the view or event node, and then switch back to the Roman Art site's database. The result is transparent access to event data on the main site with all theming controlled by the Roman Art site, with no data duplication or messy RPC calls.
Innumerable thanks to the various authors of the following modules:
- CCK, datefield, link, image field, video field: CCK is truly one of the key pillars of Drupal. The ease with which we were able to roll out new node types with rich meta data made modeling the data architecture remarkably straightforward.
- Views: Views is the second key pillar of Drupal, and was used extensively on the IMA site. In all, there were no less than 25 views built out in the final version.
- Viewfield: A number of pages on the site are, properly, views. However, we needed them to be nodes so that we could customize what image pools the blocks on that page pulled from. We therefore created a "View node" consisting of just a title and a Viewfield CCK field that referenced the requisite view. That allowed us to have an edit page where we could configure blocks and specify arguments to the view within the node. This "View node" technique is one we have used on a number of sites with great success.
- Pathauto: Given the amount of path-based logic used by the theming layer, we're not sure it would have been possible to build a maintainable site without automatic path alias generation.
- Audio: The site also features podcasts provided by the IMA staff. We leveraged the same Audio module used by the Lullabot team with their podcasts, and to much the same degree of success.
- Path Redirect: One of the challenges of the site was that the information architecture at times called for a page to be its own child; the "explore" page, for instance, is actually the same as the explore/index page. Rather than try to assemble several different menus, we built the site hierarchy into a single Primary Links menu with judicious use of Path Redirect. That allowed us to model the site hierarchy cleanly without any additional code.
- And others, including Devel, Component, XMLSitemap, Menu Tree, Role Assign, and Custom Error.
We were forced to modify Drupal core in three specific places.
- We needed to change some wording in the search module's help text. Since it was not in a form we could not form_alter it, and the locale system was too heavy to load just for one help string. In the end we simply overrode the module for the site and changed the wording directly. Drupal 6, however, will feature a simpler and lightweight way to override selected strings without loading the full translation system, making this sort of hack unnecessary in the future.
- We needed more specific control over how and where comments are displayed. Unfortunately Drupal 5's comment display options are not very flexible, especially with comments added directly to the node body after it is rendered. In the end we had to override the node module and modify node_view() to only show comments inline on blog node types and to let us pull them manually on artwork nodes so that they could appear in an Ajax popup.
- Using taxonomy to create image pools worked well, and we've adopted it for a number of other sites. Athough in this case we used a custom block definition to randomize the image because of the many states the block could take, a less complex setup could easily use a randomly-ordered List View to create blocks as needed.
- The View-as-node trick using Viewfield is also a simple and easy way to have our view cake and eat our node cake, too. The downside is that dynamic arguments in the URL do not work, but can be added within the node directly. All other View functionality, such as filter forms, continues to work normally.
- Calendars are always a challenge, whether using Drupal or not. We have found that the most effective way to build a ranged calendar as on this site is to use the hook_views_query_alter() hook to manipulate the View's query WHERE clause. By removing the parts of the WHERE clause built by the filter form and replacing it with a custom clause with an OR, we can transparently mutate the view to interpret the filter form however we want.
Written by George DeMet and Larry Garfield