Introduction
Balboa Park Online Collaborative (BPOC) is a collaborative technology project involving 20 museums, performing arts venues, gardens and the San Diego Zoo in Balboa Park, San Diego. One of our initial projects involves re-launching several member Web sites on a common open-source platform that will simplify administration, design, and content production and management. The common content management system will make it possible for organizations with limited technical resources to support robust content production; the shared technology will allow BPOC to more effectively provide technical support to members and build communal on-line tools that can be deployed across multiple institutions.
This mini workshop will focus on the calendar sub-project of our multi-institutional, Drupal Web site deployment. Like most cultural institutions’ Web sites, the sites from our member institutions have a significant emphasis on events – exhibitions, lectures, classes, tours, performances, etc. Commercial calendar products are often not flexible enough to meet the specific needs of the cultural heritage field, forcing many museums to make do with inadequate calendaring systems at great expense. Additionally, the complexities of scheduling events on-line for museums and cultural institutions (e.g. a tour that takes place every other Monday, except for holidays, when it happens on Tuesday) often leads to either inefficient or, on the other end of the spectrum, overly complex calendaring software that non-technical staff are loathe to embrace and technical staff are loathe to support. Finally, in a multi-institutional environment like Balboa Park, there is significant need for a centralized, automated calendar system that will streamline workflows for marketing and publicity staff by simplifying the data entry process and allowing the institutions to both coordinate events with their neighbors and distribute accurate event information to other media outlets and social networks en masse.
What Makes a Cultural Calendar Unique?
Most of the 85 Balboa Park institutions have a Web site, where they publish event data. But the cultural events vary widely from institution to institution within Balboa Park. They can be very large and complex (art exhibitions), very short (30 minute hike), ongoing (every 3rd Saturday at 1pm), or part of a series (films about geography with lectures following). A great many discrepancies exist between each institution’s calendar data as a result, presenting a challenge for the centralized calendar located at http://www.balboapark.org, because the data is categorized, sorted and styled differently. The BPOC aims to give members the option of adopting a common event framework and providing a unified park-wide calendar for the public on http://www.balboapark.org, as well as for further distribution to media outlets, social networks, and other interested institutions.
Collaboration
For the purposes of this workshop, we will review the critical project steps and challenges of building a complex cultural calendar. Collaboration has been key in demonstrating our Drupal-based cultural institution calendar system as well as our ongoing development of a centralized Balboa Park calendar.
Throughout this process, we have consulted and collaborated with a variety of interested and related parties, including staff from BPOC member institutions, to get their input on how the calendar piece functions currently and how it needs to be improved in their individual institutions. We also consulted with institutions outside of Balboa Park, including the Indianapolis Museum of Art technical staff, on how their calendars were constructed and what challenges they encountered during the development and deployment phases. Based on discussions with the IMA staff, we also brought the firm Palantir on board for additional planning, development and deployment consultations regarding the centralized calendar.
Through workshops like these at Museums and the Web, as well as other industry events, forums and conferences, we plan to present the design process, including the prioritization of user experience for museum staff, members and the public. Key elements we need to communicate to both technical and non-technical staff and the public include the challenges of creating a user interface that can effectively communicate the depth and breadth of events while encouraging greater user engagement; our process for aggregating data from various sources, including direct data entry; and our approach to pushing existing data using an API and for exporting aggregated calendar data via API and RSS to other Web sites.
User Scenarios
During the collaboration phase, we constructed a fictional set of user scenarios which help to explain how the individual institutional calendars, the centralized calendar, and the general public will eventually interact on-line.
Museum Users - General
Mary works at a museum, the San Diego Beach Museum, using Drupal, and wants to enter in a new event. She logs into sd-beach.org, and goes into the private section where she can add new content. Sometimes Mary has all the details about the event already - adding it to the Web site is really just the last step in making it 'official'. Other times, though, it might be for a new exhibit that's not going to be arriving until late next year, and the details are still very sparse. Mary first picks what kind of event she's going to be entering (a Film, or Exhibition, or Lecture, etc) and then gets presented with a form that contains just the necessary fields for that kind of event at her museum. Mary fills out as much information as she can, and then saves the new event. She knows it will automatically show up on the museum's site, and pretty soon everywhere else too! Occasionally, new information comes in later, and Mary needs to update the event. She goes back to sd-beach.org, finds the event she already entered, and starts adding more information. Quite soon most of the other Web sites that use the events from her museum will have the new updated event information too, and everyone will be up to date.
Adam is at the Natural History museum, and it runs its own site. This museum doesn't use Drupal - the IT staff is top notch and has built out a great Web site using other technologies, but the museum is still part of the Balboa Park Online Collaborative. After a particularly thrilling status meeting, Adam sits down to get those new events they discussed onto their site. After he's done, the new events will show up on his museum's Web site as usual, but they'll also get sent out to the central calendar thanks to the custom programming bridge Adam, James, and Daniel wrote to connect the two sites. It didn't even take that long to write the bridge code, since another museum also uses the same technology!
Bob works at a museum tha’ts not part of the BPOC: the San Diego Taco Museum. They are neighbors of Balboa Park, though, and really want to get in on the calendar that is fast becoming indespensible for San Diego residents and visitors. After lots of meetings with James and Shelly and the rest of the team, they have a number of options. They could use an RSS feed to send the data over to the central calendar, or build a custom bridge like the one at the Natural History museum to move data over. Another option is relaunching their Web site using Drupal and using the same calendar and event system as the BPOC member museums. While they really like Drupal and want some of the more powerful content management features, the Taco Museum just don't have the budget for it, so they decide that Bob can have an account on http://www.balboapark.org and can create events right on the site. Shelly still has to approve them before they show up in the calendar, but at least he can tell people about the Carne Asada Burrito eating contest without too much work.
Alex is getting ready to plan a big gala luncheon at the San Diego Beach Museum honoring San Diego's greatest news anchorman, and checks the calendar for August 17th to make sure there are no conflicts. Every so often there's a big event that affects the entire Park, like the annual Carne Asada Burrito eating contest. There's a data feed coming from the central calendar back to the Beach museum, which Alex checks periodically so they can add in important park-wide events to the Beach museum's Web site. Even though most of their visitors aren't going to eat Burritos, it's important for them to know - parking is just terrible while it's going on! Luckily, the 17th is clear, and Alex can start calling caterers.
Museum staff - system administrators
James is a manager at the San Diego Beach museum, and needs to add a field to all Film events at his museum, now that the marketing team has decided they should really tell people what the Max Capacity is for each film. James goes to sd-beach.org and logs in using his administrator credentials. He finds the link to configure the Film event, and enables the field Max Capacity from a list of fields common to all events. It's already configured to display as a select list on Mary's screen when she's entering a new Film, along with a standard set of options. While he's looking over the form, James also checks to make sure that all the other fields they want are appearing on the new Film form. James can also add a field that's just for the San Diego Beach Museum here, even though the field will only display on his museum's Web site. The central calendar or other sites probably won't know what to do with it and will ignore the extra field. If James does want to get a new field or event type that's recognized throughout the system, he'll have to make a request to the central programmers to add ir, and they will deploy a new version of the event system as soon as they can, just as soon as they're done playing Halo 3 and planning their weekend in World of Warcraft.
Shelly runs the central calendar at http://www.balboapark.org. She gets to her computer in the morning and, after coffee of course, checks the event queue to see what's been added all over the park. She gets to pick and choose which events are going to make it on to the central calendar, but in general she likes to get as many in as possible, especially the ones her kids will like! Every once in a while, Mary will call her up and ask about something she entered a few days ago, and how come it looked so terrible when the event got to the central calendar? Shelly has enough insight into how the system works to be able to walk Mary through fixing the funny title characters and getting all the images to show up properly. Once all the events are entered and approved, the central calendar can make sense of them all and how they relate to each other. This part of Shelly's job doesn't take too long, which is great, so she has more time to help all the other tech people in the park with their technology problems.
Daniel is a programmer at the Balboa Park Online Collaborative. He likes his job pretty well, but he'd like it a lot more if he didn't keeping getting damn requests to make changes to the event system! It already works perfectly well, as long as you always remember never to have a 'Q' next to a 'Z' in the name of an event, and make backups regularly just in case something bad happens. Right after he gets back from a nice sushi lunch at the Japanese Friendship Garden, he sees an e-mail from James, asking him if there's any way to possibly add Organ Recitals as a new kind of event. "Could be worse," he figures; "good thing I built a way to do this kind of stuff easily!" This isn't the first time Daniel has received a request like this, and he hates to have to do things manually. The last time he worked on the event system, Daniel spent a little extra time making sure he had a good deployment system in place. After creating the new event type and adding some really useful fields to it (Number of Ranks and Manuals), and testing it on the development server, he saves out a new version of the event and calendar software. After that, he deploys the new version to all the museums and can get back to "real work."
The public
Patricia works on a cruise ship, helping the guests find fun things to do during all the port stops. San Diego is one of her favorite cities - she loves sunshine, palm trees, and practising Spanish. At the central calendar Website at http://www.balboapark.org, she can run a search that lets her narrow down the events to things that are happening that day. She also gets rid of all the evening events so that guests won't be left behind and have to walk home to New York! She prints off a list of the events at the Park, highlights a few for the captain to include in his morning announcements, and goes back to work on printing the ship's daily schedule.
Francis loves going to the San Diego Natural History Museum, and checks the Web site frequently. He uses Google Reader to make sure he has enough blogs and articles to read every evening after work. He'd like to add a data feed for the Natural History Museum to get a better picture of what's coming up. The last time he checked the Natural History Museum's site, they had a bunch of pre-made data feeds he could pick from, or he can set his own parameters and get a feed tailored just for him! Organ music and IMAX films mostly, as it turns out. Of course, the Natural History museum has lots of these, but Francis is also thinking about adding a data feed from the central calendar to tell him where these kinds of events happen all over the park.
Steve runs the San Diego Worder (a local newspaper), and like any good business owner, he tries to understand his customers. A lot of them are really into this thing called Balboa Park, and Steve is determined to figure out a way to use his newspaper to publicize events at the park. Even though his paper is small, they have some pretty fancy publishing technology, and it includes features for automatically getting content from outside sources. Since all the event info is grouped together at the calendar at http://www.balboapark.org, Steve calls up Shelly and Daniel and makes his pitch: "Why don't you guys send out your data in a way that my system understands, and I'll list 5 events on the first page of the Style section of the Worder every day?" Steve gets to pick the top 5 he wants to show, and it's almost no work for him since everything ties right into his fancy publishing software. Shelly and Daniel think it's a great idea too; they just have to write the code once, and all the BPOC members can have their events publicized (the Worder has a surprising number of readers). As an added bonus, if they can find other newspapers using the same software as the Worder, it'll be easy to send them data too!
Development Process
We have hired a content editor to, among other tasks, interface with the existing staff that have managed balboapark.org for over ten years to get their perspective on working challenges, requests and insights for the new centralized calendar. We are also working to establish a park-wide style guide for park events.
The project was broken in to several phases:
- A base Drupal calendar with all of the data related to a cultural event. In phase one, we deployed new Drupal sites for individual institutions that make use of the event management system and display basic calendar functions on a museum Web site.
- An advanced administration interface for controlling events that take place on multiple days but are not truly repeating
- Central Calendar with aggregated transfers from members/satellite sites and the ability for direct data entry, editorial control, and event modification. Ability to have both central and distributed control over taxonomy for event types
- API for data to be accepted into the central calendar from non-Drupal member sites
- Ability for select central data info to be pulled in to satellite sites
- Ability to create feeds from the central site to other potential partners.
Calendar Display
Since the calendars are deployed on sites that are very different graphically, the public facing calendar display of event data will vary from organization to organization. However, for the central calendar, we needed to work out usability issues we saw in working with huge calendar data sets.
Reaching Beyond the Park
In addition to building APIs from Balboa Park members' non-Drupal sites to the central calendar, we are also working on connecting the central calendar to allow outside publishing systems to make use of Balboa Park event data and publishing event and calendar solutions for other museums to use or build upon. We will allow users to add or edit personal events to the central calendar, with approval or moderation required from the BPOC content staff. The next phase might involve allowing users to create a personalized schedule of events, mapping out a week (for example) while visiting San Diego with the family, integrating the central calendar with classroom learning software packages, and eventually integrating on-line payment processing and reservation systems.
Development Challenges: Data Entry and Scheduling
Several technical challenges arose during initial development (e.g. can the values of a field be altered on a per-museum basis, or would they have to stay consistent across the entire system?) as well as conceptual challenges. The goal was to create a calendar that was capable of supporting different types of events. In some cases each type will be handled uniquely (theming a Film is different from theming an Exhibition). In other cases, they will be treated identically, such as exporting all events to a Newspaper's API, in which case an external party will decide how to handle the event data.
Data Entry
We also tackled challenges surrounding controlling the data entry process. The admin interface for each event should be tailored for the specific type of event the user is entering. This is to keep the interface as simple as possible, preventing clutter and encouraging adoption by users. Ease of data entry is a high priority. Events should require as little data as possible. Even within a particular event type, there is some variety in the information to be entered, and the user may not have access to all of it immediately. On the theme level, designs should take into account potentially missing portions.
Each museum should be able to make small modifications to the event definitions, within the bounds of the common underlying data structures. For example, a Film is considered to be a certain subset of the possible event fields. By default, it may include a price. But the Free Museum never charges for Films, so they would like to remove that field from the data entry screen. The event created is still treated as Film, equivalent with all others from the other museums. Overall, regarding data entry, the event fields should make use of auto-complete functions to facilitate data entry as much as possible and enforce a uniform style to reduce human error.
Like many content management systems, Drupal provides a means to specify recurrent events. However, a number of limitations complicate the entry of recurring events. Recurring dates can only specify a single repeat rule. This makes it difficult to specify an event that occurs, for example, or every Wednesday and Saturday. Furthermore, Drupal’s recurring date mechanism has a minimum granularity of a full day. As such, it is impossible to specify recurring events that happen more than once per day.
In order to provide ease of entering recurring date values, BPOC has worked with the Drupal community to create a more robust Date Repeat module. This module extends the existing Date Repeat feature set to support multiple recurrence rules, additional arbitrary date values, and exceptions to those values.
Scheduling
Scheduling complexities have proven to be one of the more difficult elements in the development process. Related events should be able to belong to a container of some kind; for example, a film series, or a set of lectures around a theme, or separate classes that are all part of the same program. The container does not have to contain date and time information, but should contain general information about the events within. Date and Time selection should present as much flexibility as possible, especially in regard to repeating events. Events may repeat every Tuesday at 1:00pm, for example, or the 4th Saturday of every month, or 4 times every weekday. Accounting for every possibility and every exception is challenging; therefore, we devised an interface that allows users to set one date/time series or pattern, and then subtract individual events as exceptions, keeping the series of related events intact.
The solution must be reusable, deployable on a number of Drupal sites, and maintainable and upgradeable across all those sites as well. Events output data through views, calendars, RSS and iCal feeds, and can export/publish to other Drupal sites or external aggregators.
Conclusions
This paper has presented our approach to creating a cultural calendar that can be shared and adapted in a multi-institutional environment, centered on the http://www.balboapark.org portal. The portal now serves as a gateway to Balboa Park organizations on-line, simplifying the on-line experience for those seeking information about park resources and events and providing new opportunities for exploration by on-site and on-line visitors. Although BPOC will continue to develop and maintain the shared calendar tools, event information will be contributed and maintained by the participating organizations themselves.
As we move forward with redesigning and rebuilding the entire http://www.balboapark.org Web site, with features like the centralized calendar of events, original content from BPOC staff, and a commons area containing digital collections from member institutions, the site will begin to serve as a model for innovative uses of on-line technology in a multi-institutional setting, and as a place for combined collection searches and educational tools.
