Monthly Archives: January 2015

A new feature you may never see – ticketing follow up emails

A few weeks ago we rolled out a small update to the ticketing website that sends a reminder email to anyone who has purchased tickets in advance.

This is sort of an experiment. but first, some background.

Recently I attended an event at another cultural institution ( which I won’t name ). A few days prior to the event I received a very up-selling reminder email, reminding me of membership discounts and other events I might like. The links within the email took me to the landing page for the event, and offered little actual information that I found useful unless I wanted to buy even more tickets, or combine my purchase with a book in the shop.

To make things worse, on the night of the event, and just as it was finishing up, I received a “follow up email” , which I found really annoying. It was literally timed to send exactly as the event was ending and while I was on my way out the door, as if to say, “wait, come back in and buy the book too!”

In fact, the subject line read “How did I enjoy [insert event title here]?” But, the email itself didn’t offer me a way to answer that question ( even if I wanted to ) and instead simply pointed me to the same landing page of the event I had just attended, along with links to their social media channels and other upcoming shows I might be interested in. The whole thing made me cringe a little as I pressed the delete button on my phone.

I thought to myself, “let’s not do that.”

I really just wanted to send a gentle reminder email, full of actually useful info to people who were planning to come visit the museum. I thought it would be nice if I had booked tickets in advance to get something like this the day before I was planning to visit. Something with a map and some info on how to get here, and potentially a little synopsis of what I might do once I arrived.

So, here was my thought process.

Like I said, it’s an experiment, and so I’m still just sort of beta-testing this feature, and trying to analyze how useful/annoying people find it. We already get so many emails, so I really wanted to make sure I wasn’t bombarding our visitors with additional garbage, or even worse, confusing them with unneeded information like what I’d recently experienced.

First of all, it would be all about timing. While talking out loud in the Labs about this one, Aaron’s comment was simply “time zones.” Computer’s have time zones ( all of ours are set to UTC ), people are in time zones. It was clearly something to consider.

Right now, we can only assume that you will be here sometime during our open hours on the day you purchased the ticket. We don’t presently do timed tickets, and unlike an event space, each day’s “performance” spans the entirety of our hours.

So we decided to try out sending the reminders the day before at 4pm, our time. I guess it’s generally safe to say that visitors are nearing our time zone the day before their visit, but its really still a best guess. Also, we are not going to “remind you” if you are booking for the same day as that’s probably overkill. So for now, at 4pm, the day before your visit, is when the email goes out.

Next I had some fun coming up with a way to extract all the relevant info from our Ticketing CRM ( Tessitura ).

I needed the following info:

  • All the things going on tomorrow ( this is sort of future proofing for when we let you book other things beyond general admission )
  • All the current orders for all the things going on tomorrow.
  • All the email addresses for all the orders for all the things going on tomorrow.

Getting “tomorrow” was pretty easy in PHP.

$datetime = new DateTime(‘tomorrow’);
$tomorrow = $datetime->format(‘Y-m-d’);

4pm EST is 9pm UTC on the same day, so all good there in calculating “tomorrow.”

Our Tessitura API wrapper I mentioned in my last post has a method that lets us get all the “performances” in Tessitura for a given date range. Simply passing it “tomorrow” yields us all the things we are looking for. We also have a method that can get all the orders placed for a given performance. Finally, we have a method that gets the email for the user that placed the order.

Now we can send the actual email.

Obviously, people place multiple orders and buy multiple tickets per order. I really only want to send one email regardless of what you’ve booked. So when I am looping through all the orders, I only add the email address to the list once.

The last step was to make a cron job that runs this script once a day at 4pm. Done!

( Incidentally, all of our servers are set to UTC, but for some reason our RedHat server’s crontab doesn’t seem to care, and somehow ( possibly magically ) thinks it’s on EST. I have yet to figure out why this is, but for now I am just going with it. )

Right now, the email is a fixed template. We are sending out emails via Mandrill, so we get some decent analytics and can track open rates, and click rates. We also added Google Analytics tracking codes to all the links in the email so we can see what people are clicking right in GA.

So far we’ve experienced an open rate of about 75% and a click rate of about 20%, which seems pretty good to me.

Our open and click rate for the last 30 days.

Our open and click rate for the last 30 days.

And here is the GA results for the “Ticket Reminder” campaign from the same time period. From here you can dive deeper into the analytics to see what pages people are heading to once they are on the site, and all sorts of other metrics.

GA TicketReminder

Since you can only really “see” this feature if you book an advance ticket I’ve posted an image of what the email looks like below. We went through a few design iterations to get it to look the way it looks, and I’d really love to hear your thoughts about it. If you were visiting us, and received this email the day before your visit at 4pm, would you find it useful, annoying, or confusing?

Reminder Email Template

Our reminder email template

Of course this will change again when the Pen goes live shortly.

Labs turns three!

Candles atop a blackberry and giner donut

Happy birthday Cooper Hewitt Labs.

Today Cooper Hewitt Labs turned three.

Back in January 2012 this blog was just an experiment, a flag planted in rough terrain, but now what is actually the ‘Digital & Emerging Media’ team, is better known out there in the world as Cooper Hewitt Labs. In fact there’s a recent #longread in The Atlantic that focuses specifically on the Labs’ work.

It is funny how naming something brings it into the world, but its true. It is also true that what the Labs is is fragile. It is a group of people who happen to work well with each other, and the people around them, to make something much greater than what could be achieved individually.

For the first year the mascot of the Labs was the mischievous Japanese spirit (or yokai) called the Tanuki, and the second was the equally naughty “Cat (and Kitten) in the act of spanking“, the new mascot that watches over the Labs is the memetic and regal, Design Eagle.

Happy birthday to us.

If you’d like the last three years of blog posts wrapped up in easy to carry PDF format (or because ‘blogs don’t last forever’), here they are – 2012 (37mb) | 2013 (34mb) | 2014 (25mb).

How re-opening the museum enhanced our online collection: new views, new API methods

At the backend of our museum’s new interactive experiences lies our API, which is responsible for providing the frontend with all the data necessary to flesh out the experience. From everyday information like an object’s title to more novel features such as tags, videos and people relationships, the API gathers and organizes everything that you see on our digital tables before it gets displayed.

In order to meet the needs of the experiences designed for us by Local Projects on our interactive tables, we added a lot of new data to the API. Some of it was sitting there and we just had to go find it, other aspects we had to generate anew.

Either way, this marks a huge step towards a more complete and meaningful representation of our collection on the internet.

Today, we’re happy to announce that all of this newly-gathered data is live on our website and is also publicly available over the API (head to the API methods documentation to see more about that if you’re interested in playing with it programmatically).


For the Hewitt Sisters Collect exhibition, Local Projects designed a front-end experience for the multitouch tables that highlights the early donors to the museum’s collection and how they were connected to each other. Our in-house “TMS liaison”, Sara Rubinow, worked to gather and structure this information before adding it to TMS, our collection management system, as “constituent associations”. From there I extracted the structured data to add to our website.

We created a the following new views on the web frontend to house this data:

We also added a few new biography-related fields: portraits or photographs of Hewitt Sisters people and two new biographies, one 75 words and the other 50 characters. These changes are viewable on applicable people pages (e.g. Eleanor Garnier Hewitt) and the search results page.

The overall effect of this is to make more use of this ‘people-related’ data, and to encourage the further expansion of it over time. We can already imagine a future where other interfaces examining and revealing the network of relationships behind the people in our collection are easily explored.

Object Locations and Things On Display

Some of the more difficult tasks in updating our backend to meet the new requirements related to dealing with objects no longer being static – but moving on and off display. As far as the website was concerned, it was a luxury in our three years of renovation that objects weren’t moving around a whole lot because it meant we didn’t have to prioritize the writing of code to handle their movement.

But now that we are open we need to better distinguish those objects in storage from those that are on display. More importantly, if it is on display, we also need to say which exhibition, and which room it is on display.

Object locations have a lot of moving parts in TMS, and I won’t get into the specifics here. In brief, object movements from location to location are stored chronologically in a database. The “movement” is its own row that references where it moved and why it moved there. By appropriately querying this history we can say what objects have ever been in the galleries (like all museums there are a large portion of objects that have never been part of an exhibition) and what objects are there right now.

We created the following views to house this information:


The additions we’ve made to exhibitions are:

There is still some work to be done with exhibitions. This includes figuring out a way to handle object rotations (the process of swapping out some objects mid-exhibition) and outgoing loans (the process of lending objects to other institutions for their exhibitions). We’re expecting that objects on loan should say where they are, and in which external exhibition they are part of — creating a valuable public ‘trail’ of where an object has traveled over its life.


Over the summer, we began an ongoing effort to ‘tag’ all the objects that would appear on the multitouch tables. This includes everything on display, plus about 3,000 objects related to those. The express purpose for tags was to provide a simple, curated browsing experience on the interactive tables – loosely based around themes ‘user’ and ‘motif’. Importantly these are not unstructured, and Sara Rubinow did a great job normalizing them where possible, but there haven’t been enough exhibitions, yet, to release a public thesaurus of tags.

We also added tags to the physical object labels to help visitors draw their own connections between our objects as they scan the exhibitions.

On the website, we’ve added tags in a few places:

That’s it for now – happy exploring! I’ll follow up with more new features once we’re able to make the associated data public.

Until then, our complete list of API methods is available here.