We began with a very short list of options in a drop down menu that included the special exhibitions, a few specific collection areas, and the collection more generally. We quickly found the need to add a few more options. For example, the admissions team asked for a “just in the neighborhood” option as it’s a common response to the question (though the data shows it’s not as common as they likely felt it was).

The survey appears in a pop-up window and has a drop-down menu of options. Unfortunately, the option to skip or cancel is baked-in; we can’t make this a required question to complete the transaction.

Results for the first two months are interesting. In July, the permanent collection ranked highest in response rate, while for August it was our Pierre Cardin special exhibition. The initial lack of options is one of the reasons for the high “other” response rate in July, which dipped the second month as more options were added. Currently, we have 16 options plus skip/decline. This feels like a lot, but maybe it’s ok. In particular, I wonder about including Korean art and African art in the list at the moment since both are temporarily off-view, but it would help us track an uptick once those collections are on view once more. We also have to remember to update the list regularly as special exhibitions open and close. For example, both Liz Johnson Artur and One: Egúngún exhibitions closed mid-August, which explains the dip in responses.

A quick comparison of the total number of survey responses (which should be every transaction) to total number of visitors who were required to visit the admissions desk shows the transaction count is about 60-65% of the visitor count. Multiple tickets can be purchased through a single transaction—and we know most of our visitors come in pairs or groups—and that feels close to the right percentage. I think we are still getting more cancellations than we should and we’ll keep working on it. The admissions team is meant to pose the question in a casual and conversational manner so it doesn’t feel like a survey (or an interrogation!) and select a response in order to proceed with the sale, although it is possible to cancel and move on. To avoid cancellation, we included a skip/decline option. Unfortunately, not everyone is consistently asking the survey question, which we know because we can run reports on who is logging which responses. For example, we found one person mostly just cancelled the survey in the first week and were able to speak with them. While we don’t want survey completion rate to become punitive, we do want to encourage completion because the information is important for us as an institution. Finding that balance can be tricky.

After two months, we are still working out the kinks, mostly in terms of making this process habit for the admissions team. A next step is to work with our Tech team to create a report that would knit together the survey answer, ticket info, and zip code from each transaction so we can compare the data set as a whole. That would be a pretty powerful triumvirate. 

When first hired for ASK, we made a best guess as to how many people we would need to staff the dashboard and settled on one full-time lead and six part-time team members. This solution gave us flexibility in scheduling so that at least a pair of team members were on the dashboard during all open hours, more for busier times like weekends. Early testing sessions indicated that one team member could handle anywhere from about seven chats at once, depending on how in-depth they were, and that number helped provide a baseline for staffing based on app traffic.

Our current ASK team (from L to R): Andy Hawkes, Elizabeth Treptow, Zinia Rahman, Stephanie Cunningham, Megan Mastrobattista. Stephanie and Megan have been on the team since the beginning. Andy, Elizabeth, and Zinia joined the team last fall. Andy is our first full-timer; we’re in the processing of hiring the second to complete our awesome team of six.

ASK team members are responsible for gaining broad knowledge of the entire collection and deep knowledge of a selected collection area, best practices for engagement via the app, and technical training on using the app’s backend.  A great deal of training is required to ensure that an ASK team member is ready to answer questions via the app. Over the course of the year, we’ve already seen some turnover in the positions, which is of real concern. We expected some regular turnover—after all, the positions are only part-time—but it happened more quickly than anticipated, and as those team members left, so did some institutional knowledge about ASK’s development process. We began to worry not only about staffing the dashboard, but about continuity.

We considered a few solutions to the attrition problem. One was a year-long graduate internship program, which would address the natural turnover head-on by building it into the job. Ideally this would include an intern per collection area for a total of 10 graduate students. While a program like this would provide a great opportunity for art history graduate students looking to work in the museum field, establishing, building, and managing such a program would be a great deal of work and so we decided against this approach for now. A second solution was to transition from six part-time team members to three full-time team members (plus the team lead). This was appealing for a few reasons: we could develop a more regular schedule for staffing the dashboard, more easily build in time for research since full-timers would be here at least one day a week that we’re closed to the public, and it would ameliorate the continuity problem. We considered this option for a long time, but eventually decided against it because there is a certain strength in numbers. We have six individuals with unique experiences and areas of study, and each one brings something important to the table. This variety of backgrounds and expertise leads to deeper self-reflection, better conversations as a team, and most importantly, better engagement with our visitors. Variety makes our team strong. We didn’t want to give that up, even in the name of continuity.

In the end, we came up with a compromise: two-full time team members and four-part timers (plus the team lead). We think this will provide a baseline of continuity moving forward, while still allowing for the richness of multiple viewpoints and voices. We’ll keep our scheduling flexibility, and the full-time team members will have time to take deeper dives into content and best practices, working with the rest of the team to develop these ideas.

All of that being said, we’re about to go into a very public launch with Marketing (with a capital M!) and more visitors able to engage with us via ASK once Android is on the floor. Happily this new team structure also provides flexibility to staff up by hiring additional part-timers, should app traffic demand it. In the meantime, we’re getting ready for launch and looking forward to many more chats with our visitors.

When thinking about Android expansion we had to re-evaluate how we were staffing mobile. In our first year it was invaluable to have someone on the internal team dedicated to iOS mobile development because the process at that time was more iterative. We were developing features and testing with users as we went along—having someone on staff to make changes as we discovered them was critical. Moving beyond that stage we had to reconsider the most efficient way of working and the best route forward would be to shift from staffing internally to hiring a firm. We contracted HappyFunCorp (HFC) to develop the ASK app for Android using our iOS app as a model. HFC is also handling our ongoing iOS maintenance allowing us to shift away from staffing internally in full.

The Android version of the app will function the same as iOS and in a future post I’ll talk about some of the changes that make ASK feel more appropriate for this platform and one of the bigger challenges we hit. Mostly, though, the transition to Android has been straightforward and, luckily for us, that meant we could concentrate on more vexing issues like how the app detects beacons and sends locations back to the ASK team. What follows is a lengthy post that details how our code works and the adjustments we’ve made. We are also taking this opportunity to release all of our code related to beacons in both iOS and Android regardless of the state it’s in—read on. 

In Android, permissions are granted in a one-step process at initial run. iOS, by contrast, stages permission actions as a user needs them. This delay in granting access to bluetooth may be causing “no location found” on start messages because we can’t range for beacons and build our array quickly enough.

So let’s take a look at the problem at hand. We’ve been seeing “no location found” on 15% of messages sent to the team with and high proportion of those on a user’s first message in a chat. We have a hunch this is likely because the beacon ranging starts too late. In iOS ranging only begins when a user turns bluetooth on and this prompt occurs very close to when a user would send that first message; turning on bluetooth is one of many things a user needs to enable and all of these prompts have been carefully staggered, so that users are not overwhelmed at the start. In Android, a user is asked for all permissions as a one step process up front and this means ranging for beacons starts right away. We think this change will help enormously, but we are still testing and this is to be determined. 

The other cause we’ve seen with “no location found” is attributed to the human error side of the equation. We have an admin tool that keeps track of our beacons and assigns them to museum locations. The beacon may be missing from that tool having been entered incorrectly (or not at all). To solve these issues the BKM web developer team enabled server-side logging; each time a beacon is sent to the dashboard that is not in the beacon database we’ve logged it in an admin tool so we can periodically use the data to chase down these problems.

Admin tool shows when we receive an invalid beacon ID likely the cause of a data entry error in our beacon tool.

The HFC team has also coded a debugger tool within the app which shows, in real time, all of the beacons in the application’s cache and the closest beacon the application would send with a message. This is helps us get visibility beyond the Estimote app because it shows what’s happening in our own application. Chris Wilson at HFC explains:

We now have a Chat/Beacon Log page that shows the list of messages sent since the list was reset. It has the beacons (with message optionally visible) showing the message timestamp, and the beacon’s major and minor ids. It uses live beacon data from the museum’s web api to determine if the beacons associated with these messages are valid, invalid, or if no beacon info was sent. The messages in the list are then color coded based on these designations. For easy visibility, messages with valid beacons are colored green, invalid designations are colored yellow, and messages sent with no beacon data are colored red. There are also total counts for each designation visible on the log screen.

Mobile side debugger tool developed by HFC to show beacons being ranged and which beacon would be sent with a message if a user were to hit send.

Our coding changes have not just been limited to the addition of debugging tools and as we discuss improvements it’s worth reviewing how the beacon code in our ASK app actually works. In a nut shell, as a user walks around the building the app ranges beacons as encountered by the device and builds an array with the associated beacon distance. When a user composes a message and hits send, we send the closest beacon to the user that is in the array. The following bulleted lists are coming direct from HFC:

Here’s the way the (newer) Android code works—

• On app start, the app begins ranging beacons using the Android Beacon Library.
• About every second the beacon ranging returns a list of beacons that have been seen.
• It cycles through each beacon and adds them to the cache, removing old copies of beacons that have been ranged with new distances.
• It removes beacons from the cache that have outlived the TTL (currently 2,500 ms – this is something we can try to tweak to improve accuracy).
• It then cycles through the list to determine which beacon is closest, replacing the closest beacon variable with this beacon. TTL on this is 3 minutes.
• The closest beacon variable is picked up and sent along to the chat server when the user hits the send button.

Here’s what we know about the way the (older) iOS code works—

• On app start, it the app starts the beacon ranging. However, the bluetooth check is only conducted when the user tries to send a message. Ranging requires bluetooth to be on, so this may be the source of “no location found” issues.
• When beacon ranging is run, an array of beacons, sorted by proximity is returned every second. If the proximity is unknown, the beacon is removed from the array. Only the first beacon (the one with closest proximity in the array) is used until the next ranging cycle. If the cache is empty, that beacon is added to the cache.
• If the cache is not empty, then the first beacon on this list (the one with closest proximity) is compared with the last beacon found with the last cache object. (1) If the major/minor ID of the beacon is the same AND the distance is less than the object, it adds the beacon to the list. If the major/minor ID of the beacon is the same and the distance is more, then it is not added to the cache. (2) If the major/minor ID of the beacon is different from the last object, it is added to the bottom of the cache.
• The last beacon in the cache array is grabbed along with the message when the user taps the “send” button in the chat message. If the beacon has been in the cache for more than 5 minutes, no beacon information will be sent.

So, what are the differences?

• Beacons aren’t removed from the cache in the iOS app, so duplicate beacons with different distances are added.
• Rather than comparing all new beacons found to all cache beacons and updating existing beacons and adding new ones as in the Android app, the iOS app compares only the last beacon found to see if it is closer than the last cache array beacon.
• There is a TTL of 5 minutes in the cache in the iOS app, whereas the TTL on beacons in the cache in the Android app is 2.5 seconds, and the TTL of the closest beacon if no new beacons have been ranged is 3 minutes.
• In the Android app, in addition to the short lived cache of beacons, there is also a closest beacon variable set in case there are no ranged beacons for a period of time. This beacons is then sent with messages if it has been more than 2.5 seconds but less than 3 minutes. In the iOS app there is no concept of a closest beacon variable.

We are now going to begin the process of testing Android with users to see if these changes have helped and, if so, we’ll start to port these lessons learned back into the iOS code after April. In the meantime, given how many people are working (and struggling) with beacon deploys, we’ve decided to release both sets of code in the state they are currently in along with the mobile side debugging tools. Having a fresh set of eyes from HFC looking at the code has help a bunch and we hope having many more eyes on this code will only help everyone.

Lastly, I’d be remiss if I didn’t take this opportunity to talk a bit about our funders as related to this post in particular. ASK Brooklyn Museum is supported by Bloomberg Philanthropies and one reason we are releasing this code today is the amount of encouragement and enthusiasm that has come from the Bloomberg team toward information sharing in all states of a project’s progress. This blog, our lessons, and our code are published in the largest part due to their support; we are honored to be as open as we are because of the standard they have set among their grantees.

The current ASK team (Stephanie Cunningham, Zinia Rahman, Elizabeth Treptow, Andy Hawkes, and Megan Mastrobattista) with a few friends.

The team’s primary task during the Museum’s open hours, of course, is conversation with Museum visitors via the ASK app. We usually have two team members “on the dashboard” on weekdays and three members present on weekends. Since the team is currently set up in a shared workspace behind the scenes, conversation about incoming “chats” and sharing of information is effective and easy. Sometimes the volume of chats requires total attention, and team members furiously type out their conversations with visitors while simultaneously conducting quick research with their reference materials (and each other!). At other points in the day, the pace slows down a bit.

Using the dashboard to have conversations with visitors.

Even though we’re involved in a technology-driven project, we’ve found that the most basic materials like a whiteboard, paper and markers, and a giant desk calendar help us to sort out our ever-evolving “to do” lists. We’ve broken our workload into daily, weekly, and monthly goals, and we have key reminders and new information prominently posted. When the team members have some downtime between chats, they’re able to tackle any number of “back-end” tasks that are necessary for ongoing learning and building of internal resources.

Sometimes the most low-tech office materials are the most helpful in determining our workload and needs.

The team’s day-to-day work could include any and all of the following:

• compiling useful information about new special exhibitions
• researching and writing “wikis” on works in the collection for our shared research database
• reviewing recent chats in order to evaluate successful engagement methods (more to follow about this in a future blog post!)
• processing completed chats into smaller “snippets,” archived by the accession number of the work discussed
• discussing recent trends in visitor questions and conversations
• attending a gallery tour led by a curator or a gallery guide

Tuesdays are reserved for team training and development, since this is the only day of the week that the full team is present in the Museum. We’ve been working with our colleagues around the building to schedule meetings that further our collective knowledge and keep us in touch with the Museum’s projects, events, and institutional goals.

Assistant Curator Rujeko Hockley meets with the ASK team to review their recent chats about Contemporary Art.

For example, Marina Kliger (our Curatorial Liaison for ASK) has coordinated sessions for curators to meet with the team. Each curator reviews the content of past chats on works in his or her collection area and offers specialized feedback. The curators have been remarkably generous with their time and their insights, and these meetings have strengthened the team’s connection to the collections.

Deirdre Lawrence, Principal Librarian at the Brooklyn Museum, shows us some archival materials.

We’ve also made some very rewarding visits to other departments of the Museum, including the Library and Archives, where we recently had the opportunity to view rare documents and publications from the Museum’s history. The team makes frequent trips to the Library for collection research, but this kind of special access adds an entirely new dimension to our understanding of the Museum and the ways its rich past still informs its present.

Last but certainly not least, we never want to forget our primary reason for doing what we do: using the app as a way to enhance the visitor’s direct encounter with unique works in the Museum’s galleries. Monica Marino, our former team lead (now School Programs Manager in the Museum’s Education Division) consistently emphasized the importance of “time with art,” and this is a priority that we’re maintaining in our schedule.

The ASK team makes an afternoon visit to “Coney Island.”

In order to refresh our eyes and minds on a regular basis, we’ve established several ways to get away from our keyboards and re-experience the galleries. Each team member self-schedules short visits to the permanent collections as part of his or her workday. Sometimes we spend time together in a special exhibition or a newly installed gallery of the permanent collection to share our thoughts and responses. And we also plan informal lunchtime presentations for team members to focus on particular works of art, and we invite our coworkers to join those discussions.

Thanks to the Museum’s full schedule of exhibitions and events, the depth of the permanent collection, and the iterative nature of the ASK project itself, there’s always a lot on the schedule for the ASK team. Much of our work will remain the same over the coming months, but other tasks may emerge or shift…stay tuned.

Download our ASK team training manual.

Over the course of a very exciting and whirlwind span of about eight months, our ASK team—at the time lead by Monica Marino—searched for answers to that very question. Through experimentation, conversation, a lot of trial-and-error with test groups, and continued examination now that the app is live, we have been able to codify this previously nebulous idea in the form of a training manual (authored by Monica) and through this process better define what ASK is all about. For example, we are able to define the main functions of ASK:

• A tool for engaging with Brooklyn Museum visitors: The primary purpose of the app is to engage visitors with the artwork that they encounter on their visit.
• An on-going experiment and driver of data: Because ASK is the first project of its kind it means that all who are involved will be part of shaping and defining what it is, and how it will be used.  Data collection and analysis is inherent in this process.
• A tool for collection research: Creating easily accessible research tools and resources are essential to the ASK project.

We have also determined four engagement goals for the app. We aim to hit at least two with every conversation, and if we hit all four, it feels like we won the lottery (hopefully visitors feel the same way and based on reviews, we think they do!):

• closer looking
  • Visitor notices details
  • Spends time looking at the object
• deeper exchange with the art object
  • Visitor leaves with information they did not have
  • Visitor makes their own interpretations about the object
• personal connection with the art object
  • Visitor connects with prior knowledge/memory
  • Visitor remembers the object (we can’t, of course, measure this! but we can hope for it…)
• making connections to other works in the collection
  • Visitor relates the object to another work in collection either on their own, or through our recommendation

Although we have these goals set down, we’re not content to just hum along. As our manual says, ASK is an on-going experiment and we’re always looking for ways to grow and improve. As part of this process, we’ve begun workshops with our Education staff in order to get feedback on ways to improve and ensure that ASK aligns with our overall engagements goals as a Museum.

As part of our first workshop, members of the education staff spent time in the galleries using the app.

The first workshop included having Education staff use the app in the galleries and also answer questions via the dashboard so that have they some context for providing feedback. Our next workshop will delve into the nitty-gritty of engagement, reviewing goals and best practices for engagement that may or may not translate from in-person gallery teaching to the app.

Equally important was time spent on the dashboard where members of the education staff answered questions coming in via the app with help from ASK team members.

As I hinted at at the beginning of this post, Monica is no longer our team lead (though we’re happy she’s still with BKM, just in a different role) and are delighted that Jessica Murphy, previous team member, has taken over that role. You’ll hear from Jessica in our next post about how the ASK team spends their time.

We thought people would have trouble with downloading and enabling the sheer number of settings our app requires, but turns out this part was easy.

People have needed that face-time, but not so much for help with the download process per se, but in order to actually explain the app and encourage people to download it in the first place. This was quite surprising to us, considering we require users to turn on multiple services for the app to function properly (wifi, location-aware, bluetooth, notifications, and privacy settings for the camera).

As I mentioned in my previous post, we’ve had some challenges figuring out messaging around ASK. After much initial testing, we think we’ve landed on some ways in which to move forward. This process was heavily informed by the work of our Visitor Liaison team. These three individuals, each of whom has worked with us in the past, were brought on board (in a part-time, temporary capacity) specifically to help us determine the how to talk about the app—the “pitch” in both long and short form—and where visitors are most receptive to hearing it.

Visitor Liaisons are identified by cycling caps, which so far has worked pretty well. We my find as the lobby gets busier, they may need to wear t-shirts or something even more visible in addition. From left to right: Emily, Kadeem, and Steve.

Steve Burges is a PhD student in Art History at Boston University and former curatorial intern in our Egyptian, Classical, and Ancient Near Eastern Arts department. Kadeem Lundy is a former floor staff member at the Intrepid Air Sea and Space Museum and was a teen apprentice here for three years. Emily Brillon was one of the gallery hosts for our first pilot test and has recently completed her Bachelor’s in Art History, Museum, and Curatorial Studies at Empire State College.

This team has been really key in helping us hone the messaging and in encouraging visitors to participate in ASK. From their efforts, we’ve learned what the key characteristics about the app experience that visitors respond to the most including that it’s a customized, personalized experience; that it’s about real people, or the idea of an expert on demand; and the immediacy, that it’s right away, or on-the-spot.

People are most receptive when they are in line.

We are also beginning to see patterns in where visitors are most receptive. We’ve been using the lines during busy weekends to our advantage, both for ticketing and the elevators—captive audiences help. But what has been most interesting to discover is that the Liaisons can most effectively get people downloading and using the app if they are the second point of contact.

At the ticketing desk visitors are asked if they are iphone users. If so, they get a special tag (right) which helps us differentiate them.

As Shelley introduced in her previous post, so far the most important point in our messaging is our ticketing process. A few weeks ago, our admissions staff began telling people about the app at the point of sale. The goal here is to identify iPhone users early (our potential audience) and to inform them about the app. iPhone users are given a branded tag so that Liaisons know who to approach. When this process is in play, the Liaisons’ job is that much easier because visitors know we have an app. Then the Liaison can focus on the hard part—explaining how it works.

When the team was first brought on board, we created an impromptu work space for them on our second floor mezzanine—a space that is adjacent to the construction area of the second floor galleries and currently off-limits to visitors. If you saw our LaToya Ruby Frazier or GO exhibitions, you’ve been in this space. A little sterile at first, they made it their own with posters, working note boards, and the like, jokingly referring to it as the “command center.” Generally, the space worked well and gave the team a place to gather and gave us a place to hold discussions after app testing sessions.

The ASK team fielding questions using our second floor mezzanine as a temporary office space.

As we approach soft launch of the app and the arrival of the new furniture, the team has relocated to a public area just inside the Great Hall on the first floor. This area is a main thoroughfare for most foot traffic (hence it’s internal nickname “42nd Street”), which admittedly makes it a challenging work environment, but that’s kind of the point. The team will eventually be in the lobby, which can be quite chaotic, so we wanted to give them a transition period in a busier space to start getting used to such distractions. Mainly though, we wanted to make the working process more visible and transparent in order to drum up excitement and anticipation on the part of our visitors. And we’re not the first ones to try this. Southbank Centre did this for their website redesign, though in an even more formal fashion. In true Brooklyn Museum fashion, ours is a little scrappier.

The ASK team has relocated to “42nd Street” to help acclimate them to working in a busy space before their lobby move in June.

Taking a cue from our colleagues across the pond, we are also advertising our testing sessions and visibly sharing feedback, though for us it’s in the form of sticky notes on the wall,on  which we invite testers to write down the one thing we should know from their testing experience. Now, I have a love/hate relationship with sticky notes, as I’ve shared before, but their appeal is undeniable. Testers jump at the opportunity to leave us their thoughts in this way, and the notes have been useful for the team to read as most of them are quite positive and a total morale booster.

What’s the one takeaway we should know from your experience using our ASK app?

It’s interesting to see how quickly this is working. Most visitors walking by automatically slow down a bit to figure out what’s going on and read our sign, even more so during really active periods when the team is answering incoming queries during testing sessions or using the conference table for feedback discussions. I hope this continues to drum up visitor interest and helps acclimate our team to working in a hectic environment.

Ed Bleiberg, curator of Egyptian Art, describing one of our signature objects, the Statuette of Queen Ankhnes-meyre II and her Son, Pepy II.

The tour was amazing. We had the opportunity to look closely with Ed at ten key objects on display. One of these objects was, “Statuette of Queen Ankhnes-meyre II and her Son, Pepy II.” He described the significance of the iconography and its influence in the history of art and later religious iconography. The six year-old King is seated on his mother’s lap, an iconography we can see in later works depicting the Virgin and Christ child in Christian objects. By looking closely with Ed, and having the opportunity to ask questions, we left with insight into the symbolic significance of the statue, its material and where it may have come from, an understanding of kings in ancient Egypt, and stylistic choices in ancient Egyptian art—for example, we asked about the elongated toes and fingers. The answer provided us with the skills to look more closely at other objects in the collection—great attention to detail was often employed when rendering hands and toes in Egyptian art, in some works you can even see the details of the figure’s cuticles; this same attention to detail was not placed, for example on the figure’s facial features. While this may seem like a minor detail, it really does change with way that you look at other objects on your own.

The Audience Engagement team working in the Egyptian galleries to write wiki content.

Following our talk with Ed, each team member chose one of the ten objects that Ed shared with us to research more in depth, and write object wikis. The wikis, as Marina mentioned in an earlier post, will provide the team with necessary information when they are engaging with the public through ASK. Over the course of training, and during ASK’s soft launch, the team will continue to write wikis for objects throughout the collection. To be sure that the wikis are resources that will provide the information that we need when manning the dashboard we also practiced using the wikis in an ASK practice session.

Alisa Besher using the app to ask questions during a team training session.

Practicing with ASK with the team in the galleries for the first time, did feel a lot like playing, in the best possible way. The feeling of excitement, nerves, fun, and fear that I had when I played capture-the-flag, and ghost-in-the-graveyard when I was a kid, were the same feeling that I and the team felt when we tried had our first ASK practice session. Two people from the team manned the dashboard and answered questions about the objects for which they prepared wikis, and the rest of the team went through the galleries and asked about those and related objects.

Megan Mastrobattista (left) and Katie Apsey (right) taking the controls of the dashboard during audience engagement team training sessions.

As was the case in a real testing environment, when manning the dashboard we felt the pressure of responding instantly and comprehensively, in an engaging and friendly way. It gave us a sense of the type of pressure that we’ll be under when ASK is live, but, the experience also gave us a glimpse of how much fun it will be. Because the team was being posed with inquiries about objects that they had just studied, they had information and ways in which to provide immediate responses, and different ways to engage those asking about the objects. Those answering questions found it exciting to have to think—at lightning speed—about the best way to share information; and those asking the questions were excited to get responses and gain new understanding.

This isn’t to say that everything was perfect. Each of us on the ASK team feel a deep sense of responsibility to the objects, the curators, and scholarship around the collections. There were plenty of inquiries that we didn’t have responses to, and even those that we did, in the back of our heads was the nagging thought voiced during the session, “Everything I write makes me nervous, there is no room to give wrong information, everything must be absolutely correct.” Fortunately, we are only into week one of training. Over the next two months the team will be working together with each other, and colleagues across the Museum to learn and study.  Including asking all the questions we have to be sure that we get it right.

I delineate here the type of information that the ASK team will have because it is this type of information that makes this app more than just a “human Google.”  Anyone can Google a question, and look up information—what ASK is allowing our visitor to do is to connect with a person who has a nuanced understanding of the works of art, AND an understanding of the different ways in which people interact with art.

As part of training, our Audience Engagement team is walking through the galleries with each collection curator. Here they are getting a tour through American Art with Terry Carbone.

With all of this in mind, how do these six individual humans engage museum visitors with 5,000 years of art? How can the team prepare to be at-the-ready to answer questions and engage in dialogue thoughtfully about any object in the collection at any given moment? It is a daunting task indeed!

To best address this challenge, we have decided that each individual team member will have a “major” and “minor” collection area of focus, and of course, each will have an understanding the many different ways in which museum goers engage with art.

Nancy Rosoff, Andrew W. Mellon Curator of the Arts of the Americas, works with the team to take a closer look at our Life-Death Figure.

To begin our work together we’ve started learning about the full collection in tandem with experimenting with the app. Although everyone will have two collection areas on which they are focusing, it is important that everyone has a broad understanding and familiarity with the full collection so that we can make connections across collection areas (and if we’re overloaded with a high volume of inquiries, we’ll be prepared to respond to some queries that are outside our focus areas). Over the course of training and our soft launch the full team will meet with all of the curators, write one comprehensive wiki for each collection area, write 7-9 object wikis in their respective “major” collection areas of focus, and practice manning ASK’s dashboard as much as possible.