[Story] Provide phone extension for business point of contact

natalia-fitzgerald commented 1 month ago

Epic

Epic issue includes overview, complete list of user stories, technical and content requirements, user testing task ideation, and current design mock-ups.

https://github.com/cfpb/sbl-project/issues/150

User story

As a filer, I want to have the option to provide the phone extension for the business point of contact for my filing, so that the CFPB or other regulators can more easily make contact.

Acceptance criteria

[x] Given the user has reached the provide point of contact step, when they scroll to the point of contact form, then they can provide the phone extension for the business point of contact.
[x] Given the user has reached the point of contact form, when they go to enter their extension, then they are made aware of the number of digits they can include.
[x] Given the user has reached the point of contact form, when they choose not to enter a phone extension, then the system should allow them to continue without requiring an extension.
[x] Given the user is filling out the phone extension field, when the user inputs a numeric value between 1 and 9 digits, then the fields should accept the value as valid.

Technical tasks

Team members should create technical tasks and add links (below) prior to sprint planning.

UX

[x] Write initial user story
[x] Map story issue to the task analysis
[x] Validate user story
- Review against task analysis for accuracy and relevance
- Review for specificity and completeness
[x] Create a design mock-up for first set of acceptance criteria (Sprint 41)
[x] Create a design mock-up for second set of acceptance criteria (scheduled for Sprint 42)
[x] https://github.com/cfpb/sbl-ux/issues/14

Content

[x] Write content label and helper text for initial set of acceptance criteria
[x] https://github.com/cfpb/sbl-ux/issues/6

Front end

Back end

[x] https://github.com/cfpb/sbl-filing-api/issues/420

natalia-fitzgerald commented 1 month ago

@angelcardoz @dan-padgett The following reflect the designs we discussed for the phone extension.

Mock-up details

Phone number and extension fields appear side-by-side at all screen widths
Phone number field is 2/3 width
Extension field is 1/3 width
There is a 15px horizontal gap between the two fields
The extension field is optional
Numbers and letters are both acceptable
Helper text: Extension should be a number.
- This text suggests to the user that the intended purpose of the extension field is to accommodate extension numbers.
Currently the extension field (in development) allows for 255 letters or numbers

Potential enhancements (future sprint)

Limit the number of characters that the field will accept to something closer to what would be a typical extension length (about 11 letters/numbers max)
- This will require some backend, frontend, design, and content rework
- Limiting the number of digits will require a rewrite of the helper text which could also affect the mock-up.
- Currently I have a 2/3 + 1/3 layout but longer helper text that indicates a max number of digits could make the text wrap to the next line and break the alignment with the phone number field.

Desktop	Mobile

dan-padgett commented 1 month ago

Thanks @natalia-fitzgerald! Since this is just an addition to phone number, I'll check off the validation task.

natalia-fitzgerald commented 1 month ago

The front end has now implemented the design shown here. The backend and the front end have been set up to accept 254 max characters (letters, numbers, or special characters).

There is a product owner preference to stay as close to the stakeholder request as possible which is to add a field that's strictly for phone extension. There are concerns with accommodating 254 characters as it could lead to unintended consequences. One concern is that we open up the field to inadvertently collecting PII.

I have discussed with development and, in a future sprint, we can prioritize making a change to more tightly define the number of characters (11-15 or some number we define). This change will require backend, frontend, content, and design work.

@angelcardoz - Do we want to release this within this sprint the way we have it and then make an adjustment in a subsequent sprint?