AS A UXer designing interfaces for the VA.gov CMS
I NEED to be able to standardize and centralize repeated patterns across multiple content types
SO THAT VA.gov CMS editors get the best possible experience every time
AS A Drupal engineer developing products on the VA.gov CMS
I NEED to reduce unnecessarily duplicated fields
SO THAT the code base is easier to maintain
The Problem
We have multiple instances in Drupal where we want to provide content for a banner alert on the Front End.
Full width alert
VAMC System Banner Alert with Situation Updates
VBA Facility
Vet Center Facility (soon)
Right now all of those Content types have multiple fields that control the banner, but they are separate instances of fields and may have different formatting (widget settings, help text, etc.) For example, one of the properties of the banner alert is whether or not the user can dismiss the banner. Despite this being the exact same functionality on the FE, it is currently described in three different ways in Drupal.
VBA Facility (best UI)
Full Width Alert (okay)
VAMC System Banner Alert with Situation Updates (bad)
The Opportunity
There are enough differences and nuances in the way banner alerts work on the different products that we do need separate content types. However, some of the fields (like dismissibility) would benefit from standardization.
In other places in the CMS, we have started using Paragraph Types to have interface consistency for repeated groups of fields. However, Paragraph Types have some weaknesses, so the Custom Field module may be a better approach.
Instead of just copying multiple fields for Vet Centers, we could use this as an opportunity to harden them into a new MEGA Field that includes multiple sub-fields.
We could then implement the new Banner Alert MEGA Field on Vet Centers as a proof of concept.
Once that's successful, stub tickets for migrating the other content types with banners to adopt the MEGA field.
Description or Additional Context
Inspired by #16149
Steps for Implementation
[ ] Review technical feasibility of implementing custom Drupal module
[ ] Basic content modeling of which Banner Alert fields would be hardened into MEGA field
[ ] Rough outline of implementation steps involved including LOE
[ ] Document the above three things in a proposal (can a comments on this ticket)
[ ] Proposal is brought to Product for review and decisioning
Per conversation in refinement today, I'm moving this to backlog. This would be a future exploration rather than something we do before Vet Center implementation.
User Story or Problem Statement
AS A UXer designing interfaces for the VA.gov CMS I NEED to be able to standardize and centralize repeated patterns across multiple content types SO THAT VA.gov CMS editors get the best possible experience every time
AS A Drupal engineer developing products on the VA.gov CMS I NEED to reduce unnecessarily duplicated fields SO THAT the code base is easier to maintain
The Problem
We have multiple instances in Drupal where we want to provide content for a banner alert on the Front End.
Right now all of those Content types have multiple fields that control the banner, but they are separate instances of fields and may have different formatting (widget settings, help text, etc.) For example, one of the properties of the banner alert is whether or not the user can dismiss the banner. Despite this being the exact same functionality on the FE, it is currently described in three different ways in Drupal.
VBA Facility (best UI)
Full Width Alert (okay)
VAMC System Banner Alert with Situation Updates (bad)
The Opportunity
There are enough differences and nuances in the way banner alerts work on the different products that we do need separate content types. However, some of the fields (like dismissibility) would benefit from standardization.
In other places in the CMS, we have started using Paragraph Types to have interface consistency for repeated groups of fields. However, Paragraph Types have some weaknesses, so the Custom Field module may be a better approach.
Description or Additional Context
Inspired by #16149
Steps for Implementation