govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Addresses
For some time (pre Design System) our recommended multi-input pattern for entering an address has contained two inputs for "Building and street", with the second input having a visually hidden label (as well as visually hidden 1 of 2 and 2 of 2).
This second input is to support users that need to enter a Company name, building name, floor, department as well as their street address.
We are wondering if anyone who has tested this pattern has seen any issues with visually hiding the second label?
I am struggling too with the hidden label concept - when there is an error in that field we are trying out error messages that reference Building and street (line 2 of 2) as the field descriptor in the message.
Also quite challenging is how to communicate that the second line is optional? (In our service line 1 and postcode are the only required fields).
If the 2nd field in the address (address line 2) is an optional field then you could have "Optional" as hint text above it perhaps?
Dropbox Paper audit
The research below was taken from a Dropbox Paper document, which was reviewed and archived On 8 Jan 2019 by the Design System team.
The aim was to reduce the number of places containing guidance and code by:
- migrating relevant, useful content into the Design System itself
- recording important research findings in the community backlog
- removing the original Dropbox Paper page
If you need to, you can see the original Dropbox Paper content in the internet archive.
Research
Open Address UK did some address entry user research - qualitative testing (9 users) of free text box (which they describe as 'one single address field') against multiple fields. The results were mixed: some users preferred free text box, others preferred multiple fields. Users were faster with free text box, but ended up with more errors in the address. They made more mistakes to start with on multiple fields, corrected them as they moved address elements around, and ended up with fewer errors in the end.
The forms they used had some usability errors such as use of placeholders for example text, so those usability errors may have influenced the results.
Related links
http://www.formsthatwork.com/internationaladdresses http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php http://www.bitboost.com/ref/international-address-formats.html#Formats
I have a question around examples of overseas postal or zip codes. I'm looking to add an example that isn't UK as our users shouldn't have a UK address but there isn't anything that I can find in the design system giving an overseas example that we can use.
Try the Universal Postal Union: http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html
and select "Guide to the headings used in country sheets"
Hope that helps
This is really helpful, thanks! It's great for checking if our validation for field length stands up. It still leaves a bit of a question mark around examples we can use though.
I'd like to create a pull request add text to https://design-system.service.gov.uk/patterns/addresses/ The text would describe how to handle input to a postcode field. I'm aware of issue #82
Does anybody object?
Hi @terrysimpson99 thanks for your message. Would you mind expanding a little bit on what the PR would contain? Would it be a hint text for the user, or some documentation for the service team on how to validate postcode input?
Hi @hannalaakso The latter. I'd like to add guidance about validation. Inspirations for good validation include: https://www.gov.uk/find-local-council https://courttribunalfinder.service.gov.uk/search/postcode https://www.royalmail.com/find-a-postcode
Those services accept characters that aren't part of a postcode. For example: "ch1-1aa", (hyphen) "ch1 1aa" (extra space within code), "ch1 1aa" (space before code), "ch1 1aa,"(comma), " ch1 1aa." (period). In addition, some services have a limit on input characters that turn "ch1 1aa" into "ch1 1a" and then tell the user it's invalid.
Anyone that received an email or text message with those examples would accept them as postcodes and wouldn't send a message back to the user saying they hadn't provided a valid postcode.
I won't name examples of unnecessary rejection but there are sufficient to make it worth mentioning.
Hope that helps.
Thanks @terrysimpson99 we've discussed your proposal with the team.
It would be great if you could submit a pull request as this will give us an opportunity to review the changes and discuss them with other teams.
It's hard for us to say whether this will work as guidance in a wider government context without seeing the actual changes.
Sorry if that's not too helpful! We're really grateful for your offer to help us improve the Design System 🙌
Hi all - is there any reason we don't have hint text (and a more specific error message) for postcodes? With email and phone numbers we are giving examples in hint text and in error messages (e.g. "Enter an email address in the correct format, like [email protected]" or "Enter a telephone number, like 01632 960 001, 07700 900 982 or +44 0808 157 0192"), but the best we're offering users for postcodes is "Enter a real postcode" with no guidance as to what a 'real' postcode looks like, what they might have incorrectly entered, etc?
What is the recommendation for capturing addresses which may or may not be non-UK (e.g. if we ask for a contact address and there's no guarantee it will be in the UK)?
The address standards says we should use (a) address lookup (but this doesn't usually work with non-UK addresses), (b) multiple text inputs (but this isn't recommended for non-UK addresses where we don't know the country and therefore the format) or (c) textarea (which we can't use if we need to use separate elements of the address at a later point).
That doesn't seem to leave any useable option for capturing a non-UK address?
If you look at https://design-system.service.gov.uk/patterns/addresses/ you'll see some guidance such as "Address lookups generally only work for UK addresses. Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses". There's more if you look further down.
If you look at https://design-system.service.gov.uk/patterns/addresses/ you'll see some guidance such as "Address lookups generally only work for UK addresses. Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses". There's more if you look further down.
Thanks Terry, but further down it then says you should only use multiple text areas "when you know which countries the addresses will come from" (which we don't) and "use a textarea if...you do not need to...use specific sub-parts of the address" (which we do). Hence why we seem to be stuck in a loop of address pattern options that we shouldn't use.
I'm surprised that, considering how many services might need to capture an address which could be either UK or non-UK, there hasn't been a catch-all pattern look at at some point.
e.g. Amazon used to have a generic form (not sure if they still do):
The example shows a field marked 'County'. For some time now, the county hasn't been required for addresses. When asked to state their county, people use a variety of terms for the same thing (I can give examples if you want). I think it's visual and task clutter for the user. (1) I propose we don't use county in examples. (2) I propose the guidance is update to recommend that county isn't used. What do you think?
We have been doing some work on my current service around bringing things onto pattern with the design system. we noted that currently our Address lookup is off pattern but the current address lookup pattern has a select list within it.
A select component according to the design system should only be used as "last resort in public-facing services because research shows that some users find selects very difficult to use"
I'm wondering if this has been thought about because currently, the design system is contradictory.
We've been experimenting using radios and I've mocked up a working version with real data, but it's a work in progress. Get a fishing licence already does this I believe.
On the subject of international addresses, I would suggest that there is a toggle for uk/non-uk address where either could be possible. UK addresses needs to use postcode lookup, of course.
For non-uk addresses, there are many internationalisation issues.
Separating a non-uk address into separate fields is problematic in general, particularly if used to send any mail to.
- address lines may appear in a different order to the ones we use in the UK. e.g. Japan has the postcode, town, prefecture (effectively a county) then country in that order.
- Some countries have regional breakdowns that are very different to the UK.
Accepting international addresses means that we potentially should accept the full range of characters from a recent Unicode Standard.
- End to end systems will need to be tested for round-tripping the addresses from input to storage to output, without corruption.
- This may then cause difficulty for manual handling of the addresses, if people reading them don't have the expertise in scripts that have been used.
Royal Mail says: "There is no need to include a county name, your letters and parcels will reach your intended recipient without one. If, however, you'd prefer to include a county name, you' are welcome to do so." See 'Address format in detail' at: https://personal.help.royalmail.com/app/answers/detail/a_id/81/~/how-to-address-your-mail-%28clear-addressing%29
The GDS current guidance makes it mandatory to include a county field: "Royal Mail does not need a county as long as the town and postcode are included. You should include an optional county text input so that people who do not know their postcode can give a valid address.".
I propose those two sentences are replaced with: "Royal Mail says there is no need for county name in addresses."
Comments?
@terrysimpson99 feels in line with trying to ask users less information, do we know what impact removing county name has on successful delivery?
@terrysimpson99 the Royal Mail guidance says county is not required but I imagine they're saying that assuming the user has entered a postcode. Do we know that a county is not required when a user has not entered a postcode?
Yes it's a reasonable suggestion that county might be useful to Royal Mail as backup to absent, incorrect, or illegible postcodes. If that were true, it would be a bold step for GDS to drop it from examples. However Royal Mail doesn't show county in their own examples of good addresses, their address tools don't use it, and guidance that county isn't required doesn't have any mention of it being conditional on a postcode. They spent years transitioning to county-free addressing and the benefit of county as a backup hasn't been mentioned in any of the discussions I've seen.
The term 'county' is ambiguous anyway. Users give inconsistent responses and may give the: 'former postal county', 'historic county', 'traditional county', 'preserved county', 'administrative county', or the adjacent county (this is common in cities that overlap boundaries). This isn't just a human failing, some machines have similar failings, for example Argos thinks Manchester is in Lancashire (it isn't).
The address lookup tool used by many government services doesn't provide county because it uses the Royal Mail database of 'correct' addresses. I quote Royal Mail guidance as the dominant letter service but other delivery services appear to be the same.
Thanks Terry, but further down it then says you should only use multiple text areas "when you know which countries the addresses will come from" (which we don't) and "use a textarea if...you do not need to...use specific sub-parts of the address" (which we do). Hence why we seem to be stuck in a loop of address pattern options that we shouldn't use.
@jonathaninch have you considered asking for the country and then providing a multiple text input address pattern once you know the country? This is something we are currently struggling with too.
Interesting. The guidance says:
- "Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses"
- "Only use multiple text inputs when you know which countries the addresses will come from ..."
In our service the default design is the UK postcode button. We make the manual option available as an alternative path even where the only valid input is a UK address. It's available as a primary path for international users and we don't ask for the country in advance. Thus we don't comply with the guidance. Would anyone like me to propose better wording for the guidance?
I propose removing:
- "Royal Mail does not need a county as long as the town and postcode are included. You should include an optional county text input so that people who do not know their postcode can give a valid address."
and replacing it with:
- "A 'county' field is redundant for UK addresses. Royal Mail (and other companies) do not use county to deliver mail."
Our current guidance
- introduces a condition (“as long as”) that doesn't exist in what Royal Mail said.
- contains the term 'should' which effectively contradicts Royal Mail.
- introduces a concept of 'valid address' but doesn't define what it means. If it means a letter without a county can’t be delivered then that’s not true. If it’s something else, then I’d like to know what it is.
Let's take an example (the GDS office). Plausible addresses using the county field include :
- 10 Whitechapel High St, London, Tower Hamlets E1 8QS.
- 10 Whitechapel High St, London, Middlesex E1 8QS
- 10 Whitechapel High St, London, Greater London E1 8QS
- 10 Whitechapel High St, London, London E1 8QS
I've heard it said that the county helps resolve the case where the entire postcode is missing but that isn't a reliable argument either. The example above becomes:
- 10 Whitechapel High St, London. which isn't difficult to resolve
In Bristol people will put 'Bristol', 'Avon' (which no longer exists), or even 'Gloucester' for example:
- 2 Redcliff Street, Bristol, Bristol BS1 6GR
It's possible county might be useful where the postcode is absent AND the postal town shares a name with a non-postal town AND the intended destination is the non-postal town. However, this looks like an edge case and neither this nor any other error scenario has been mentioned by Royal Mail or by the PAF advisory board (who made the decision to delete counties from the PAF).
The Royal Mail address finder doesn't provide county. See: https://www.royalmail.com/business/find-a-postcode
See also:
-
"There is no need to include a county name, your letters and parcels will reach your intended recipient without one." https://personal.help.royalmail.com/app/answers/detail/a_id/81/~/how-to-address-your-mail-%28clear-addressing%29
-
"But in terms of postal deliveries, the concept of counties is redundant. " https://www.formisimo.com/blog/uk-e-commerce-businesses-counties-are-gone-and-have-been-for-a-long-time/
-
https://en.wikipedia.org/wiki/Postal_counties_of_the_United_Kingdom
This may appear to be a small detail but addresses input is a very common pattern so it's worth debating opportunities for simplification. Happy to discuss this further.
@terrysimpson99 thanks for writing that up, we'll discuss it as a team and get back to you!
Thanks for the thorough write-up @terrysimpson99. We're going to investigate this, and other potential improvements to the pattern, as part of this story: https://github.com/alphagov/govuk-design-system/issues/1190
The pattern has a mismatch between visible and invisible field labels. We decided this isn't necessary because in our services we can use 'Address line 1', 'Address line 2' etc then 'Postcode'.
We try to keep the visible and invisible label the same unless there's a good reason otherwise. It's simpler for all parties in the product lifecycle because errors/inefficiencies in legacy invisible code have sometimes been causing problems without people knowing. https://adrianroselli.com/2017/02/not-all-screen-reader-users-are-blind.html
Does anybody else use: 'Address line 1' 'Address line 2' etc 'Postcode'