Progressive enhancement and team memberships

Posted in: Beta, Content Publisher, Development

We recently shipped some changes to how we order team members in our Team Profile content type.

These improvements came in several stages, each building on the last, so this seemed like a good opportunity to talk about progressive enhancement.

What is progressive enhancement?

The Government Digital Service's service manual has a great explanation of progressive enhancement:

It’s based on the idea that you should start by making your page work with just HTML, and consider everything else an extra.

This is because the only part of a page that you can rely on to work is the HTML. If the HTML fails there’s no web page, so you should consider the rest optional.

We prefer this approach to immediately building a feature with all the extras (like JavaScript) and then trying to make it degrade gracefully (or just keeping our fingers crossed that it doesn't break).

Progressive enhancement is important for accessibility. By making sure your feature works with HTML alone, you can be more confident that your feature will work for people who are:

  • using assistive technologies
  • on slow or compromised connections
  • don't have JavaScript enabled for some other reason

Progressive enhancement is also well-suited to Agile, as you can start with the core functionality and then iterate.

Introduction to the feature

Users have two options when it comes to creating team profiles:

  • 'Create manually' – create a list of names and roles using Markdown
  • 'Select from Person Profiles' – add Person Profiles to the team to pull through the member's name, role, photo and other important information

When we first built the 'Select from Person Profiles' feature, users had no say over the order in which the team's members were listed on the page.

Members with the 'Leadership Profile' subtype were always listed first. All other members were then listed in alphabetical order. Our users reported that this wasn't ideal and it was often important that members be listed in a certain order. For example, the manager of a team should probably be listed first, even if they don't have a 'Leadership Profile'.

Adding the order with HTML

Our earlier version of the Team Profiles interface did have some JavaScript. Adding the order was complex enough that it was easier to strip out any existing JavaScript and go back to basics.

After some complicated data structure changes behind the scenes, we had a shiny new field called 'Order in team'.

Team members in the base implementation
Team members in the base implementation

Users could now specify the order by entering numbers into these fields. When they saved or published the page, members would appear in the order they'd chosen, both in the interface and on the page itself.

Saving the page also added more empty member dropdown menus, so users could add more members if they wanted to.

We now had the core functionality, even if there was still room for a bit of polish.

We shipped this version of the feature and then moved on to the enhancements.

Adding the magic with JavaScript

We had the essential behaviour of the feature, but there was still room to improve the user experience.

Now that we had a feature which worked with HTML only, we could add enhancements for any users who also had JavaScript enabled.

Our JavaScript addition did several things:

  • replaced the multiple dropdown menus with a single one, which adds new members to a list below
  • allowed users to drag and drop the members in the list into their desired order
  • hid the member order fields, but updated them behind the scenes whenever users rearranged the members through drag-and-drop
  • added a remove button for each member to take them off the list

These enhancements make it quicker for users to add, reorder and remove team members.

Team members with JavaScript enabled
Team members with JavaScript enabled

If the user doesn't have JavaScript enabled, none of these enhancements kick in, but the feature still works as before.

This means the Content Publisher can still be used by broad range of people, no matter which technology they're using.

What comes next?

We don't work with JavaScript nearly as often as we do Ruby. As such, our practices need a bit of work.

Because the JavaScript implementation changes the interface, this means inserting HTML into the page. Currently we store this HTML in the script itself, which is messy and difficult to read. It's probably time for us to get familiar with a JavaScript templating engine – Handlebars.js seems like a likely candidate.

Trying (and failing) to test the drag-and-drop behaviour in Capybara also revealed that we need a better way to handle feature tests and JavaScript. We've got some planned investigation into Poltergeist which will hopefully sort this out.

While neither of these changes will be apparent to users, it should make our development process smoother as we roll these sorts of JavaScript enhancements out to other parts of the Content Publisher.

Posted in: Beta, Content Publisher, Development


  • (we won't publish this)

Write a response