Working out the Wiki

The most basic goal of the ASK app is to connect visitors to works of art in the museum. Although the conduit for this connection will be a piece of technology, its authors will be people not unlike the ones who already give tours and interact with visitors in the galleries today. The difference, of course, is that unlike a traditional museum educator who provides information of her choosing about a group of preselected objects or, at the very least, speaks with visitors about a predetermined area of the collection, the people behind the ASK app will be expected to answer visitor initiated questions about objects from any part of the collection. This is an intimidating task for even the most experienced museum professional or art historian!

Luckily, there are some additional differences between the traditional museum education experience and the ASK app. For one thing, the person answering a visitor’s question is not in direct view. So while a gallery lecturer thumbing through notes might be a bit distracting, our audience engagement team members will be free to look things up. In addition, the medium of text message has a built-in expectation of moderate response delay (asynchronous communication). Thus, our team members will have a few minutes to find the answer to an unfamiliar or tricky question. Knowing these basic challenges, benefits, and constraints, it was always clear to Shelley and Sara that in addition to the dashboard, which connects our audience engagement team to incoming visitor questions, they also needed a tool that would allow the team to access in-depth and reliable information about objects in the collection very quickly—they needed a wiki! My job, as Curatorial Liaison, is to help give this ASK wiki form in consultation with curators and Monica Marino, our Audience Engagement Team Lead.

A wiki will have a number of essential benefits for our team:

• Searchability: As a digital resource, a wiki is easily accessible and searchable. This is important because, when responding to questions on the dashboard, our team won’t have time to thumb through books or read entire essays to find the answers to object specific questions.
• Content integration: We are sourcing content from a variety of vetted sources—including collection and exhibition catalogues, museum education training materials, and scholarly articles—to create a single trusted reference tool.
• Multiple kinds of content:  We can gather and store comparative images, x-rays, videos and the like—dynamic content which we can then quickly and easily share with visitors via text as our conversations progress.
• Consistent organization of information: We are creating detailed object page templates with sections devoted to things like materials, iconography, cultural context, related historical events, style, artist information, and provenance. Thus, our team with know immediately where in a page to look for particular kinds of information.
• Multiple authors: The daunting task of creating and updating content (which we hope will eventually encompass every object on view) can be spread between the entire team. Monica and I will also maintain administrative roles, vetting content either by approving edits or reverting to previous versions of pages. Curatorial staff will also have administrative accounts so that they can easily review content in their collection areas.

In choosing a specific wiki platform, Monica and I quickly realized that our most important criteria was usability. On Thursday, February 5, we participated in our first round of user testing and the experience was eye-opening. Chief Curator Kevin Stayon, Monica, and I manning the dashboard while a few dozen visitors explored the American Identities galleries.The rate at which questions came in could be so high that responding to questions in anything resembling a timely manner was extremely challenging. This was especially the case with unfamiliar questions that required some “googling” and the inevitable selection of trustworthy sources. A clean, intuitive interface, free of any extraneous text, branding or links was thus absolutely key, as was a clear automatically generated table of contents. We also knew we needed the ability to easily embed, reposition, and caption images; to upload PDFs and other files; and to automatically insert content from other parts of the wiki so that oft-repeated information (like artist biographies or religious practices) only needed to be updated once.

A wiki will supplement the dashboard to help answer visitor questions. A clean, intuitive platform was needed that we can later fully integrate into the ASK dashboard.

We looked at and tested several different platforms that we found through an online tool called WikiMatrix. Our first selection was Wikispaces, a beautifully designed wiki hosting service largely geared for classroom and higher education use. When we brought our choice to the technology team, however, we learned that they had some additional criteria we hadn’t originally anticipated. Initially, we had all understood the wiki’s function as an internal reference tool for the audience engagement team and thus largely distinct from the dashboard. Yet the user testing that had lead Monica and I to focus more on usability had also sparked discussion about possible additional applications for the ASK wiki in the future. For example, wouldn’t it be great if, one day, the wiki could be linked to the dashboard directly? That is, if an object detail in the dashboard (whose information is imported directly from the collection online) could also automatically show existing ASK wiki content on that object, or even a link to it, that would be much faster than having to search for an object in the wiki by copying and pasting an object ID. This type of functionality would require a good API (application programming interface) in order to link the two pieces of software by tagging pages with object IDs. Wikispaces, we learned, does not have a comprehensive API for this purpose and that would limit what we could bring into the dashboard at a later date. So it was back to the virtual drawing board. After testing two more wiki platforms suggested by David Huerta, our Lead Developer, we settled on Confluence, a team collaboration software mainly used in corporate environments. As a comprehensive project management application designed for purposes rather different from ours, it has numerous features beyond our immediate needs. We will resist temptation and ignore (and, where possible, deactivate) these additional tools, using only their wiki functionality.

Digitizing object based information about the museum’s collection has a lot of potential for future use across our institution. Our current objective is thus to keep the wiki-building process simple by using an existing wiki platform but also flexible by meeting certain technical requirements that will ensure integration at a later date.