Making with Dough
Over the last year, the Money Advice Service has been putting together a reusable component library for use on our site. It’s called Dough and it’s now powering nearly all of the common UI elements across a suite of around twenty five tools, calculators and websites. It’s completely open source and available for you to use too.
Dough is a collection of server side helpers that generate markup. Simple yet powerful – there is a single copy of the HTML for documentation, tests and live implementation. Change once, change everywhere.
These bits of markup are then styled, initially by Dough’s base CSS, and then by a ‘theme’ layer. We chose themes for a couple of reasons;
- We’re open source, and themes make Dough easily fit any design style
- We have a couple of visual styles at the Money Advice Service – the main site, and the blog and so each have their own ‘theme’ for Dough
We’re a public organisation and reaching the widest number of users is a major priority. Our components are fully tested in house and with our partner agency, Digital Accessibility Centre.
We believe this makes our component library pretty unique and goes the extra mile in making our tools as wide reaching as possible.
<p class="component" data-dough-component="Tooltip"> <p>Tooltip text goes in here</p> </p>
There’s also a common interface from which all components inherit to ensure consistency in code and behaviour.
For the Rails-based helpers there is a solid RSpec suite of tests to ensure the inner workings of Dough are behaving as they should.
Alongside automated testing, knowing that we’re working with the same markup everywhere gives us assurance that things are going to be consistent. Confidence also brings flexibility – everything running from the same markup means we can iterate quickly and see the affects reach across the entire suite of tools.
In the real world
We’ve just launched our Retirement Adviser Directory which makes heavy use of Dough (mostly it’s form helpers.) These will generate our preferred markup for form elements, and handle our style of validation.
Aside from working out what to ask the user, using Dough meant we no longer needed to spend time thinking about how much space should be between fields, how wide they should be, what the focus state should look like, how validation should work, etc.
Dough targets Ruby on Rails as that’s what our tools are built in, but we’re interested in making this more agnostic.
Obviously this isn’t a golden hammer. It’s not going to make our projects so trivial that we barely need designers and developers. It allows us to focus on the bigger problems we’re trying to solve. We believe that time is better spent working on how we can provide value to the users we’re aiming for, rather than designing a submit button every time a new project starts. With Dough, you can prototype with production code, which means we get ideas out to users sooner and iterate faster.
We’re working on a front-end for Dough – “Made with Dough” – which we hope will be a resource for how to get started, how to contribute and all other things Dough.
[This was written for the Making Money Advice Service blog, and has been cross posted here.]