Author Archives: Seb Chan

About Seb Chan

Seb Chan was the inaugural Director of Digital & Emerging Media (2011-2015) and the founder of the Labs. He likes imaginary creatures and overly sweet beverages. You may already have met him and you can find him on the other side of the world at Fresh & New.

Designing the responsive footer

Leave a reply

We now have a responsive main website. To a degree.

Like everything it is a stopgap measure before we do a full overhaul of the Cooper-Hewitt online – timed to go live before we reopen our main campus (2014).

With the proportion of mobile traffic to our web properties increasing every month we couldn’t wait for a full redesign to implement a mobile-friendly version of the site. So we did some tweaking and with the help of Orion, pulled responsiveness into the scope for a migration of backends from Drupal 6 to Drupal 7.

Katie did the wireframing and design of the new funky fat footer – which you’ll notice, changes arrangements as it switches between enormous (desktop), large (tablet) and mini (mobile) modes.

Here she is explaining the what and why.

Why did you do paper prototypes for the responsive design?

A few months ago I was working on a design for the Arts Achieve website. I showed my screen to Bill, our museum director, to get his thoughts. Bill is a former industrial designer and one of the pioneers of interaction design. The first thing he said was “ok, let’s print out a screenshot.” He then drew his suggestions right onto the printed page. We didn’t really look at the screen much during the conversation. Writing directly onto the paper was more immediate and direct, and made his suggestions feel very possible to me. Looking at a site design on a screen makes me feel like I’m looking at something final, even if its just a mockup. The same thing printed on paper seems more malleable. It’s a mind trick!

Paper also lets me print out many versions and compare them side-by-side (you can’t do that on a single monitor).

Paper also ALSO lets me walk around showing my print-outs to others and ask for rapid reactions without pulling everyone into a screen hover session. This is a simple body/communication thing: when everyone is facing toward a screen to talk about a design, you’re not in a natural conversational position. Everyone’s face and body is oriented toward the screen. I can’t see people’s faces and expressions unless I twist around. When you’re just holding a paper, and there’s no screen, it’s more like a natural conversation.

Post-its stuck to the monitor as a way to quickly agree on our initial ideas

Why do some of the elements move around in the responsive footer? (why do the icons and signups move)

They move around to be graphically pleasing. And to make sure the stuff we wanted people to notice and click on is most prominent.

We had a strong desire for the social media icons to be really prominent. So they’re front and center in the monitor-width design (940px width). They’re on the right hand side in the tablet-size design (700px wide) and in the mobile-size design (365px wide) because I think it looks sharpest when the rectilinear components are left-justified and the round stuff is on the right.

What were the challenges for the responsive design?

We had a really clear hierarchy in mind from the beginning (we knew what we really wanted people to notice and click) so that eliminated a lot of complexity. The only challenge was how to serve that hierarchy cleanly.

One challenge was the footer doesn’t always graphically harmonize with the body of the page, because the page content is always changing.

Another challenge was getting the latest tweet to be clear and legible, but still appear quiet and ambient and classy.

What were some of the things you are going to be looking out for as it the site goes live?

I want to see how the footer harmonizes with our varying page body content and then decide if it makes sense to change the footer to match the body, or re-style the body content to sit better atop the footer.

I wonder if people on Twitter will start saying stuff @Cooperhewitt just because they know they’ll get a few minutes of fame on our homepage. That participation could be awesome or spammy. We’ll see.

I’m really excited to see the analytics. I want to see if this new layout really does boost our newsletter signup and social media participation and everything. It will be super gratifying if it does.

Of course, we’ll reiterate and revise based on all the analytics and feedback.

Patrick Murray-John hacks our collection at #THATcamp

1 Reply

And following Mia’s residency in the Labs we were excited to find out collection data ended up being toyed with at THATCamp.

Patrick Murray-John wrote up his experience with our data, reflecting many of the same issues that Mia cam across.

He calls out our CC0 licensing –

If the data had been available via an API, that would have put a huge burden on my site. I could have grabbed the data for the ‘period’, but to make it useful in my recontextualization of the data, I would have had to grab ALL the data, then normalize it, then display it. And, if I didn’t have the rights to do what I needed, I would have had to do that ON EVERY PAGE DISPLAY. That is, without the licensed rights to manipulate and keep the data as I needed, the site would have churned to a halt.

Instead, I could operate on the data as I needed. Because in a sense I own it. It’s in the public domain, and I have a site that wants to work with it. That means that the data really matters to me, because it is part of my site. So I want to make it better for my own purposes. But, also, since it is in the public domain, any improvements I make for my own purpose can and should go back into the public domain. Hopefully, that will help others. It’s a wonderful, beautiful, feedback loop, no?

As a fork of CC-0 content from github, it sets off a wonderful network of ownership of data, where each node in the network can participate in the happy feedback.

Go read his full post.

Learning from data. Part 372

1 Reply

Here’s an interesting image which shows a heat map of the mouse clicks in the last week on a page element on the Graphic Design: Now In Production page.

We are using a tool called Reinvigorate to generate these. And the data to help us figure out whether certain UI elements are working or not – before we do a wholesale redesign and rebuild.

Surprisingly we’re seeing a lot of interaction with the image gallery slideshow – far more than what we are seeing on a much more prominent video element on the same page.

What can we learn from this?
What should we change as a result of this data?

If anything, we are rolling out more analytics tools across our digital projects to help us better understand the behaviour of visitors.

And as we redesign our physical museum spaces we are looking at a number of different tools to help us do this in ‘meatspace‘ as well.

Might our future galleries as be as reconfigurable as our digital projects? Could we begin to treat our galleries as having this down specific UI elements?

Building Design Week NYC with Ushahidi

3 Replies

Today we pushed an event aggregator site for Design Week NYC out into the world.

Pulled together quickly in response to community need, we used the open source Ushahidi platform, usually used for emergency situations. We jokingly talked about using it to ‘tackle a design emergency’.

Micah answered a couple of questions about the project.

Why Ushahidi? What was Cooper-Hewitt’s relationship with them, if any?

When our communications and marketing team approached us with this project, I immediately thought of Ushahidi. We had recently featured Ushahidi in our Design with the Other 90%: CITIES exhibition, and through this I had grown to know their platform. Although originally designed for use with emergency situations and election monitoring ( or Wall Street occupying ) I thought that it could easily be customized to make sense for a city-wide week of related events. it seemed a perfect fit.

Ushahidi is an open source platform that is very much in development. Were there any tensions between using it ‘out of the box’ and the desired functionality?

Yes, we had to customize it to suit our needs. The main issue was the nomenclature Ushahidi has baked in across the platform. For example, the term “reports” didn’t really fit the vision we had for our deployment, as we would be mainly listing “events.” However, it turned out that this was fairly easy to remedy as the dev team at Ushahidi has done a decent job in compartmentalizing these kinds of things in the source code. The platform is also theme based, much like WordPress, so we were able to customize the overall look and feel of the site to our liking.

Some other issues we have come across have to do with the basic workflow. In a typical Ushahidi deployment, people on the ground submit reports. Its pretty straight forward. For our site, it would make more sense to create a list of events on a running basis and then allow the use of SMS and email and twitter to essentially comment and “check in.” It’s really only a matter of associating these things with the right data model, but this is failry rigid at the moment within the Ushahidi platform.

What were some of the major technical difficulties in getting it up and running?

Ushahidi has a lot of moving parts. Getting a basic install up and running is pretty easy ( about as easy as installing WordPress ) but it took some time to figure out how to integrate the site with the wide variety of plugins and add ons that are required to make the site really work. Functionality like following a twitter hashtag, submitting events via email or text took a little effort to get working properly.

Can you imagine a less-emergency-oriented fork of Ushahidi for these sorts of event planner operations?

Yes! I think it would be great to either fork Ushahidi for sites like ours that are more event driven and less “reporting.” However, I also sort of wonder if the dev team at Ushahidi might consider redesigning the core to make some of this a little more flexible. I’d also love to see them help prepare open sourced iPhone code for a more custom app deployment. There was a great article about using Ushahidi to essentially “roll your own” foursquare. The platform supports the idea of checkins via the iPhone app, though this part of the project seems to be fairly beta at the moment.

Releasing the collection on GitHub

15 Replies

Late last week we released the Cooper-Hewitt’s collection metadata as a downloadable file. And in a first for the Smithsonian, we dedicated the release to the public domain, using Creative Commons Zero.

I’m often asked why releasing collection metadata is important. My teams did similar things at the Powerhouse Museum when I was there, and I still believe that this is the direction that museums and other collecting institutions need to go. With the growing Digital Humanities field, there is increasing value in scholars being able to ‘see’ a collection at a macro, zoomed out level – something which just isn’t possible with search interfaces. Likewise the release of such data under liberal licenses or to the public domain brings closer a future in which cross-institutional discovery is the norm.

Philosophically, too, the public release of collection metadata asserts, clearly, that such metadata is the raw material on which interpretation through exhibitions, catalogues, public programmes, and experiences are built. On its own, unrefined, it is of minimal ‘value’ except as a tool for discovery. It also helps remind us that collection metadata is not the collection itself.

Of course it is more complex than that.

There are plenty of reasons why museums are hesitant to release their metadata.

Collection metadata is often in a low quality state. Sometimes it is purposely unrefined, especially in art museums where historical circumstance and scholarly norms have meant that so called ‘tombstone data’ has sometimes been kept to a bare minimum so as to not ‘bring opinion’ to objects. Other times it has simply been kept at a minimum because of a lack of staff resources. Often, too, internal workflows still keep exhibition label and catalogue publishing separate from collection documentation meaning that obvious improvements such as the rendering of ‘label copy’ and catalogue narrative to object records is not automatic.

But I digress.

We released our metadata through GitHub, and that needs some additional explanation.

GitHub is a source repository of the kind traditionally used by coders. And, lacking a robust public endpoint of our own which could track changes and produce diff files as we uploaded new versions of the collection data, GitHub was the ideal candidate. Not only that, the type of ‘earlyvangelists’ we are targetting with the data release, hang out there in quantity.

The idea for using GitHub to host collection datasets had actually been bouncing around since April 2009. Aaron Straup-Cope and I were hanging out in-between sessions at Museums and the Web in Indianapolis talking about Solr, collection data, and APIs. Aaron suggested that GitHub would be the perfect place for museums to dump their collections – as giant text blobs – and certainly better than putting it on their own sites. Then 2010 happened and the early-mover museums all suddenly had built APIs for their collections. Making a text dump was suddenly off the agenda, but that idea of using GitHub still played on my mind.

Now, Cooper-Hewitt is not yet in a suitable position infrastructurally to develop an API for its collection. So when the time came to make release the dataset, that conversation from 2009 suddenly became a reality.

And, fittingly, Aaron has been the first to fork the collection – creating individual JSON for each object record.

Could GitHub become not just a source code repository but a repository for ‘cultural source code’?

(But read the data info first!)

Upending ticketing

7 Replies

One of the opportunities we have right now is to challenge the conventional wisdom that back-of-house systems need to always be ‘enterprise grade’. As we are currently in renovation mode and our exhibitions and programs are happening offsite and around the city, we have the chance to rethink and experiment with different systems to perform common functions such as ticketing. In so doing we are looking at the way different systems shape visitor/staff interactions and are also able to refocus by choosing systems on their user experience rather than their ‘backwards compatibility’.

A recent change we’ve made is to use EventBrite for ticketing, replacing a system that despite being tightly integrated with our donor management system placed an inscrutable purchasing interface between the customer and their desired tickets. It isn’t a permanent solution (what is these days?), but more the opening of a ‘possibility space’.

So how is it going?

Our ticket selling velocity has increased – events sell more quickly – and we’ve been able to integrate ticket selling directly into our email marketing, as well. When ticket price points have reached capacity we’ve used automatic waitlisting and we’ve even been able to collect donations as purchasers buy tickets, and we’ve also been able to issue refunds easily when required. Most importantly the customer experience of purchasing tickets has vastly improved.

Last night, we had our first trial of a medium size event check-in. Using the EventBrite iPhone Check-In App we were able to run a cashless door using staff members’ iPhones to check everyone in quickly. Checkins were done via ticket scans and where people had forgotten their printed ticket, by name. Each iPhone synced to the master list meaning that we could easily ‘add extra ticket staff’ to process more people if we had a logjam. This had a nice side effect of freeing up staff time to direct visitors to our roving iPads for quick signup to our mailing list on their way into the venue.

But the purpose of deploying lightweight technologies as a replacement for gargantuan enterprise systems is not just about improving visitor experience, or streamlining back-of-house operations – it is also about positioning us to reconceptualise the type of entry/ticketing experience we might want for our new building and galleries when they are completed.

If it is possible to do the entry experience to events in a seamless mannner with only mobile devices, can a museum jettison its ticket counter in a redesign? It also makes us ask ourselves to be specific about the other functions ticket counters might serve.

Introducing Cooper-Hewitt Labs

4 Replies

Welcome to Cooper-Hewitt Labs.

The Labs is a place where you can discover what is going on behind the scenes in digital & emerging media at the Cooper-Hewitt. Now you might well be asking why the Cooper-Hewitt needs another blog – we’ve got the popular design blog on our site already – so here’s why:

It is going to get noisy here. It might even get a bit messy. And that’s the point.

(There’s a reason we have a tanuki as an unofficial mascot for the Labs.)

There’s going to be a lot of technical posts in amongst others that teardown how experiments have performed. And some speculations, ideas, and things we’d like to do, too.

The Cooper-Hewitt is undergoing a transformation with a major rebuilding project. As a result digital content development, digital outreach, and the integration of digital into the fabric and visitor experience of the new building, are all top of mind for us here. This means that there is a lot of experimentation and rapid change, and in the spirit of the broader Smithsonian New Media & Web Strategy, we are going to be doing a lot of ‘thinking aloud’.

We’d love your feedback and input as we go.
Continue reading →