New post - 'An intro to agile for new devs'

The core of my skillset is front end, including expertise in React, page load performance, accessibility and authoring UI component libraries. I also have 8 years’ solid experience of Node.js.

I understand every angle of a successful agile team including user-centred research and design, continuous delivery, TDD, test automation & strategy, pairing and shared ownership of quality and dev-ops.

I have skills in:

React

scalable CSS including CSS-in-JS

Node.js

Javascript

Typescript

page performance

accessibility

micro-services

micro-frontends

progressive enhancement

TDD & unit tests

BDD & end-to-end tests

responsive / mobile web

CI / CD

agile

rapid prototyping

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.

Accessibility

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.

jonnywyatt2 - [@] - gmail.com