When a conversation to solve a problem for the customer begins, the Nucleus Design System team listen intently and contribute wholeheartedly.

Inner city lighting

When the country's homes began to use gas lights in the 1860's, the amount customers paid depended not on the quantity of gas consumed, but on the number of lights they had installed.

Originally, gas was measured by it's lighting power. But with the growth of other uses of gas by the end of the 19th century, the calorific value of the gas became the measurement.

Domestic gas meters became commonplace soon after, which helped to make it more affordable and accessible to everyone. But the process is complex.

As a utility company supplying energy to customers homes it's always been important that billing is accurate, transparent and predictable.

J. J. Mulhall - Gas meter patent 1903


The responsibility falls on both the supplier and the consumer to agree on the quantity of gas that's been consumed in any given period of time.

The challenge

To allow British Gas customers to provide accurate meter readings.

As this challenge has been part of British Gas for over 120 years, it's fair to say that there's a lot of history on this topic.

A number of product teams within British Gas have the need to capture a customers meter reading during different stages of an online journey.

When someone moves into a new home supplied by British Gas, when a customer provides quarterly meter readings, if someone is providing a meter reading on the behalf of someone else, if a customer moves to a new home and keeps British Gas as their energy supplier. This list goes on...


Bringing these product teams together and finding other people responsible for capturing data in this way soon lead to a broad discussion.

We actively encouraged all sorts of conversations and quickly discovered that the core of this problem wasn't only related to accurately capturing a meter reading, but to accurately capture a variety of customer data.

Meter reading, date of birth, sort code, credit/debit card numbers, telephone numbers, reference numbers to name a few.

Accurate and contextual

The accuracy of the data is extremely important, reading a gas or electricity meter can be awkward, difficult and complicated.

To help customers with this we provide lots of information on how to read all the different types of meters (of which there are a lot). Especially when combined with different types of energy supply, be it Economy 7, gas and electricity, electricity only.

After a number of conversations and workshops we were able to distil the requirements enough to produce a scope to design and build improvements to our ns-inputter component.

We all agreed that any help, explanations, descriptions and information is possible to achieve with our existing components, using considerate content. This is where the context can be set.


Plenty of research was conducted from all sides and brought together in workshops and casual conversations. Where we were able to evolve and refine the component into a few key requirements.

We set about introducing these requirements to our already mature ns-inputter component.

The features we agreed on were to introduce mask and separator attributes.


It looks a bit similar to adding a placeholder, but has some key differences.

The mask

The mask allows us to pre-populate the input with helpful characters which indicate and guide our customers to accurately populate the field.

In the following example, the field has 2 zeros followed by 4 hyphens.

In this scenario, we expect the customers meter reading to be prefixed with 00. We assume this because their last meter reading was '003452' and the household consumes on average 100 units per quarter, so the expected value is roughly 003552.

Each character entered into this field will replace the character in the mask until the field is populated with 6 characters.

Our validation can help here too, for example we can add isNumber which will present a validation message if any other character except a number is entered.

The separator

The separator attribute allows us to allocate a specific character to not be overtyped when entering the data.

In the following example, the field has: mask=" - - " separator="-"

When this field is populated the the cursor skips over the separator, in this instance presenting a familiar sort code pattern.


Lego Batman celebrating with fireworks and a martini (©Warner Bros)

Since the introduction of the mask and the separator over 18 months ago it has proven itself to be very useful.

Here's an example that we didn't discover until recently: