Form input prefixes and suffixes

[timpaul]

Update: This proposal was approved by the Design System working group in June 2020. See https://github.com/alphagov/govuk-design-system-backlog/issues/134#issuecomment-654968716 for more details.

Earlier review: Update: This proposal was rejected by the Design System working group on 13 April 2018. See the comments for more details.

---

What

Prefixes and suffixes on form inputs.

Why

Prefixes and suffixes are useful for any service that needs to ask for things like measurement units, currencies, percentages, area codes etc.

Anything else

Here's a prototype showing some proposed guidance and examples

The code is on GitHub here

[edwardhorsford]

Some thoughts:

The gap between input text and right aligned suffixes can get quite large. I wonder if there's any solutions to this. Off the top of my head:

• Right align all input on this
• Size the fields dynamically to the content
• Leave as is

Will js be included to swallow characters matching the prefix?

The telephone one makes me slightly uncomfortable as it's something that users may want to change - I presume they can't. I guess the label could be 'UK telephone number' - but then is the prefix necessary? It may be easier to treat international phone numbers as a separate pattern to be researched.

[timpaul]

Thanks Ed. I think the suffix issue is one to keep an eye on. My hunch is that suffixes are typically used for things that have a relatively short or known length, like numbers - but of course there will be exceptions.

Good call about swallowing the prefix/suffix characters. Feels like a future enhancement rther than something that should block publication?

Yes, telephone numbers would need an additional control that lets you change the country - which would then automatically update the country code prefix.

[NickColley]

Do we need to associate this information in anyway for users with access needs?

If the +44 input indicates that we are looking for a UK telephone number, should that be repeated in a hint?

[edwardhorsford]

I think it would be good to treat international numbers as a separate pattern.

My hunch for something to try: Phone number prefix [custom autocomplete]

Telephone number [ ]

I wouldn't have the prefix in the number - I'd just treat it as a separate field.

[abbott567]

We had this conversation on our service for when agents were entering Child Benefit numbers. They always start CHB, so should we just prefix the input? But then what happens if I type CHB into the field. Is it now CHBCHB? Is that a validation error? Because, technically you've added a valid number, but the prefix made it invalid.

In the end, we just accepted it was probably better to let the agents put it in how they wanted, with or without the prefix, and do some work to sanitize and format it in the backend.

[joelanman]

are there any examples of services that use suffixes and prefixes?

[stevenaproctor]

@timpaul I am in the middle but slightly more down so I voted :-1:

In the examples, all of the prefixes and suffixes are hidden from screen readers, making them just a visual enhancement. This is fine but how do we give this extra information to those users without loads of visuallyhidden text or aria-hidden=true? That seems over the top to me when the user need can be achieved with better content and labels.

Similar to what @abbott567 said, we would still need to be deal with people who repeat the suffix or prefix.

@joelanman I have seen a lot of pound signs used outside of inputs like on Pay your Self Assessment and occasionally seen things after inputs too but cannot think of the service.

Both are usually in <span>s and can seem random when you use a screen reader, especially the suffix because it is read out after you leave the field.

[edwardhorsford]

@stevenaproctor

I'm pretty sure there's a hidden label too that's attached to the field. When we tested them as part of the patterns work last year, each had hidden text. Something along the lines of "Ticket price in £".

I suspect most suffixes should still get read out beforehand. Something like "Total weight in kg, INPUT". Not all of them need to be announced - I think "Percent complete" is correct as it is. Keeping the visual treatment and the labels separate works well for this - services will need to decide on the most appropriate label.

In terms of repeating suffix or prefix - depending on use case, I think we could swallow those characters - but regardless services will need to deal with them on the backend - just like they strip whitespace on postcodes. Services should be able to deal with "£2.56" and "2" etc.

[edwardhorsford]

@joelanman

We had a prefix on passports for the tracking number:

We didn't swallow the "PEX" characters if users typed them, but would have stripped them on the backend.

If I were doing it again I'd have the prefix inside the box as per the designs above (which I subsequently worked on).

[stevenaproctor]

@edwardhorsford There is visuallyhidden text in the label but it seems over-engineered to me. You could say 'Ticket price in pounds' and that would work for everyone. They do look like mini-buttons too.

[timpaul]

Thanks everyone, this is really useful. So, what I think @stevenaproctor and @abbott567 are suggesting is something more like this?:

[tspear]

I voted down too, I agree with the 'mini-buttons' comment and I wonder whether the user need is better served with hints or examples?. So not sure about useful/unique here.

[cathydutton]

I’m also leaning towards a thumbs down,

•   Is there a clear user need for this or do we have evidence of users failing to recognise units in labels?
•   Would this pattern replace units being placed in labels/hint text or be used alongside? 

Could this be useful in situations where multiple units are accepted?

[jonhurrell]

I built the prefix this was based on for the budgeting loans service to denote loan amount as pounds. I was hesitant to see any utility over a label, until I went to a job centre and saw people struggle trying to find and execute the keyboard shortcut for the pound glyph. For those that entered it within the input, we allowed it and stripped it out on post.

I saw no evidence of people trying to click them as buttons, especially given the context of using a service, where a button or action convention is pre-established.

Is there a reason people with dyslexia may prefer unit glyphs over label, or vice-versa?

[stevenaproctor]

@jonhurrell The British Dyslexia Style Guide says "Pictograms and graphics help to locate information." which could explain people struggling to find the £ on a keyboard. This is the principle behind Easy Read documents too.

The examples could use both words and symbols. Something like 'Ticket price in pounds (£)'.

[timpaul]

Thanks to everyone who reviewed and voted on this proposal. The final result was 3 votes for and 4 against, so we won't be developing this component for now.

In summary, there's not enough evidence that this component meets needs that can't be equally met by other components like form labels.

We'll move this card to the 'Not doing' column where it can act as a record of this decision.

[edwardhorsford]

Long comment incoming.

I'm rather sad with this result. I hope it can be reconsidered.

If there's still discussion going on, I suggest giving people a chance to address concerns before having a vote. As it is, I don't think there's yet a firm proposal for what the design might look like, with different people commenting on different designs.

---

Reasons

This is a really common pattern already in use across many government services. It would be great for us to standardise our approach and provide an accessible solution. I see people asking for code snippets for it really regularly.

I feel like some of the concerns raised here are about whether they're always necessary. There will absolutely be cases where they might not be - such as @abbott567's case number example. Does that mean we shouldn't have a pattern for it though? or that we should let services use their judgement and research to determine when it's helpful.

The other concern I see is about services having to deal with the prefix or not - but services already need to deal with this regardless of the pattern. It's part of doing the hard work to make it simple. In Craig's example, I wouldn't expect the prefix to get submitted - so the server will either get CAB12345 or 12345 - regardless of the prefix it should arguably deal with both.

The prefix the patterns team at GDS built last year had it styled like this:

We tested this across three rounds of research and it worked well. The styling avoided the potential for it looking like a button (though I'm not too worried about that).

I think changing the label to "Approximate cost for tickets in £" would be detrimental and make the label too complex.

---

Prefixes in labels

I have concerns with the suggestion of standardising on adding prefixes to labels - and don't think it works in all situations.

The labels are the most important part of the field, whereas prefixes are extra visual touches that help by adding affordance to the field. They should be secondary to the label. Adding them to labels makes the labels longer and more complex - possibly harder to read.

There'll also be cases where it really doesn't work with the label. Here's an example from HMRC self service:

And one from Help with fees: In these cases, I think adding it to the label would be really weird. You could argue it doesn't have to have a prefix at all, but I personally think it's a nice extra touch.

NB: There are probably cases where the unit works really well as the label. Services should be free to choose between the two depending on user need.

Other examples

Here's some more examples we collected prior to our research last year. We were only looking at currency input - so I don't have examples of other types of prefixes. We judged that currency input would be by far the most common form of prefixed input.

Office of the Public Guardian

Digital Marketplace

Pensions

HMRC Personal allowance calculator

HMRC unknown service

[jonheslop]

FWIW GOV.UK Pay use @edwardhorsford and @hannalaakso’s markup from the their research last year and it works well for us

Code: https://github.com/alphagov/pay-selfservice/blob/a06ba1074f4f099f7bdd47e1a0b802a0d2d4d46c/app/views/dashboard/demo-service/create.njk#L20-L29

[vickytnz]

I feel like there's something in investigating the different options available - including the default if we can't have this of how we ask for money. I know that the design system feedback format has iterated - this could be worth investigating more and then bringing back in another format?

(I'm interested in this for reasons such as how we encourage people to input in GBP - or allow them to put money in a different currency and do conversions on the backend ...)

[frankieroberto]

Here's another example from the NHS, which uses suffixes for weight and height units as part of their BMI calculator:

Metric:

Imperial:

[james-siteclick]

In our service we are using a suffix for the unit of measurement, similar to the NHS example above. It would be great to have a standard pattern for this.

[kr8n3r]

HMRC's Tax account is using this pattern

[timpaul]

Related: https://github.com/alphagov/govuk-frontend/issues/924

[dashouse]

Input prefix and suffix

I've researched use cases of Input prefixes and suffixes across Government on https://github.com/alphagov/govuk-design-system-backlog/issues/134, across GDS products such as GOV.UK Pay, Digital Marketplace & GOV Wifi as well as patterns on the GOV.UK Design System, such as https://design-system.service.gov.uk/patterns/payment-card-details/

Component slots

From this I have found there are potential use cases for 4 'slots'.

• 2 external BeforeInput & AfterInput
• 2 internal InputPrefix & InputSuffix

Slot contents

These slots could contain text or images. Both of these could be decorative, such as an a illustration of a credit card or interactive, such as a password reveal toggle.

There should be an option to override the colour of the icon or text based on use case.

Questions and considerations

• Can items in BeforeInput & AfterInput still be associated with the Input in a meaningful way?
• How could we achieve auto-spacing for unknown content in these slots?
• If we moved to Flexbox for this, would that affect how we size inputs generally?

[dashouse]

Work in progress code based on above design. https://jsfiddle.net/0qf1vpLs/2/

Notes from prototyping this design:

• Input padding may be dependent on the glyph – £ needs less padding than %
• Absolutely positioning the internal prefix / suffix is easier to control than wrapping all elements and creating a ‘fake’ input. This means the only difference between BeforeInput and InputPrefix is styling, not markup
• Actionable icons should not be places inside input as having them inside leads to confusing focus interaction
• Prefixes / suffixes inside input disappear when text colour is overridden to white. Haven't spent a lot of time looking at this, but because inputs will retain a white background when colours are overridden the text becomes invisible

[aliuk2012]

In Digital Marketplace, we use an input with a suffix and came across this interesting issue (Another reason why prefix/suffix might not be a good pattern to follow).

If the user has a browser extension that adds its own icon to the input then it can obscure the services suffix and the extension icon.

Example:

[a184studio]

Has anyone had any issues with decimals? We need it down to the penny, as £1± over £500 could result in less/more in payment.

Something along the lines of this.

[adamliptrot-oc]

Has anyone had any issues with decimals?

We've looked at currency inputs at HMRC and tested a grouped input, however we found it difficult to make it non-confusing when using a screen-reader. The issue was that the first input encountered would be for £, which everywhere else you would enter the full figure, including pence. Then you would go to the next input which would ask for the pence amount.

Making the screen-reader user aware of the second input was the difficulty when the learned style is a single input. Adding some explanatory text for screen-readers was cumbersome.

In the end we settled on a single input (HMRC Currency Input pattern), with inputmode of decimal to provide the correct keyboard on touch devices.

[a184studio]

@adamliptrot-oc Yeah, Suspected it would cause issues with screen readers. We are going to stick with a single field and then loosen up the validation a bit.

[edwardhorsford]

Two ideas I've wanted to prototype (but have not and have no research for):

Have a single html input for this, but use some nice js input masking so it visually looks more distinct.

I've also sometimes seen sites that count 'up' from the decimal as you type in - I hazard that this might be to catch some errors where people end up with 100x what they intended.

Eg if you type 1, 2, 3, 4, 5 in order you'd see:

£00.01 £00.12 £01.23 £12.34 £123.45

This might catch some of those errors, but at the downside it's less standard and users always have to give you pence as well.

---

Going the opposite way, could you strip all pence, and round down? Simpler for entry (maybe?) if you could get the business on side.

[adamliptrot-oc]

Going the opposite way, could you strip all pence, and round down? Simpler for entry (maybe?) if you could get the business on side.

Even if you round up or down ideally you still need to ask the user for the full amount so we aren't putting that burden on the user.

A lot of HMRC services do round up or down to the user's favour. It depends on the service as to whether they do that for the user or not.

[hannalaakso]

GOV.UK Design System working group review

Representatives from the GOV.UK Design System working group reviewed a prefixes/suffixes variant for text input in June 2020.

Based on a majority vote, the group decided that:

• The contribution can be published as is

They also made the following recommendations.

Guidance

• Create a pattern for asking users to enter an amount of something
• Create a pattern for asking users to choose the unit or measurement

Design

• Consider whether users could confuse the grey background of the prefix/suffix container with a button

Code

• Ensure that the variant works for longer prefixes/suffixes on smaller screens
• Investigate generating the prefix/suffix for the label text with the Nunjucks macro

Next steps

Based on this feedback, the GOV.UK Design System team and the contributor have agreed to:

• Improve the wording of the guidance to make it clear there needs to be an association between the input label text and the associated prefix/suffix
• Ensure that the variant works on smaller viewports, up to a point AND
• Add a recommendation for when the variant should not be used (eg. with very long or complex prefixes/suffixes)

We don’t think we currently have enough information to create a wider pattern for asking users to enter an amount, or a pattern to help users to choose the unit or measurement from a number of options. For this reason we will record these two recommendations here in the backlog, and will keep an eye on how the prefixes/suffixes variant gets used by services to gain a better understanding of the requirements for related patterns.

We decided not to investigate how the Nunjucks macro could generate the label text from the prefix or suffix. This is because the feature would not benefit the users of the HTML version and would necessitate different guidance to the HTML version. It might also not be possible to support the feature once GOV.UK Frontend can support localisation to different languages.

We currently don’t have evidence that the grey background of the prefix/suffix container is a usability issue. MOJ, HMRC and GOV.UK have all used a variant with a grey background on their services. However we should keep an eye out for any related issues. The variant also allows the background colour to be overridden with a class so teams can adapt it to suit the specific requirements of their service.

[MalcolmVonMoJ]

I think click area should include the prefix/suffix box as well as the main input box, so that if a user clicks on the prefix box, the input receives the focus.

I made a quick mock-up of this behaviour by altering the CSS of one of our current currency fields:

[hannalaakso]

@MalcolmVonMoJ Thanks for the suggestion. It would be good if this interaction could be tested with users. For instance if you have both a prefix and a suffix, could users think that something "happens" or is activated when you click the prefix or the suffix, and might users think that whatever "happens" is different depending on whether you click the prefix or the suffix? It would be useful to hear any findings from teams.

[MalcolmVonMoJ]

@hannalaakso

The only thing I can offer now (and I have mentioned it before, so this might seem familiar) is some user research from the MoJ regarding currency fields. Some users were reported as thinking that the grey box around the prefix (as found on the MoJ Design System) was a button to change the currency (£, $, € etc). For this reason, many services opted to drop the grey background for a clear one (you can see the pattern we all use in the video I posted). However I don't know any more than that - the user research and design decision preceded my joining the team - I was just told the results. I would assume that a similar behaviour might be witnessed for suffixes (kg, lb, st etc).

However, now that the Design System working group has decided on this pattern, I was just trying to suggest that the prefix and suffix should be considered part of the input. If users were expecting the currency to change, the input box receiving focus might inform them that typing in is all they can do. If nothing happens, that might lead to a moment's confusion.

I think we have a new round of user research and testing on the horizon, I'll suggest that we make the changes as seen here and see what the results are. However, most of our currency fields have a selectable suffix as can be seen in the video (select: per week, per month etc), so might not be ideal for testing this pattern.

Hope that all makes sense (and is useful).

[edwardhorsford]

I like @MalcolmVonMoJ's suggestion. It loosely follows the existing pattern that clicking on an input label will focus an input.

[hannalaakso]

I think we have a new round of user research and testing on the horizon, I'll suggest that we make the changes as seen here and see what the results are.

@MalcolmVonMoJ It would be great if you could post findings from relevant user research here. We hope to publish the new prefix/suffix variant within the next month so it'll be available for testing then. If you need to combine it with a pattern for choosing the unit it would still be useful to document the findings here.

[lfdebrux]

@hannalaakso I'm really pleased to hear the working group has decided to accept the contribution!

Would it be possible to update the comment at the top of the page to reflect the current status?

[timpaul]

I think click area should include the prefix/suffix box as well as the main input box, so that if a user clicks on the prefix box, the input receives the focus.

I made a quick mock-up of this behaviour by altering the CSS of one of our current currency fields:

Hi @MalcolmVonMoJ - did you have any results with your suggestion of making clicking on prefixes and suffixes focus their input?

[MalcolmVonMoJ]

Hi @timpaul

In regards to user research, I'm afraid not. All our currency inputs are using this approach, but the round of user research that I was hoping would look at this didn't look at this part of the service. I am still hoping to have this included in the next round of research in this part of the service. The previous pattern (without the grey border) worked well, and that had an identical click area with this one.

In regards to technical implementation, it is quite easy (we had to make an unexpected adjustment in the CSS for Firefox as this behaves slightly differently, but this was also easy).

However, we just did it for currency input where the size of the prefix is constant - this means that the padding can be fixed in the CSS.

I was thinking about this last week and if you cannot be sure what the width of the prefix is, then the padding either has to be changed by the developer for each input or be a set by JavaScript.

Given that the pattern is published, it might be best to just write a bit of JavaScript to get the width of the prefix and then change the padding for the input element accordingly.

With our setup, we only use JavaScript for a slight adjustment to the error state. As the whole area is selectable, we initially highlight the whole box in red.

We then use JS to change the black prefix border to red too - as it is a little odd to leave this black.

[frankieroberto]

I like the "honesty", as I think @timpaul put it, of having only the input area highlight on error or focus. This also avoids any overlaps where browsers add icons within the form fields (eg for autofill).

Possibly having the input field focus if the prefix or suffix boxes are clicked could be considered as a javascript enhancement though?

[timpaul]

Thanks for the suggestions @MalcolmVonMoJ and @frankieroberto - I've raised an issue for this idea here: https://github.com/alphagov/govuk-frontend/issues/1973

[timpaul]

Following up on @edwardhorsford s comment here: https://github.com/alphagov/govuk-design-system-backlog/issues/134#issuecomment-627413219

Here's how Paypal do it...

So less of an input mask, more of a placeholder hint?

[edwardhorsford]

@timpaul that's different than what I was describing.

[timpaul]

Hah, yeah I see that now - that Paypal use case is pretty limited

[lalexander12]

When asking about pounds (currency) can I ask if we always need to spell out the pounds?

eg, Tell us how much you have in your bank account, in pounds?

There's lots of examples on this thread where people aren't saying the 'in pounds' bit.

[RobSinclair]

Findings from a DAC Accessibility Audit on a service using various inputs with both prefix and suffix types:

We are actioning their feedback by adding hint text to be read out.

Might be worth adding some extra detail into the component guidance to make sure there's enough information on the page for screen readers to be able to determine the information that's in the prefix/suffix - or updating the component to not hide the prefix and suffix from screen readers.