Pension calculator from the Money Advice Service

A beta version of a new Pension calculator has just been launched by the Money Advice Service.

It has been the result of several months of work and from a front end point of view, uses several approaches and techniques:


The Pension calculator was fully accessibility tested, to the WCAG AA level of compliance, by users of assistive technology like screenreaders and voice activation software at the Digital Accessibility Centre. The tool makes use of ajax for responsiveness, and it took a fair bit of experimentation to get updates reported via ARIA to a range of software like Voiceover, JAWS and NVDA. This post from Paciello Group was especially helpful.

A Javascript component loader

I wrote a component loader to start up all the UI components required by a page. It uses RequireJS for dependency management, and Promises to report back to the loader when each component is initialised successfully (or not). It was developed using TDD techniques.

Javascript unit testing

I used Karma, Mocha, Chai and Sinon for testing. I’ve put a basic Javascript testing template project on Github including the testing frameworks, a module, spec and fixture. I delivered a talk about the testing techniques I used to the London Developer in Test group.

An event hub

The clumsily named eventsWithPromises micro-library provides standard event hub methods including subscribe and publish, but also includes a promise with every event sent. The listener can then resolve or reject the promise at its leisure, eg even after an async operation such as an ajax request or animation, which will feed back to the event emitter, allowing it to act on that result. In other words, the events aren’t ‘fire and forget’.

Progressively enhanced ‘app-like’ behaviour

As you use sliders and other UI widgets to alter values, the interface is updated with ajax responses. There is also some addition of new text content without a full page refresh. This is achieved using data-binding rather than string templating. The bindings are driven from markup attributes, in a similar style to AngularJS, eg

<input data-value="salary" value="30000" />

The initial value is rendered on the server, then the data binding Javascript populates its data model by scraping that value, ie the above example would lead to the following model data:

  salary: 30000

When the model value is updated it is synced with the server. Any model properties that are different in the response returned from the server are then used to update the element value.

The library that I used for the data-binding was Rivets. To watch for changes in the model I used the very lightweight Iota-observable.

All data syncing was done using async form posts. If Javascript is disabled or fails, the forms will still work.

Go native, don’t fake it

I used native sliders with input type=”range” rather than using a Javascript library to render them. Native sliders are supported from IE10 upwards and can be styled purely using CSS. Some useful references:

Modular CSS using BEM, SASS and OOCSS

I’ve used BEM on my last two projects and it’s invaluable. Naming things is, after all, tough. At first glance it can look verbose if you’re used to your HTML being as uncluttered as possible, but the predictability it introduces far outweighs this.

Every UI component has a corresponding SASS file with all selectors prefixed with that component name eg. .tab-selector__target.

We write CSS for maintainability first, rather than prioritising clean HTML. Some references:

Frequent user testing

We had a dedicated user testing lab and recruited testers that reflected our target demographic, ie people who typically hadn’t saved for a pension. Sessions were lightly facilitated, video’d and the whole team could go and observe the sessions which was incredibly effective for getting everyone bought into the product’s direction.

… and lessons learned?

Release early, then iterate. We were made to wait way too long – 6 months – before our initial release.

Leave a comment

Posted by on October 16, 2014 in Front end development, Portfolio


Talk: BDD-style testing in Javascript

A short talk I gave last week to the London ‘Dev in Test’ meetup group about testing Javascript with BDD syntax and Karma / Mocha.

Leave a comment

Posted by on July 19, 2014 in Front end development


Portfolio: Which? Home Entertainment

I used: Responsive / mobile development | Modular Javascript | Unit testing | HTML5 | CSS3 | SASS | Cucumber / Capybara

Apr 13 – Feb 14

Which? is a powerful brand in the UK, combining highly trusted product reviews with consumer advice and campaigning.

Their web site attracts millions of visits each month and helps drive their large subscription base. The project was a responsive rebuild of the Home Entertainment Reviews segment, beginning with TVs.

TV reviews are presented with high-impact use of 3D rotating images overlayed with tech highlights and the all-important Which? score and review breakdown. Review sections were loaded with pushstate for speed. We integrated with other review APIs such as Reevoo and Pluck.

Sony Bravia KDL 42W705B television review summary   Which

My biggest areas of learning included BDD with Cucumber / Capybara, a bit of a revelation for me. Also responsive / mobile techniques; in hindsight this project should have used a fully mobile-first development approach. We tested Javascript at the behavioural rather than low level and used SASS / BEM / OOCSS to create predictable, re-usable styling patterns.

Working with Rails for the first time and understanding more of the web stack was very empowering; when this contract ended I immediately sought out another using Rails. It has its weaknesses – the Asset Pipeline is a bit too tightly integrated with the front end for comfort – but the speed and ease that you can piece together and debug an app will be a revelation to any front end dev.


Leave a comment

Posted by on June 16, 2014 in Portfolio


A Javascript event hub using promises

The event hub / aggregator pattern is fantastic for decoupling code modules but the emitted events are usually ‘fire and forget’ so if the event listeners want to feed back an error or status report to the event emitter, they can’t.

Adding promises solves this – if the event is published then each event listener will receive its own promise. Once the listener has performed any synchronous / async tasks that it needs to, it can choose to resolve or reject the promise it has received. If all event listeners report success using their promises, then a promise passed back to the emitter will resolve successfully. However if one or more of the listeners reject (fail) their promises, it will fail.

Because the event listeners are receiving promises, they can wait until async activities eg. ajax are complete before resolving their promise. Handy if decoupled modules need to save state or complete animations before feeding back to the event emitter.

The code is on Github, hope it helps someone!

Leave a comment

Posted by on April 8, 2014 in Front end development


Balancing functional and unit tests

It’s been a year and a day since my last post. Plenty has been going on in the last 12 months. I finally took the dive into mobile that I’d been putting off until the tools improved, with a rebuild at Which? in London.

Which? made some bold technology decisions to break with their legacy codebase. Previously using Java in the web app and API layers of the stack, they kept it for the API and adopted Ruby on Rails for the web application.

I’d heard great things about how fast you could build stuff with Rails. I didn’t come to front end development via a server side language so a framework like Rails, that gives an easier introduction to that layer, has great appeal. Without a doubt it’s enabling and makes you a better all-round developer.

Another big thing that learning Ruby has given me is the ability to write automated UI tests with Cucumber. I had heard about CucumberJS early last year but it looked a bit in-progress. Cucumber with Ruby looked more complete with better docs and plugins.

Regarding BDD and the practise of describing features using Given.. When.. Then syntax, that are readable by the business – I’d heard experienced consultants saying things like

“Feature files are a nice idea but I’ve never actually seen them used by a business in real-life”

I don’t buy that view – at Which? the features have been described by a business analyst in Jira then handed over to us to automate. We might make some minor tweaks in language not meaning, to make it possible to automate them.

The company, developers and QA then have a clear contract for what we’re building, and even better, we can code directly against it. When we fulfil the contract, the tests turn green.

BDD is of course an investment – in mocking up the data, working out robust ways to test the code, trying to make the tests run as fast as possible, and dealing with occasional (and sometimes inexplicable) fragile tests that work one minute then fail the next.

Finding a balance between unit and UI tests

Have you ever had someone display a diagram of a testing pyramid and declare that unit tests are far quicker to write than UI tests? I’ve not always found that. I’ve often found Javascript unit tests are at least as expensive to write, largely because you’re mocking out so many of the surrounding components – HTML fixtures, API data, other Javascript widgets, third party code. That’s all fine, and unit tests are essential, but I swear they’re not significantly quicker to write. They are of course many times quicker to run – moments after you saved a change your entire suite of hundreds of unit tests can have completed and it’s that fast feedback loop that is one big reason to write them.

You burn through a lot more unit tests because they’re more tightly tied to the implementation, which in any decently maintained codebase should be evolving constantly as it’s refactored. Parts of your code inevitably get thrown away, implementations change and the unit tests frequently turn red until you turn them green again or remove the redundant ones. The closer the tests are to the metal, the more ephemeral they are.

On the other hand, a UI test, once turned green should only turn red infrequently – if there’s a breakage in the interface, or if a refactor is significant enough to require the parts of the step definitions that touch the implementation, to need updating.

Again, am I saying don’t write unit tests? Absolutely not. They can guide the design of lower-level logic and help find flaws in it. And they can instantly expose regressions as you refactor.

I’m just questioning some commonly received wisdom that you should have orders of magnitude more unit tests than UI tests. All tests are an investment – the time spent writing and maintaining them gets paid back in fewer regressions and production bugs.

I’m totally sold on the BDD way of working now. You won’t always find it happens in a project – I’ve come across the odd very capable front end developer who didn’t see it as part of their role to write UI tests. Although it was in a technology stack that didn’t make it easy to write UI tests (hello Java).

Some QAs get nervous about developers doing it, but they shouldn’t. If the devs write UI tests for the web app that mock out services like authentication and APIs, then it frees up the QAs to write those true end-to-end tests using real copies of the services.

Writing tests and seeing them run green gives calm to the developer. You don’t get that sick feeling in the run-up to a release that you might have caused regressions with your last commit, but aren’t sure where. The better your tests, the more secure you feel. If you haven’t, try it!

Leave a comment

Posted by on January 12, 2014 in Front end development


Testing a RequireJS / Backbone component with Jasmine and jsTestDriver

If you want to use Jasmine to test something that’s inside a RequireJS module, for example a Backbone model, you need to find a way to load the Require module from your Jasmine spec, and pause the running of the test spec until the module is loaded and ready.

I need a few things loaded up front for my tests to run – Require itself, Backbone, jQuery, Underscore.

First of all I’ll load require.js from my jsTestDriver.conf.

Backbone is expressed as a dependency in my require.config, and will in turn pull in the other two libraries:

Now I can load the main RequireJS config file, and hence those dependencies, by loading an extra require.config snippet, which specifies where files can be found under the test server, and then loads the main config itself:

This extra require.config snippet is loaded directly by jsTestDriver.conf. The ‘serve’ directive below makes all files under the /app folder available to my test code under a ‘/test/app’ path. So for example /app/mymodel.js could be loaded by a Jasmine spec from the path /test/app/mymodel.js

Now if I run jsTestDriver, my dependencies are all loaded up, plus my require.config, but not my application. This matters as I should only need to load in the specific module I want to test. I can do this using a require call inside my test setup (beforeEach). Wrap it in a “runs” block then use a “waitsFor” block to halt things until it’s loaded.

These patterns took a while for me work out when I started testing Require / Backbone apps using Jasmine. Hope this helps somebody!

Leave a comment

Posted by on January 11, 2013 in Front end development


Backbone Marionette – using nested views

For the past few months I’ve been picking up Backbone, then Marionette.

I quickly liked and later cursed the fact that Backbone gives you some structure yet lots of flexibility, especially around managing views.

At the start the flexibility makes picking things up conceptually easy. As you move beyond the most basic app you need to keep the creation and destruction of views under control, especially when you start nesting them. Backbone gives you very little to handle this, but Marionette plugs the gap nicely.

Terms used in Marionette

  • A layout is a type of view that can hold other views
  • The element within that layout that holds / wraps the nested view, is called a region. A region can hold one view at a time. It can reload the same view multiple times as required, or swap in different types of view.
  • Marionette.Layout actually extends Backbone.View (not directly, but it does inherit from it). So as a layout is a type of view, you can actually nest a layout inside a region of another layout

The markup

Your template for the outer layout might be:

.. and your template for the view to be nested inside the region:

Note – I prefer that the container element for the nested view shouldn’t be in the parent layout template (it should be created dynamically by the view’s Javascript definition)



Why? I think the view should control its container element, it’s more maintainable. You know that everything relating to that view is in one place in your codebase and there are no fragments of the view contained in other templates.

The Javascript

The outer layout can use its regions to show views, when it has been rendered itself. Use the ‘show’ method of the layout’s region. When you call ‘show’ it automatically calls the render method on the subview.

The View definition for the nested view would contain a className attribute so the view container will be created dynamically when the view is rendered.

You can hook into the onRender and onShow events.

What’s the difference between onRender and onShow?

Remember that when the parent region’s ‘show’ method is called, it automatically calls render on the subview as well, so onRender will of course be triggered after that. At this point the view has been templated and a DOM fragment created. However it hasn’t yet been attached to the parent region so it’s still only in memory and not actually part of the page yet. If you put a breakpoint in the onRender and in your browser console looked for a parent of this.$el (the view’s container element):


it would return 0.

The onShow event fires after the view has been attached to its parent region. If you ran the same line in your console during the onShow event, it would return 1.

More reading on Layouts

Marionette provides structure in the biggest areas left vacant by Backbone. One of the best things about it is its creator Derick Bailey is a prolific blogger and documenter (and Stackoverflow lifesaver).

Check out his blog post – Managing Layouts and Nested Views with Backbone.Marionette and the Marionette docs on Layout.

1 Comment

Posted by on December 21, 2012 in Front end development