Patterns into prototype: Find an address

[htmlandbacon]

What

Extract our our address lookup example into a stand alone prototype repo.

At a first pass this should work 'as is' with additional deployment instructions.

As part of the work we should also understand how might we...

1. use a mocked data to be more representative/avoid integration with external apis
2. use the internal DWP api

Why

This is the next step in helping how we can better leverage the prototype kit for repeating parts of a prototype.

Done when (first pass)

Views

• address input and search page
• list of search results page
• confirm your address choice page (if the search returns one address, then the list page is skipped)
• address manual entry page
• No address found page

Iterations from review

Dev:

• Namespace post/prefix 'dwp-find-an-address-plugin' plugin path to prevent clashes. Document standard to make this a consistent consideration across existing and future plugins
• Bug: lookup fails if return to main interface after manual address interaction
• Review semantic of address string into to a div, what's a more suitable element (this is inherited from the main pattern).
• Explore enhancement to formatting of address data (e.g. multiple line)
• Discover and fix any other a11y bugs
• Resolve validation messaging
• Add validation to manual address interface

Content

• Guidance to cover examples of exit path url absolute structure, with example path to illustrate
• Guidance to cover how pattern works with check answers including copy and paste partial as example
• Resolve validation messaging
• Review structure and clarity of guidance against a designer audience

Data

• use the OS api

Outcomes

• a releasable, installable find-an-address plugin package (first pass in Gitlab)
• a prototype showing the plugin working with real data (first pass in Gitlab)
• a slack trigger to request OS key (workflow)

Anything else

• Alternative formats files
• Example plugin
• Example prototype

[simoneduca]

Outstanding first pass work:

• start and exit url variable
• don't show the whole stack in the error if the API fails
• API key properly stored (env var)

Nice to haves, maybe

• consider an extra info page at the beginning
• OS API search criteria are too loose, i.e. single digit + postcode results

[martinwake]

Validation errors

To fix the immediate bug we should treat the two fields as one error, with the following validation error when blank:

Enter a postcode, the first line of an address, or both

Enter a postcode, a building number or name, or both

EDIT: validation error needs to match field label, which in this case is "Building number or name"

This looks like this and also like this.

It will need a bit of coding (for example where do we put the focus?) but seems like a better user experience.

cc @simoneduca

[martinwake]

Validation: manual entry

We agreed that on the manual entry screen the following fields should be mandatory (following the pattern shown in the example pizza delivery service):

• Address line 1
• Town or city
• Postcode

Validation errors when these are left blank are as follows:

Address line 1:

Enter the first line of the address

Town or city:

Enter the town or city

Postcode:

Enter the postcode

Notes

These validation errors talk about "the" address rather than "an" address as on the search screen. This is because we assume the user now has an address in mind.

They could be adapted to the context of a service, for example:

Enter the first line of your company's registered office address

or

Enter your postcode

@simoneduca @mitz-lad

[jonhurrell]

Pizza prototype example of find an address needs retiring.
See #640

[simoneduca]

Plugin published here https://github.com/dwp/find-an-address-plugin