Open timpaul opened 4 years ago
I'd like to see all the address lines to have visible labels. Visible labels are especially important to users of voice control assistive technology as it means they can go directly to an input. Additionally as quite often beyond the first line, address line fields are optional, they require this information to be exposed as part of a visible label. Currently the pattern has visibly hidden address fields and this causes confusioin in teams implementing this pattern.
I'd suggest updating this pattern to show the second address line marked as optional, but all having visible labels.
We use: 'Address line 1' 'Address line 2' 'Address line 3 (optional)' 'Address line 4 (optional)' 'Postcode'
This has several advantages:
Could this exploration include improvements to capturing non-UK / international addresses please? (I've already reviewed the thread at https://github.com/alphagov/govuk-design-system-backlog/issues/31). My team at HMRC are exploring options on using third party APIs to improve the quality/consistency of non-UK / international addresses. Thanks
One of the advantages of the above 'Address line 1' format is it works equally well for UK and non-UK addresses. The only issue is with the postcode field. You have the choice of:
Forgive me if this is a ridiculous solution, but what's the disadvantage in just using a <textarea>
for this?
I'd still lean towards asking for the postcode (and country, if required) separately as they'll probably undergo validation.
Edit
_While thinking about this, autocompletion seemed like it might be problematic but it's actually covered by autocomplete='street_address'
_, which is described by MDN as:
A street address. This can be multiple lines of text, and should fully identify the location of the address within its second administrative level (typically a city or town), but should not include the city name, ZIP or postal code, or country name.
I'm leaning towards using a similar pattern to that suggested by @peteryates above.
Our current pattern:
Our users are admins entering the addresses of trainees. Unlike users entering their own addresses, they're entering addresses that are already written down - copying from one system to another. We're finding that the majority of their other systems store the address as a single block with postcode. So to put in to separate fields as the design system recommend means many more copy and paste operations. Alternately they paste the entire address in to street line 1 - and then either cut bits out of it, or don't notice, and then things go wrong with the data.
It's really frustrating that there is no workable address capture when you don't know where the user lives in the world. It's all well and good offering a postcode lookup for UK users, but an overseas user is faced with either a multiple field entry asking for county and postcode (?!?), or a textarea which then doesn't allow you to target and use any part of the address later in a service, such as sending data to Notify.
On a past project we've used the postcode lookup pattern with a 'Enter your address manually' or 'Enter an overseas address' link which takes you to an address capture page with simple multiple text entries e.g. Line 1, Line 2, Line 3, Line 4, Line 5, Postcode (if UK), Country (if not UK) to try and cover all bases and still allow the data to be manipulated if necessary. There's other examples of services that have had to try and work round this issue with their own design. Surely we can come up with some sort of standard pattern that ends us having to use sometimes contradictory and often unworkable existing patterns?
What
Investigate whether there are improvements we can make to the address pattern.
Why
We've had a couple of questions from users about our address pattern recently. It's been a while since we reviewed it and it's a very popular guide.
More detail
This card is to do a 2 day investigation into the following:
1) whether or not the 'county' field can safely be removed in all cases 2) whether we could provide a coded example of a postcode lookup 3) whether there's any other useful feedback on the backlog for this pattern
The following are a good starting point for the investigation:
Who needs to know
Chris T