At the Natural History Museum, we’re looking for opportunities to increase the richness of the user experience of our website. So when the Museum of the Moon exhibition was in planning earlier this year, we had the opportunity to improve its exhibition page.
In this post, I’d like to take you through the Digital Team’s approach to creating and testing the new look page, and users’ responses to it.
Requirements
We started with a hypothesis:
Could the exhibition page feel more like the exhibit itself, to invoke a positive emotional response and encourage people to explore more of the content on the page?
The exhibit features a bright moon in a darkened space, but our web pages are usually very bright and airy. Perhaps by inverting our regular page colours, we could create the right mood for the page?
We decided to find out.
Approach
Our content management system uses components that content editors use to build all the pages on the site. For example, an exhibition page might use a Hero Image component, along with a variety of Text blocks, Calls to Action, other Images and a Related Articles component.
As we know what components are already used on an exhibition page, our designer Florence Okoye was able to quickly create a new design variation. The design used an inverted colour scheme: it was dark and atmospheric and really made the content stand out.
Approach 1: Use a single CSS file
With the design agreed, new CSS would be required to update the live page. CSS provides an easy way to override existing styles, but there are many different ways to implement it.
For our first attempt, we used a simple approach: identify all the CSS rules used on the existing page and write new CSS to override them. These override rules go in a single CSS file, which is loaded after the master stylesheet. Due to CSS specificity and the CSS cascade, our new dark styles will override the original light styles and the look of the page is updated.
For example, here’s a simple CSS rule for an existing component, our global header, served in our master file called main.css:
.global-header {
background: white;
border-bottom: 1px solid lightgrey;
}
If we want to override this, we can serve a second file in addition to main.css. Where the rules are the same, the later styles will override the earlier styles. In this case, our second file is named dark.css and contains this rule:
.global-header {
background: black;
border-bottom: 1px solid darkgrey;
}
Without a theme specified, the CSS links in our page look like this:
< link rel="stylesheet" href="/css/main.css" >
But if the content editor has selected a theme, the CSS links in our page now look like this:
< link rel="stylesheet" href="/css/main.css" > < link rel="stylesheet" href="/css/themes/dark.css" >
The great benefit of this approach is that there’s very little back-end engineering to make it work:
- Add the ability for content editors to select a theme for an exhibition page.
- Add logic in the global header of our document to check if a theme is specified, and if so, add the to the required stylesheet.
We tested this approach and it worked perfectly. However, we quickly realised that while it was effective, it was quite limited. The biggest drawback was that there was no way of styling individual components on a case by case basis. For example, what if we only wanted some of our components to take on the new theme, but others to retain their original styling?
Approach 2: Use component based CSS files
We decided to try an approach that would allow us to style the components separately from the page itself. For this we’d need one stylesheet for the page (background, foreground, header, footer etc.) and then individual stylesheets for each component.
Our CMS is Adobe Experience Manager, which has a method for styling components in this way: Client Side Libraries. These clientlibs allow developers to write smaller chunks of CSS (and JavaScript), and only deploy them when the page includes a component that needs those resources. Compared to the simple structure in our first attempt, the folder structure for our CSS ends up more complex:
For this to work, content editors would need the ability to select the theme applied to any component. Fortunately, we already had this functionality available, as some of our components were already “themeable” depending on where we use them in the site. We extended this functionality to allow content editors to select the new dark style for any component (although this added to the development time.)
Once a page is constructed, AEM inspects all the components. If a component has a custom style applied, AEM links to the required clientlibs (CSS or JS) using standard elements. AEM is also smart enough to load a clientlib only once, regardless of how many times the same component is used.
We implemented this approach and tested it, but concluded it was too complex for a number of reasons:
- It added too much complexity to the content editor’s workflow
- Loading multiple CSS files in the body of the document degrades performance (this is mitigated in HTTP/2 but we’re not using that yet.)
Which approach to use?
In the end, we chose Approach #1: Use a single CSS file to override everything on the page. The reality was that the Museum of the Moon exhibition page didn’t need individual component styling: with our second approach, we’d tried to solve a problem we didn’t even have.
I was reminded of this article by web developer Rachel Andrew, Stop solving problems you don’t yet have. In this case, Rachel’s advice was sound. Despite the time we spent on the component based approach, we reverted to using the single override CSS file from our first attempt.
As developers, we have to be comfortable trying things out that may never be used. It can feel redundant, but it’s an essential aspect of finding the right solution.
Results
The existing Museum of the Moon exhibition page used our regular styling: black-text on a white background. After deploying the dark version on an alternate URL, we ran an A/B test to see if there were any differences in user engagement.
After two weeks of testing, the new dark page won out in quantitative testing with a 1.3% higher general conversion rate. Our goal was not to raise the conversion rate, but to make sure that the dark UI didn’t negatively impact the existing user behaviour. So the increase in conversions was a bonus!
In qualitative feedback, both pages were rated equally as ‘Informational’ but the dark page rated much higher than the original for ‘Mysterious’, ‘Intriguing’ and ‘Artistic’ qualities and considerably lower for ‘Dull’, ‘Basic’ and ‘Expected’. This was a great result, and supported our hypothesis that a more atmospheric page would invoke a different emotional response.
Once we had analysed these results, we disabled the original page and set the darker page as our new landing page for the Museum of the Moon exhibition.
Future
With this short project, we learned that it’s quite simple to add individual theming to any page on our website. This opens up lots of possibilities: we can now make any page match the theme and atmosphere of any exhibition. We’re excited to start using themed pages for future exhibitions, so watch this space!