Landing pages of hope and glory

Posted in: Back-end development

Permission to land

In July 2017, based on the feedback the team has received over the past year, we made the decision to improve our landing pages. What we now have is the culmination of an intensive project with major contributions from the different disciplines within Digital. This is how we developed the new template.

Over several iterations, the design team put together a template using movable and interchangeable strata to highlight the key items related to a department. To do this, we exiled ourselves into a small room that would later become known as the "Dev Shed". Fuelled by tea and optimism, we took a week and most of a whiteboard to settle on a final design.

A whiteboard showing a data model
Landing page data model (revision 84)

As part of the improvements to our website, we’ve been working towards a new, modular, way of combining content which will mean that individual components can be reused across different types of pages. This will reduce code duplication and allow other content types to follow the same path in the future.

As a way to handle different groups of content as a common "Container" object, we settled on Single Table Inheritance (or STI).

Based on the design, we identified four sections - Pinned Items, Events, Awards & Accolades, and Contact information - that share a database table and basic fields such as Title and Summary. Each section could then be sub-classed to allow for its own particular logic.

On approach

Despite a few snags, the STI approach has worked well, with Rails making the process relatively painless! First, we built the backend. It took a long time, and much code, but we got there in the end. Keeping to our plan for a modular system, we built each section as its own component and combined them onto a single form.

When we'd finished, we had a 34 A4-page-long form. We decided this wasn't ideal from a user perspective.

At this point we split our resources. One of us (Justin) began working on modifying the publisher to generate a page from the raw data, while the other (Chris) took on the not-insignificant task of compressing our unwieldy form into something logical, functional and - most important of all - usable.

A screenshot of the Landing Page editor form
The new landing page form - designed with usability in mind.

We were able to build on some previous work on movable objects that had already been implemented on Team pages. Users can already reorder the members on a Team page by dragging and dropping. The JavaScript driving this provided us with a nice template for the Landing Page work. The end result uses JavaScript to rip out any empty form sections and restyle the full ones. The jQueryUI sortable plugin then lets the user drag-and-drop each section into place. JavaScript buttons add new sections, or let you remove old ones. Design stepped in to make sure each movable chunk looked and felt connected and manageable. As a final tweak, we added CSS toggles to let each large section be collapsed down to a slimline block for clearer dragging.

The job of updating the publisher has been made easier by our recent experience with course pages. Most of the work we’ve put into the publishing of course pages has been transferable to landing pages as a baseline. This can then be updated to meet the requirements of the new pages. Both courses and landing pages share our new Lens design system and similar templates. In fact, the landing page is the first content type to make the jump from our previous design system (Origins) to Lens. The process we’ve devised in developing landing pages (with a few tweaks) will form the template for work on future content types.

Cabin crew

Each member of the design and development teams has discussed every aspect of the design, layout and logic throughout the process. From discussing early hand-drawn sketches through to determining conditions for separators to appear on pinboards, the conversation has always been positive and collaborative.

A sketch of the new landing page design
One of the sketches which informed the design of new landing pages

When the time came for the new landing pages to go live, we celebrated with a dragon roar (as is the custom)! Dragon activations usually only occur when large projects have shipped, so they often represent an important milestone for the team. In this case, it represented four months of work across multiple disciplines, involving every member of the digital team through the stages of discussion, planning, design, development and testing.

At the gate

The key thing that we’ve taken away from this work is that it was more extensive than we thought it would be - our editor updates alone totalled 5,000 new lines of code (and 39 deletions) across over 100 files! As this is the first content type we built with this approach, this was to be expected. Future content types will share code which has been added here and so shouldn't need quite so many additions to get up and running.

A special mention (and possibly a medal) should go to Lizz, who had to review every single line of code and somehow did not lose her mind in the process (or if she did, she's hiding it very well).

The whole team can be very proud of what we’ve achieved with new landing pages. This work will serve as a good foundation for updating our other content types in the future and we look forward to seeing what our users produce on their new pages.

Posted in: Back-end development


  • (we won't publish this)

Write a response