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.