*Author’s note: I’ve been sitting on a half-finished draft of this for too long, and while I know this is a bit of an odd time to share, I have very little else to do. I hope that these kinds of online museum resources can be a positive outlet for boredom and inspiration in the weeks and months ahead.*

Last year we replaced our separate online collection site with a new experience integrated within whitney.org. We made this shift for a number of reasons, but the biggest was that this allowed us to take full control over the UI/UX, and start building out an experience that allowed for more kinds of exploration. What users saw when they came to the online collection changed greatly, but the underlying data and the software delivering it to whitney.org stayed the same. For that reason, that initial work was always going to be part one of an (at least) two part project; we had to tackle the systems that delivered the data as well.

The challenge of magic middleware

To launch the initial version of the full online collection when the new building opened (2015), we worked with an outside agency to build a set of internal tools that would pull data out of our database of record (TMS, or “The Museum System”), an API that would ingest that data, and a public-facing website that would present that data for easy access. When we relaunched the collection last year, we replaced the final stop of that system (the public-facing website), but we left alone the tools and API. The former continued to pull data out of TMS, and the latter simply switched to feeding the new collection experience on whitney.org rather than the old. We’ve since replaced both.

The challenge with our middleware wasn’t that it was buggy or lacking in performance; on the contrary, it did what we needed it to and served us well for 5 years despite being built and launched in an extremely tight timeline. But as the Museum has grown, so too has our expectations of the online collection. We needed a system that could expand with us, while staying supportable.

Moving to more durable infrastructure

One of the challenges of being part of a small dev team at a non-profit cultural organization is making sure we’re not biting off more than we can chew, because we don’t have much capacity for something to go wrong. Supporting a smaller number of apps and stacks is one way to make things more sustainable, and in this case we had an option built and supported by the same company that makes TMS: eMuseum.

eMuseum and its associated parts plugs directly into TMS, and outputs collection data to an intended-to-be-public website, alongside an (optional) API. As I’ve written about before, we want the online collection to be deeply connected to the rest of the whitney.org experience. We’ve done this through importing collection data directly into our primary content management system (CMS), from our previous API. With eMuseum offering a robust and flexible API, supported by a vendor that we are already committed to working with, it seemed a good fit…and a lot less daunting than writing our own solution from scratch.

What eMuseum offers us are small but meaningful improvements over our existing API, and a much larger increase in peace of mind over being able to maintain the software, and make adjustments to how it works. It also slotted into our existing cms-to-collection-syncs without a huge amount of work, given the work we had already done.

What else is new?

Despite being an infrastructure-focused project, our move to a new API ended up coming with a number of noticeable improvements to the online collection…on top of changes we’ve already been making quietly over the last year. Some of those improvements:

1. Larger images

Now that we’re able to make meaningful changes to our collection middleware, we’ve updated all of our various image sizes to be substantially larger (currently up to 2048×2048)…based on more modern interpretations of fair-use, and updated licensing agreements.

2. Temporary images

Previously, for images to be pulled into the online collection they had to be present in a specific folder structure that corresponded to our collection documentation initiative. That did not allow for temporary images, supplied by the artist, gallery, or ourselves, to be used since they wouldn’t be stored in those set folders. With that limitation removed, we are able to start posting images of objects sooner after they’re acquired and before they are fully documented.

3. Linkable portfolios

Previously, the most we would do for objects in a portfolio or series would be to add a label like “1 of 5 in Portfolio Name”, with no way to link to either a view of that portfolio, or even show what the other objects were. With our more feature-rich API in place, we are now able to link to a new view within the online collection that will show all objects in a given portfolio, from each object page.

4. Simpler workflows

On the administration side, previously what objects would show up in the online collection was based on a variety of settings and TMS “object packages” that made it difficult to quickly diagnose why a particular image or object might not be visible online. With our ability to now configure the API more deeply, we’ve altered our import rules to be based on simple “Public Access” checkboxes in TMS, so it is much more transparent what will appear online.

What’s next?

With both the frontend and backend of the online collection now relaunched, one of the biggest items on our whitney.org wishlist is now complete, roughly 3 years after we launched our new CMS. Going forward, we are in a better position to iterate on the online collection, rather than fully rebuilding major pieces of it. We should be able to push forward new public-facing experiences, whether that’s open access (*crosses fingers*), new kinds of interpretive resources, or something else entirely.

👉 whitney.org/collection

[Read this on Medium]

I can’t tell if you QR codes are dead, undead, or if they never died in the first place, but I can tell you we’ve been trialing them at the Whitney Museum of American Art over the last year. Anecdotally, everybody familiar with what QR codes are seems to have an anecdote about them, but we wanted to determine more systematically whether or not they might be a useful tool for driving visitors into digital content while at the Museum, with any meaningful levels of utilization. And as it turns out, for us, QR codes are alive and well.

Connecting to the Mobile Guide

With our recently launched Mobile Guide one of our goals has been to get more people engaging with the experience on their own devices. To achieve that goal, we have to get visitors to open up a URL on their phone. That may sound small, but even little barriers can seriously affect take-up rates, as evidenced by the increasingly widespread death of the museum app (see: The Met, Tate, Guggenheim, etc.), in no small part due to the need to download what will for most visitors be a one-off experience. And while we can shorten the URL to something generally easy to read and type (whitney.org/guide), not all visitors are adept screen-typers, and this might be just enough to put them off if they didn’t already consider themselves “audio guide people”. Enter QR codes.

iOS 11 and a better QR experience

Historically, one of the biggest annoyances of QR codes has been the need to download an app just to read the codes, which could then open other apps or websites. Many Android phones have built in readers, but with our visitors skewing heavily towards the iPhone and the difficulties of messaging around different models of devices, that wasn’t particularly useful for us. With the release of iOS 11 in 2017 however, iPhones gained native QR scanning abilities in the camera app, opening up the viability of QR as a part of our digital strategy.

The benefit to being built-in to the native camera meant that nearly all of our visitors with smartphones would have a device that could seamlessly scan and open a URL to our Mobile Guide experience, without having to type anything in. For less tech-savvy visitors in particular, this is extremely useful, because even if they don’t know they have a reader in their camera, staff can reliably direct them to it faster than they can type in a URL, which can be subject to typos or other mistakes.

Starting the trial

Knowing that a significant portion of the museum’s visitors would at least technically be able to scan QR codes, we started placing the codes in a number of places throughout the building. Every QR code we placed led into our Mobile Guide, but the URLs were built slightly differently in each case so we could track a) the number of total QR scans and b) know which placements were the most effective. We did this by adding a unique query parameter to each QR code URL that would be picked up by our Google Analytics after the code was accessed.

Gradually we rolled out QR codes in a number of locations across the museum. Those locations and their numbers of respective scans between Nov 2018 and May 2019 are listed below.

Tickets
4,169 scans

Museum guides
4,110 scans

Lobby stanchions
2,289 scans

Elevator wall labels
745 scans

Tour stanchions
562 scans

Contextualizing the results

In total, we saw a total of 11,875 sessions from QR code scans (based on unique pageviews) from Nov 2018 to May 2019. Those sessions were initiated by approximately 7,100 users, out of a total Mobile Guide user base of nearly 34,000. And while the ratio of QR-begun sessions to total usage has shifted as certain wall vinyls have changed and ticket stock has rotated, overall QR scanning has been responsible for a significant portion of the Mobile Guide pick-up since we began rolling it out. That more than 1/5 visitors access the guide through a QR code is huge, and at certain points during the Warhol run of show it was responsible for more than 1/4.

Where we go from here

When we began talking about alternative ways to get visitors into the Mobile Guide, one of the most interesting options was just out of reach—NFC tags, which could be placed on signs, walls, counters, and anywhere else. Unfortunately, while most Android phones allow for URLs to be opened from a tap on an NFC tag, iPhones (at the time) did not outside of native NFC-reading apps. However, with the iPhone XS and XR, it appears that this is changing, which should eventually open up this option as consumers gradually replace their older devices. The clear benefit of NFC over QR in this case, is that with NFC visitors would not need to open even their camera, and could instead simply tap their devices at the counter as they enter and be on their way.

In the mean time, we are continuing to place QR codes throughout the museum, and adjusting our standard ticket to permanently include a code on the reverse.

TL;DR: Apparently QR codes work, pass it along.

[Read this on Medium]

The Whitney’s collection defines and drives much of our mission and our work. It is a unique resource, offering a lens into the historical and contemporary landscape of American art through more than 3,400 artists and 23,000 works of art. With the opening of the Whitney’s new building in 2015, nearly every work in the Museum’s collection was made available online for the first time.

That the initial platform was developed and launched alongside a flurry of other initiatives reflects the challenges, scope, and successes of the release. And while the online collection has been something to celebrate, now coming on five years later we are ready to start making improvements.

Saying goodbye to collection.whitney.org

The core challenge of any museum’s online collection work is reflected in how many systems and limitations are in play, at all levels of any technical stack. When we first launched the complete online collection, Cogapp and Whitney staff worked together to build a solution that would push our data out of The Museum System (TMS), our database of record, and into forms usable publicly online. Previously the result of this effort lived at collection.whitney.org, which notably is separate from the primary hub of our content and information that lives at whitney.org. Having separate systems allowed for a simpler initial implementation of the collection, but as both the Museum and ambition has grown, so too has the need to bring these separate platforms together.

After the relaunch of whitney.org gradually (and also quietly) in 2017, we began laying the groundwork for pulling the collection into our new custom in-house-built Content Management System (CMS), biting off bits and pieces as we have been able, to slowly build out a solution behind the scenes. By the end of 2018, the collection was fully imported and integrated into whitney.org, syncing on a regular basis, and had a barebones but functional (and non-public) user interface. In short, we had built the majority of a new collection in quiet, as a non-project.

The reasons why we did things this way are complicated, but the succinct version is that while the online collection is important to everyone it is also rarely a priority. So much of what the Museum does on a day to day basis is tied to exhibition programming, either for current shows or those on the horizon, that carving out time to look back or undertake the difficult infrastructural work inherit to collections can be extremely difficult. In this light, performing the bulk of this project over a long period of time without a hard deadline was one of the only ways we could be sure it would happen. As the Museum’s Digital Media department, it is our responsibility to undertake this kind of work because it ties so closely to our mission to enable greater access to the art and Artists we represent, for anyone and everyone we can.

So that said, why build a new collection at all? What does integrating it into our primary web CMS get us that the separate platform did not? There are three main reasons:

1. Global improvements elsewhere on whitney.org improve the collection

As we’ve improved elements of whitney.org like the site’s navigation, font sizes, spacing, accessible markup, and other global aspects, none of those changes have previously fed back into the online collection due to it living on a separate platform. By integrating the two frontends into the same custom Ruby on Rails CMS, work that we do elsewhere will not need to be duplicated on the collection, and the collection will benefit from nearly two years worth of continual improvements to the main site.

2. Deeper and easier relationships between artists, artworks, and related content

In addition to global improvements, we can leverage Rails’ built-in relationship concepts that we use all across whitney.org, to draw links between the collection records and videos, audio, exhibitions, events, products, Whitney Stories, essays, and other online content. And while the previous platform did a certain level of this (through non-trivial manual efforts), by keeping it all within the same ecosystem it becomes both more expansive and easier to manage.

3. Simplified development going forward

Having two entirely separate stacks to produce visually comparable frontends is complicated, and requires separate development environments and domain expertise. By bringing much of the system into our primary CMS, it will take less time going forward to iterate on new features, and more of our code can be reused.

Beyond those three main reasons, there were a whole host of smaller ones, from improved accessibility, to mobile performance, to fixes for bugs, to new search and sort options. All of which on their own constitute major improvements, and ones that would be recognized as such both by internal stakeholders and the public. It is in that vein that we decided to launch what we had, softly, while also using it as a chance to prime our thoughts for what we could really offer with our online collection in the future.

What we launched

The updated online collection encompasses two main strands: one, an artist-centric approach, and the other an artwork-centric one. This is reflective of our positioning as the “Artists’ Museum”, and also the more standard need to surface what works are in the collection. Both sections are deeply interlinked, and are best thought of as two twinned entry points into the Whitney’s collection, history, and mission.

whitney.org/collection/works

The bread and butter of any online collection is of course the art. Our updated whitney.org/collection/works page is the new hub for exploring what artworks are in the Whitney’s collection.

The biggest change from the old collection.whitney.org is that now all sorts and filters are featured on one page instead of being separated across many, and they can be combined and toggled on or off in concert with one another. Which means no more navigating distinctly between what’s “on view” and “works with audio or video”, or being unable to search within the selection of works that have complete object labels, or are on view, or any other qualification— all fields and properties can be leveraged as needed, from one page, with no limit or restrictions on how many can be active at once.

We’ve also taken the opportunity to start fixing certain features that over time drifted into non-functional states on the previous site, while also adding new ones including the ability to view only works that have images (a critical distinction for many users), and to filter by classification or medium. Most of these features take the form of extra fields (revealed by clicking “advanced search”), rather than a single integrated search box, which is something we will be closely monitoring and user testing.

One of the primary goals was to launch with as many search and sort options as possible so that we could see how each feature gets used in practice. Rather than launch a minimal viable product (MVP) we wanted to launch something closer to a maximum to give us the broadest possible scope of data on real usage. Once the trends start to become clear, we can then begin to pare back and invest development resources as the true needs continue to surface.

whitney.org/artists

The second of the two sections, whitney.org/artists, did not have a clear equivalent on the old collection.whitney.org, which was limited to showing lists of artists by the first letter of their last name. With all the artist data pulled into our primary CMS, we for the first time had the ability to reorganize and reframe this section into something more respectful of how we think about the Artists in our collection.

Similar to the more standard collection works view, we’ve also added new features here while fixing the intention behind some old ones: artists can be filtered by those that have works on view in current exhibitions, or by those that have audio or video content. Both are options that were not possible on the previous site, and in the case of the latter is a particularly large improvement — we generate a substantial amount of video content around particular artists that might not include any works in our collection, so under a system that only surfaces video if it’s tied to a specific work, much of our video would remain buried. By allowing for more content to be associated and discovered at the artist level, we are aligning better with our overall content strategy.

What comes next?

This is just the first initial step in bringing the collection closer to the rest of what we do online. With our new hubs for collection artists and artworks we can begin to analyze our data, user test with our colleagues and our visitors, and push forward in building an online collection that better reflects the Museum’s mission, and supports the artists within it.

[Read this on Medium]

A lot has changed about whitney.org over the last year. This includes the entire platform underpinning the site, and a number of major usability and user interface improvements, from reworked navigation, to new mobile experiences for audio and video, to the incorporation of outside voices in our exhibition content. And with growing distance from the complexities of launching a new website, our data-related work has been picking up steam as we’ve been able to devote more time and mindshare to it, which in turn has begun to more deeply impact our design thinking and decision making processes. A major aspect of that impact is in an increasing ability to reevaluate our assumptions, and to better understand how visitors are actually interacting with us…rather than just how we might think they are.

In the beginning…

With whitney.org being rebuilt from the ground up, there was the opportunity (and requirement) to reconsider what data we ought to be collecting and analyzing through Google Analytics (GA) and similar tools. I joined the Whitney Digital Media team part way through this project, and so initially my primary goal was simply to get a handle on what was being tracked, and where we had major gaps.

Previously I had interned with the Museum of Modern Art on a data analytics and ingestion project and I hoped to build on that effort at the Whitney. Google Analytics can give you a lot just from incorporating the tag on your website, but to really understand our audience we needed to make sure we were also tracking important interactions, like use of our navigation, audio and video plays, and various call-to-action (CTA) clicks that wouldn’t necessarily be visible in the default pool of data. Without that tracking, we wouldn’t have a baseline to compare to when we were ready to start considering more major design and structural changes. Looking forward meant getting our house in order, today.

In addition to putting together the pieces for an interaction-baseline in Google Analytics, I was also interested in reviewing how accurate our GA-reported ecommerce numbers were compared to the organization’s internal accounting. This necessitated reaching out to colleagues in other departments. And while those conversations were brief, they have been incredibly important in framing our work. Seeing how our numbers compare to their numbers gives context to the fuzzy reporting of Google Analytics, and helps us to know what of level of confidence to ascribe to our figures…which is vital to separating the signal from the noise.

From passive data to A/B testing

The next stage in the Whitney’s digital data lifecycle has been to start investigating why our numbers are what they are. It’s one thing to know that we got 100 clicks on a button last week, it’s another to tease apart why it was 100 and not 50, or 200, or 10,000. To that end, we’ve begun to evaluate more and more of our core digital content through A/B testing. Altering certain elements of pages and considering those changes in relation to basic metrics like session duration, pageviews, and ecommerce transactions has been hugely helpful in terms of figuring out what aspects of our design and layout are effective at achieving their intended purpose. It has also been a gradual process, characterized by a growing willingness to experiment.

We began by making small changes to individual elements using Google Optimize: experimenting with the color of a few CTA elements, shifting the placement of a few links (and adding others), all in the hope of driving more conversions. As we became more familiar with the process of building and running tests, we started experimenting with larger aspects of the site, including a wholesale replacement of the footer, and a number of tests designed to start teasing out the effects of utilizing different kinds of content to promote exhibitions (or broadly, the institution) on our homepage. In the case of the latter, we’ve varyingly given users videos of artworks, images of artworks, experiential videos of exhibition installations, and images of people in those exhibitions.

The question of what content works is incredibly important to us as the museum’s Digital Media department. It’s our job to determine how to best reach new and returning audiences, and a major driver of our ability to do that is the media we choose to forefront. A/B testing is one more tool we can use to help make those decisions.

The conventional web wisdom tends to be that video will result in higher user engagement than still images. Video is also inherently more expensive than images, so the choice to go with one over the other doesn’t come without a few tradeoffs. In the effort to set a baseline for our both our data and any data-driven strategy, we wanted to test the conventional wisdom against our specific circumstances as a mission-driven arts institution. Given the added cost, we wanted to be sure that we understood the implications of each approach, and the metrics they affect.

And while it’s still too early to say what the definitive value difference may or may not be for us, the initial results have been interesting, and continue to warrant further investigation, and suggest new avenues to explore for homepage content.

Incorporating user feedback

Closely connected with our push into A/B testing, we’ve been working to get more qualitative feedback on various aspects of our platforms. This has included both quick in-person terminology surveys, and an incredibly rigorous two-part in-depth usability study of whitney.org run by an outside consulting firm. Both kinds of testing have been extremely useful, while also demonstrating why it can be worth it ($$$) to work with experts in the field. In-house user testing has made a lot of sense for us as small and focused endeavors, while the external usability study brought a level of expertise and specialized tooling we would never otherwise have had access to. There’s much more to say on both, but that deserves its own post.

It’s worth mentioning that all of our user testing efforts at some level remind us of what we aren’t doing as well as we’d like. And while it would be easy to discouraged by that, I think it’s important not to be. There is no end state in usability work. There is no point at which everyone will convert, everyone will understand our UI, and everyone will have a positive experience the first time, and every time after. Rather our goal is the constant evolution of our products, reflecting the changing needs and expectations of our audience.

T H E F U T U R E, and moving to product development in tandem with evaluation

So what comes next for our data efforts? Likely, it’s wrapping together all the helpful experiences we’ve had over the last year into a more consistent, repeatable process. In effect, moving to something akin to user–test driven development, where new features are planned alongside user-focused evaluatory measures. Whether that means A/B testing aspects of design or functionality, or small scale in-house user surveys, or even larger external evaluation, our actions should depend on the nature of the feature and be determined in advance, rather than only as a post-launch reactionary measure.

TL;DR

1. Just because we measured something doesn’t mean we measured what we thought we did.
2. User testing is useful in all kinds of forms.
3. User-test driven development is good development.

[Read this on Medium]

An up to date count of the number of works by Edward Hopper currently on display at the Whitney Museum of American Art.

An animated mapping exploration of the Washington Post’s fatal police shooting dataset. Locations are geocoded through the Google Maps API, and build up a familiar image of the United States.