search

department-of-veterans-affairs / va.gov-cms

Editor-centered management for Veteran-centered content.
https://prod.cms.va.gov
GNU General Public License v2.0
99 stars 69 forks source link

[EPIC] Alternative VAMC banners that do not use content-build #19302

Open jilladams opened 1 month ago

jilladams commented 1 month ago

Background

https://dsva.slack.com/archives/C0FQSS30V/p1727108182414679

VA would urgently like to pursue methods for getting critical content out to production faster, for things that should not / cannot wait for content-build when it's having problems.

This was introduced at the end of Q3 2024, and will be a Q4 priority.

Scope

MVP: VAMC banners, not including situation updates

Additional phases can be scoped when we arrive at a methodology to achieve MVP.

MVP is not for full-width banners first, but for VAMC banners without situation updates. They are similar, but different.

These ride along with the header:

Image

High level work required to complete the epic

Decision log

timcosgrove commented 4 weeks ago

Just to put it out there: we have a lot of the pieces of a solution for this in Next Build / CMS already, and it would not require using Next Build:

The basic work would be:

Or, use parts of this. At a minimum, it feels like the API endpoint already exists in CMS and replicating it would be wasteful, unless there are requirements for this effort that are fundamentally incompatible with the existing endpoint.

dsasser commented 4 weeks ago

Just to put it out there: we have a lot of the pieces of a solution for this in Next Build / CMS already, and it would not require using Next Build:

The basic work would be:

  • wire up the existing CMS endpoint to vets-api so that it data can be retrieved in realtime
  • move the banner components to vets-website
  • set up both Content Build and Next Build to use these components and endpoints

Or, use parts of this. At a minimum, it feels like the API endpoint already exists in CMS and replicating it would be wasteful, unless there are requirements for this effort that are fundamentally incompatible with the existing endpoint.

A Slack conversation around this can be found here.

jilladams commented 2 weeks ago

Meeting with Bryan, Eli, Christian and Laura / Michael / me.

UX concern

The banners code in FE lives in content-build completely. We originally planned to introduce a static content-build element that vets-website could hook into to pre-load content. But: everything in VAMC views is only content-build in the static pages. We don't have a means to inject vets-website. This would require the client's browser to send a call for the JS to get the banner. That means: lag time for the user while the browser fetches data. The entire page has to render first, then the JS call to return the banner. Time required to make that call depends on the user's browser and internet connection, so timing may vary. Could be up to 5 seconds on bad wifi / mobile. UX for the banner snapping in will be a jump. (Sort of like what we see on TeamSites with the injected header showing up, when it's slow.)

Might be ok though

Per Eli: in our current structure, this UX flash after JS loading is not out of the ordinary. In content-build: create a data element that React looks for from vets-website and loads itself into. Those asynchronous calls are unavoidable within our structure. So: this UX issue might be par for the course / not be the worst thing, given the reasons for this project.

Also: when vets-website does load in async, it will bring with it all of the DST components / dependencies.

Per Michael: migration to AP will affect this once we move VAMCs to AP. Alternative is a near-term fix to honor the needs, so we can think of it as stop-gap. And then it's probably ok if it's not perfect. (Next Build will still be making an asynchronous call but it’ll be to Drupal as opposed to vets-api and that still has flashiness.)

UX question to confirm: skeleton spaces

Should we create a "skeleton space" to hold space for this banner, to prevent the jump down when it loads. No, we think, and need to confirm with @thejordanwood . So far: that's an antipattern for VA. Also: it would be more frequent to hold space for a banner that doesn't exist / have to disappear it, than it would be to not hold space, and have the page jump down when banner loads. (Also the jumping down works in favor of the banner intention, to get user's attention.)

Facts of deploy

Content release: builds main every hour or on certain types of content changes, including VAMC BwSU. (Content-build rebuilds what is main from code, daily. SO: templates daily; data hourly or more.)

thejordanwood commented 2 weeks ago

I agree that we don't need to create a skeleton space for this banner. Having the page jump down when the banner loads is currently the existing behavior for VA banners and can be seen with the natural disaster banner that's on the homepage right now (example).

cc: @jilladams @davidmpickett

mmiddaugh commented 1 week ago

Update 11.5.2024