How we ended up with two different headers
In 2017 we commissioned an external agency to build us a theme for blogs.bath.ac.uk, our WordPress multisite. The header was based on the look and feel of our site at that time:
Why we wanted to update the header
Since 2017 we've made a lot of changes to the design of www.bath.ac.uk so the header used on our blog site started to look outdated and out of step with our core brand.
If we adopt the same look and feel across our platforms, the user is not suddenly hit with content that looks completely different. They don't need to acclimatise to differing functionality and they are reassured that the pages are official, because they carry the same branding.
Something extra
In addition to achieving that same look and feel, we wanted to introduce a bit of animation and reduce the size of the header when the user scrolls on a larger tablet, laptop or desktop computer.
What the challenges were
Most of the pages on www.bath.ac.uk are created using our bespoke platforms; Typecase and Typecase for Courses. Our blog site uses WordPress, an open-source content management system. So not only do they use a different code basis for the build, but the component structure (how the different parts of the pages are split) is not the same.
Same same but different
The global page size was different on this site and without changing that, we'd end up with things sort of being the same, but not quite. If the design is not precise it could appear less trustworthy to the external user - think about those spam emails which use a company's logo, but it's a little bit pixelated.
WordPress sites use several templates for different scenarios, such as site landing pages, blog posts and blog pages, so when making a global change, you have to make sure it works on every type of page.
Scroll and swap functionality
We wanted to shrink the header on scroll, which meant adding some JavaScript to swap over the logo and reduce the height of some elements. This involved quite a bit of trial and error as there are multiple ways to approach this. You need to be careful about how your changes work in multiple scenarios; on different screen sizes, devices and pages/posts.
When you visit the site you are presented initially with the full-sized header:
As you scroll down the page you see the reduced sized header and the smaller logo:
We use a different logo and display for mobile devices and small tablets, so if you want to see this in action you will need to view it on a larger tablet, laptop or desktop device.
The process
There are multiple stages to our process to make sure we consider the wider context and check everything works before it goes live.
- Discovery: We review our options on how to tackle the story and agree on the next steps.
- Estimation: We decide how many points the story is worth. We give our scores individually, discuss and agree on our final score.
- Draft the changes on staging: We make a copy of the live site in our staging environment. We can then draft our changes somewhere that won't affect any of our live content.
- Review: Another member of the team, takes a look at the changes and will give feedback on anything they think could be improved. They look at coding conventions, functionality and design.
- Accept/reject: The product owner will take a look at the proposed changes and either accept or reject them. If the story is rejected, we'll make further changes and then ask our reviewer to re-review.
- Schedule downtime: Once the story has been accepted, we let our blog users know that there will be a period where they should not make any changes.
- Go live: During the scheduled downtime, we will copy the changes to our live site.
Moment of pride
Much of what we work on is not very visible. We are either fixing a bug or making a small improvement which improves the look and feel or improves usability or accessibility. The header is very visible to all users, so it's great to be able to see something you've done go live. And now we're looking into using it on the main site too.
Respond
