[EPIC] Standardize phone numbers on Support Services

[laflannery]

Status

[2024-08-20] [Dave] Created separate tickets for Vanity and International phone numbers
[2024-07-12] [Fran] 'Call us links' have NOT been updated to va-telephone components and we cannot stop using custom analytics on them currently. We need to update CMS phone number entry to standardize, then update FE to use DS component, in order to enable that analytics update.

Description

The Support Service content type is an older content type. The way phone numbers are created in Drupal on this content type, and the way those phone numbers are presented in the VA.gov front-end does not match current standards or use current widgets / design system components. The va-telephone DS component and the applicable props now do a lot of the display and functionality that the Support Service CMS fields are manually doing.

We would like to update this content type to use modern standards.

Where Support services appear

CMS BE usage:

• Support Service is a content type: content form.
• Support services content model docs
• The Related Office field is used by the FE to build content relationships in FE templates.

Screenshot

VA.gov FE:

The Related Office field on a Support Service is used to tie it to other content types / templates:

1. On Benefit Hub Landing Pages: right sidebar, "Ask questions" panel. The Offices field is used to create the relationship between the Hub and the Support Service. e.g. Education & training
2. Resources & Support detail page: Need more help panel at the bottom of the page, e.g. Login.gov R&S page

Screenshots

Considerations for updates:

Drupal

• [MUST] update the Phone Paragraph type with new options for vanity and international numbers

• [MUST] Update Support services to use the phone paragraph legacy widget, to standardize the entry for this phone number field to allow digits-only phone, e.g. 711, 918-781-5678, 877-222-8387

  • Data migration: There are ~17 existing support services (not all are phone #s, some are links) that will need migration to the new phone model. Current usage is to enter the entire visible label , e.g. TTY: 711, +1-918-781-5678, 877-222-VETS (8387). We can work with CAIA to manually update these to the new pattern.

• [CONSIDER] Add Facility services "Type" field to Support Services. It includes options for Phone, Fax, SMS, TTY

  • When the editor chooses a type, data is able to be passed to the FE which can then be used to set the appropriate prop for the component (e.g. tty, sms)
  • This also allows for conditional fields in the CMS
    • When "Phone" is chosen an "Extension" field displays but does not when the other options are chosen
  • [CONSIDER] Add 2 options to Type field for FE component scenarios:
    • Vanity - If selected this should trigger an conditional field for the vanity info
    • International

• [CONSIDER] Link updates: The link is no longer necessary for phone numbers, but is needed for scenarios where a Support Service is not a phone number. Is there a way to indicate which type of support service is being made / if a link is necessary, and conditionally show it only when it's needed? (Example usage)

FE

• [MUST] Update templates where the Support Services number appears to:
  • Use the va-telephone component
  • Pass in phone numbers, extensions accordingly
• [MUST] Update FE template to use Name of support service existing field for the message-aria-describedby prop

Vanity numbers

The GIBILL number is an exception: Link = tel: 1-888-442-4551; Phone Number = [888-GIBILL-1 (888-442-4551)](tel:888-GIBILL-1%28888-442-4551%29). This number is not handled by the va-telephone component. Has been ticketed to the DST: department-of-veterans-affairs/vets-design-system-documentation#2531.

This epic is essentially blocked until the parent epic around Vanity number support has been addressed both in Drupal and by the DST.

[omahane]

The only place that we have something like what you're describing for the phone number at present is in Service Locations, using the field_phone (a paragraph type).
https://prod.cms.va.gov/node/add/health_care_local_health_service

[randimays]

FE QUESTION: Should they not be entering the dashes between the numbers either? Should be be validating and/or providing help text against that or is that ok and the component can handle those?

The web component doesn't like dashes. In many cases we're having to remove them in content-build / the FE

Could we make changes now, update the CMS and the front end but allow this GIBILL number to not use the component?

We can make exceptions in the code for this type of phone number 👍🏻

[FranECross]

@davidmpickett @dsasser @jv-agile6 I feel like this needs some review/love love outside of a refinement meeting to determine the best approach. Would all/some of you be the ones to do that? BTW this ticket is currently blocking implementing the 'va-telephone' component. Thanks! (I'm scooting it back to the backlog. cc @Agile6MSkinner

[davidmpickett]

This sounds like the exact same work as we will be doing in the Q3 Phone Number effort.

• Migrate existing phone numbers from phone field to phone paragraph type
• Update graphql query
• Remove old field after prod verification

[laflannery]

This requires more work that the existing phone pattern does not support:

If this pattern was considered a good option, we could consider adding additional options so that this could cover all scenarios needed for the component:

• Vanity - If selected this should trigger an conditional field for the vanity info
• International

[davidmpickett]

Got it, so we'd likely need to update the Phone Paragraph type with those new options and then implement

[davidmpickett]

@laflannery I took a first pass at adding task lists here. Would love a sanity check.

One of the first steps would be defining the exact requirements for the Vanity and International phone number types. Do you feel like you have the info to specify those? Or should we make a little spike ticket for you and I to collaborate on that?

[Agile6MSkinner]

Going to put this in a future epic for vanity/international, etc.

[jilladams]

Took a look at this ticket today since DS is about to update the va-telephone component for int'l numbers.

FYI: There are a grand total of 17 published Support Services.

• 1 in April 2024
• 1 in June 2023
• 3 in Oct 2021
• All the rest in 2019

I am fishing around based on the Support services content model docs and am having a hard time finding where any of these are actually used in modern content.

Which is all to say: all this work on behalf of Support Services seems like very low priority, and we should check first with CAIA about when / why they choose to use SS before we try to prioritize this.

[laflannery]

@jilladams These numbers are used in a couple places (It's above in the Additional info section of the ticket description):

VA.gov FE usage: These phone numbers are used in the right column of benefits landing pages, example: Education & training as well as in the Need more help at the bottom of multiple resources pages

[jilladams]

AH! Thank you, Laura.

@FranECross FYI: Updated this ticket today to reflect the fact that it's actually an epic, and is a child of the greater #19121 International / Vanity effort. Put task lists that used to be in ticket body into tickets that are now children of the epic. It'll be PW work if/when the bigger picture Vanity / Intl work & DST blockers are gone.