Chris Unitt

Notes on what’s on listings for cultural organisations

NB: right now this post is a bunch of hastily thrown together notes. I’ll come back and add, edit, rearrange, and rephrase things later.

What’s On listings tends to live in four places:

These fit on a spectrum from…
You pick     —————— pick from a limited range —————— our selection
(what’s on) —————— (season grouping) —————— (homepage)

These notes focussed on the dedicated What’s On listings.

User behaviour on What’s On listings could be lumped into two types:

  1. Browsing (person isn’t sure what they’re looking for but is likely to have some criteria in mind)
  2. Searching (person knows exactly what they want and everything else is a distraction)

Users with different needs are going to have different requirements. They’ll want to find their way through event listings in different ways. Their mode might change from one to another.

There are various tools that can be used on a What’s On listing page to help a user find what they want:

Hackney Empire’s what’s on page features a list, calendar, filters, and a highlight block.

A person searching for a specific event may well just use the search bar, or pick something in the highlights block. Someone who’s just browsing may want the full list, or a broad filter.

Once they’ve narrowed a selection down to a list, how do they parse that? That’ll depend on how big the list is and what their next criteria is. This can be hard to judge but there are well-known trends. For instance, for classical music, repertoire is key.

Following from this, there’s an argument for adding ‘comparing’ as a third mode of behaviour. This often comes into play slightly later in the process, when a user has chosen a production / event and is looking for a particular performance. Have you ever clicked through multiple dates of a show looking for seats in the right area, or for the right price? That’s the sort of thing I mean.

Filters

Filters tend to relate to production-specific metadata:

Or more practical logistics:

Date could be considered a filter, but this is often handled via some sort of calendar.

Different organisations will need to handle these in different ways depending on the type of programme they offer, the ticketing system/CMS they have in place, and various other considerations (price and availability can often be tricky to handle for nobody’s particular fault).

Back-end

The back-end storing of events is in a pretty good place these days. There are good systems that can handle this. Where those back-end systems can fall down is in:

These problems tend to be worst for organisations that are using older websites or ticketing systems.

Front-end

Questions to ask:

The optimal layout for listings might depend on whether the user is in a browsing or searching mode. An image-heavy grid might work for flicking through lots of one-off events; a list might better suit someone who’s picking from a filtered selection.

Testing

When you’re doing user testing of What’s On listings you might consider testing:

You can also put constraints in the way of people – ie not allowed to use the search feature.

And don’t forget to test on several types of device. Filters tend to be designed really well on desktop, but less so on mobile because they take up quite a bit of space when open and are ignored when closed (this is a massive generalisation – good examples are out there).

Also, heatmaps are a shortcut to seeing:

A few cases studies

Tate puts all events behind filters, which assumes that nobody is going to be interested in everything and that it’d be best to get some of those preferences down early on.

Royal Albert Hall homepage and what’s on are interesting to contrast.

Royal Opera House again, compare homepage and what’s on.

Southbank Centre Lots of events and an example of the ‘tag everything and let people filter it’ approach.

London Symphony Orchestra a different set of considerations for a classical audience.

The V&A. An example of a complicated one, with a mixture of: