Spec banner content type for VBA

[davidmpickett]

Description

Use the existing banner pattern with recent updates from VAMCs as a starting point. No situation updates. Review for any nuances of Regional Offices that might require special treatment.

Eng note: We do have a 'banner' content type that we should consider leveraging for this if at all possible.

Sharepoint specs

Acceptance Criteria

• [x] Draft document of content design
• [x] Review document with Product and Drupal engineering
• [x] Options reviewed with PO/PM
  • [x] #10241

[jilladams]

From UX refinement:

• If ROs don't have situation updates, do they need banners?
• Previously Dave Conlon has said: we removed them from VAMCs bc banners were abused but now: maybe we really want these.
• Let's use new & improved experience minus situation updates
  • Mirror updated pattern from VAMCs as a starting point

[swirtSJW]

We do have a 'banner' content type that we should consider leveraging for this if at all possible.

[davidmpickett]

Added new tab for banner to VBA Content Specs in Sharepoint

[davidmpickett]

Option 1 = Use existing Full Width Alert (machine name = banner)

• Pro: Any improvements would benefit VBA banners and main VA.gov banners
  • The way banners were built should not require the addition of a new build step in content build and should not slow down the content built.
  • When AP implements banners, it will account for VBA banners automatically (no extra FE work required)
• Con: This feature is owned by Public Websites, so we'd have to collaborate on any updates to ensure they make sense for all use cases.
  • e.g. Body is currently capped at 1000 characters, vs the 300 character limit we'd want.
• Current implementation of this content type uses URL targeting so having a national VBA banner would require:
  • A) namespacing that we might not get
  • B) adding additional targeting features which may be at odds with the core intention of this content type

Option 2 = Create new VBA Banner Alert content type

• Pro: Can be made to match specific needs of VBA product without consulting Public Websites
• Con: Introduces a 4th banner content type to the Drupal ecosystem
  • Will require a new build step similar to VAMC banner step which can significantly slow down the content-build
    • Yet another thing to cutover when moved to AP
• If we do the checkbox option for targeting, consider a select all option

Option 3 = Use existing VAMC Banner Alert with Situation Updates

• Pro: Any improvements would benefit VBA banners and VAMC banners
• Con: VAMC banners have several elements that are VAMC-specific, how do we preserve those while broadening the use to VBA?
• VAMC -specific components: connection to the System Operating Status page, situation updates, and Govdelivery integration

:edit: added 9/12/23

Option 4 Banner lives as a pair of fields on the facility. link to comment

Other notes:

Body vs field_body https://dsva.slack.com/archives/CT4GZBM8F/p1681494491912719

[davidmpickett]

Attaching a moment in time snapshot of the Spec document for those unable to get on Sharepoint VBA.Drupal.Content.Specs.xlsx

[swirtSJW]

@davidmpickett I added some pros and cons to your options so it is easier to see them all in one place.

[swirtSJW]

Questions:

• Are we limiting to one per?
• Do we need banners that span multiple ROs and can be controlled by higher ups?
• Do we need them to trigger content-release after hours.
• Does it need the same re-use restrictions that we use on VACMS banners to prevent re-use? (for reasons of record keeping rather than govDelivery)

[davidmpickett]

Meeting recording where review happened: https://civicactions.zoom.us/rec/share/JyUXRJ6Bv7Yu3X98DOycnykvxprX0JCUWzvxaRXymTYfrvtjozIeTLjNK-J53ENm.OEPd-H0eTd_0ZBCK?startTime=1692113813000 Passcode: 2EzB*^UG

[davidmpickett]

@xiongjaneg @mmiddaugh For end of Sprint 90 clarity, there will need to be more conversation & decisioning on the path forward before implementation would be unblocked.

Not sure how you want to handle tracking that (leaving this ticket open / having a new ticket / updating the implementation ticket ).

[xiongjaneg]

@davidmpickett I think you mentioned this potentially impacting both Public Websites and CMS teams. Is that correct? If so, I can bring it to our next three-person PM sync.

[mmiddaugh]

@swirtSJW @davidmpickett Given that the existing VAMC banner has specific behaviors/features designed for VAMC use (such as the connection to the System Operating Status page, situation updates, and Govdelivery integration)...

• Is it possible to update it to make it compatible with other facility types?
• If so, what would be the pros/cons?

[davidmpickett]

@swirtSJW @davidmpickett Given that the existing VAMC banner has specific behaviors/features designed for VAMC use (such as the connection to the System Operating Status page, situation updates, and Govdelivery integration)...

• Is it possible to update it to make it compatible with other facility types?
• If so, what would be the pros/cons?

I added an option 3 to the comment above to house this information

[davidmpickett]

@davidmpickett I think you mentioned this potentially impacting both Public Websites and CMS teams. Is that correct? If so, I can bring it to our next three-person PM sync.

Option 1 would require coordination with Public Websites, but not options 2 & 3. The CMS team will need to review the proposed implementation via their Collab Cylce regardless of which option we choose.

[jilladams]

https://dsva.slack.com/archives/C0FQSS30V/p1692195315879269?thread_ts=1692046861.455919&cid=C0FQSS30V Next step: Jane to review options with Mike / Wes.

[xiongjaneg]

@davidmpickett RE Option 1, Wes' opinion is that the cons of coordination outweigh the pros. I'll run the other options by Mike for CMS input.

[xiongjaneg]

@productmike Two options for VBA banner for your feedback per my Slack

Option 2 = Create new VBA Banner Alert content type Pro: Can be made to match specific needs of VBA product without consulting Public Websites Con: Introduces a 4th banner content type to the Drupal ecosystem Will require a new build step similar to VAMC banner step which can significantly slow down the content-build Yet another thing to cutover when moved to AP If we do the checkbox option for targeting, https://github.com/department-of-veterans-affairs/va.gov-cms/issues/14752

Option 3 = Use existing VAMC Banner Alert with Situation Updates Pro: Any improvements would benefit VBA banners and VAMC banners Con: VAMC banners have several elements that are VAMC-specific, how do we preserve those while broadening the use to VBA? VAMC -specific components: connection to the System Operating Status page, situation updates, and Govdelivery integration

[swirtSJW]

Option 3 is a lot to override unless VBAs want to also use govDelivery for the possibility of sending mass emails to subscribers.

[xiongjaneg]

From Mike: Difficult to balance the business need, LOE and risks of each reading through the comments, but I would say generally speaking I'd veer away from any additional dependencies on the content-build process at this point. Kinda like building a sandcastle near the water line. Ultimately, if the other options come close to delivering the same value as option #2, I'd pick those purely from a stability perspective.

[mmiddaugh]

FYI @xiongjaneg @davidmpickett I will be back with a decision a meeting late next week with a group of VA POs (to get higher level context and visibility)

[xiongjaneg]

Idea: What if we use the existing VAMC status block and render it visually as a banner for MVP? Assumptions: not using GovDelivery, flat structure, would elevate prominence and visibility, add a call to action if needed (e.g., message exceeds length). This might also be leveraged to be used for both a status and a banner, e.g., COVID default text plus status

Rendered on the front end as a banner visually but not as a separate field. Post-MVP would be a separate field type.

Does this create an inconsistency in banners as a user experience? This difference in experiences by product might need content review.

Would this only have to appear on a facility's page? After MVP, what are the other pages going to be? Will this banner need to display on subpages later? This is a consideration, especially regarding being content on the Facility content itself. E.g., if the next page is Events, a banner might not be important to show on the Events page. This is not necessarily a blocker, just might require more work if the decision is to show the banner on subpages.

Is there a need for a higher level of hierarchy for push to multiple facilities? Not currently. Instead, full-width alert could be leveraged for that example.

[xiongjaneg]

Facility operating status is included in MVP. Is a banner a part of MVP? Yes, especially if it's for emergencies and we're not building something new.

[xiongjaneg]

@xiongjaneg to add this new information for option 4 (having the fields live on the Facility content type) in this ticket and add to subsequent Drupal ticket.

[swirtSJW]

Option 4 Banner lives as a pair of fields on the facility.

A simple option exists where we could have a facility have a pair of fields (field_banner_title and field_banner_content) that could drive the banner for that facility.

Pros

• Simple to implement in CMS and FE
• Simple for an editor to unstand
• Simple governance... they only get one.
• Multi section banners would have to use the Full width alert content type. Not pleasant if we do not namespace the VBA facilities' path like /vba/vba-facility-name

Cons

• No possibility of having a banner appear on multiple (see last point under pros)
• Could not have the node expire if we want banners to auto expire. (would need a more complicated solution for this)
• More difficult if there are pages "under" the facility that we would also want the banner to appear on.

[xiongjaneg]

@mmiddaugh Will add to our 1:1 meeting

[xiongjaneg]

Closing as options will be discussed by PO/PM today

[xiongjaneg]

For option 4, do we have to create new fields? Can we leverage existing fields (like those used in operating status)?

[xiongjaneg]

@swirtSJW For option 4, you seem to reference two new fields. In a prior meeting, we talked about leveraging existing fields, like operating status. Are there pros/cons to new fields versus existing fields?

[mmiddaugh]

My understanding of option 4 was that we could reference the existing operating status+ operating status - more info fields and simply render the content visually as a banner component, consistent with the style guide. This would allow us to implement quickly using existing fields and return later to the bigger conversation about banners/alerts.

Screenshot

[Private Zenhub Image](https://api.zenhub.com/attachedFiles/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdEtaIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--87b72f31f82f1d8793ac18edc8e9bdc72752810a/image.png)

[davidmpickett]

My understanding of option 4 was that we could reference the existing operating status+ operating status - more info fields and simply render the content visually as a banner component, consistent with the style guide. This would allow us to implement quickly using existing fields and return later to the bigger conversation about banners/alerts.

Screenshot

While this might seem like a quick fix, I believe it would actually create more complexity. These components have different options from a FE perspective (e.g. banners can be dismissable, whereas operating status isnt) and we'd have to wire up additional logic that would later be removed. Keeping these as separate fieldsets on in the CMS allows FE to use existing templates because all the info is the structured the same as it is elsewhere on the site.

Additionally from a content perspective these two feature shave subtlety different use cases and implications for the larger product landscape (facility locator, Lighthouse, etc) that would need to be considered if they were tied together here.

That said, option 4 is a great idea overall. For all the reasons @swirtSJW outlined.

[swirtSJW]

@swirtSJW For option 4, you seem to reference two new fields. In a prior meeting, we talked about leveraging existing fields, like operating status. Are there pros/cons to new fields versus existing fields?

I don't think we should leverage existing fields. The intent is different and the functionality would appear more like magic than something intentional and understandable. (when systems become less transparent to editors, they become harder to understand)

I did initially propose that we could use the supplemental status as a possibility, but backed away from that idea after pondering it a bit more.

[swirtSJW]

@mmiddaugh Dave Pickett answered this ^^ well. Sorry in my initial processing of this on the call the other day, I suggested supplemental status as an a possible solution. But after pondering it a bit more, I backed away from that idea. See my answer to Jane above ^^

[xiongjaneg]

Revisit the two field names @swirtSJW suggested above

Also consider dismissibility

[xiongjaneg]

@mmiddaugh Please see Steve's answer to your question above.

Do we have enough info to move ahead with Option 4? If so, that will unblock #14700 for next sprint.