VA Police data page content model

[xiongjaneg]

User story

• As a Veteran, I want to know police activity that has occurred at my VA Medical Center facility.
• As a VAMC editor, I want to add information to the police data provided for my VA Medical Center facility.

Background

Legislation passed in 2022 requires VAMC websites to include data about VA police activity.
Deadline: One year after the enactment (December 29, 2022), the Secretary shall report to Congress on the implementation of all provisions of amendments to 38 USC 902, which includes the publishing of arrest and ticketing data.

Initiative Brief: VA police transparency (WIP)

Assumption

The Police Transparency MVP page will be built in Drupal with police data provided by a vendor added by the front end. The Drupal page may consider future uses by VAMC editors, but for the MVP editors will not be editing the page.

Working document

https://app.mural.co/t/departmentofveteransaffairs9999/m/departmentofveteransaffairs9999/1698092447003/c969debf289d4e43e3cdd293d90053c2c137c338?sender=u9c899abc4fe36c9a698b1647

Acceptance Criteria

• Review and respond to CAIA's questions
• Content models that covers external data sources, Facilities backend products, and VA.gov front displays are sketched out in Mural
• Address Police vs Policies feedback via menu order
• Address granularity feedback via split of system page and facility data pages
• The models are reviewed with product & engineering to evaluate pros and cons
• Possible iteration within Mural
• After a decision is made about overall approach, modeling can move into more detailed specification of content fields Moved to subsequent ticket

[davidmpickett]

Initial mural for starting to think through - https://app.mural.co/t/departmentofveteransaffairs9999/m/departmentofveteransaffairs9999/1698092447003/c969debf289d4e43e3cdd293d90053c2c137c338?sender=u9c899abc4fe36c9a698b1647

[swirtSJW]

The mural helps a lot. Nice work. The only variant I wasn't seeing is this possibility

Which might solve the menu problem (not just the code.. but how the menu would look).

[xiongjaneg]

From Michelle and Jane conversation: Our preference is for the page at the facility level - on the Mural, VA Police (page per facility). This would need to be linked from elsewhere in the Facility, for example a service accordion. This would eliminate the possibility of a link from the left navigation that only exists at the system level.

[davidmpickett]

From Michelle and Jane conversation: Our preference is for the page at the facility level - on the Mural, VA Police (page per facility). This would need to be linked from elsewhere in the Facility, for example a service accordion. This would eliminate the possibility of a link from the left navigation that only exists at the system level.

I do want to flag a risk to this approach. Having a page that is not reflected in the sidenav is in violation of Platform's URL standards. They already have an outstanding ticket about our Billing and payment and Medical Records Office pages violating this principal. department-of-veterans-affairs/va.gov-team#54291

[davidmpickett]

Noting that L4 pages are not supposed to show the sidenav at all, so that might be part of the solution here

[mmiddaugh]

Thank you for flagging the risk (and the related outstanding ticket).
We should be covered under the L4 guidance.

[jilladams]

From planning:

• @mmiddaugh wants to put something in front of the Office of Operations, Security, and Preparedness, and CAIA, to review.
• @davidmpickett to think about that during this ticket, and get review from Michelle & @xiongjaneg , sync or async, early in Sprint 96.
• Also need to specify how which data makes it into the CMS pages up front, since Editors won't be doing the data entry.

[davidmpickett]

• ABOUT [VAMC SYSTEM]
  • About us
  • Work with us
  • Contact us
  • Policies
  • VA Police
  • Programs (if enabled)
  • Research (if enabled)

[davidmpickett]

Summary from conversations with @swirtSJW and @eselkin about possible paths forward for creating pages per facility. There is still some more work to do to fully understand these options (Eli has some digging to do), but wanted to document them for the rest of the team to start absorbing.

Option 1 - Single Page App - SPA (ala Income Limits)

• Each facility page has it's own URL path
  • (system)/va_police/(facility)
• Each police page has full unique breadcrumbs for MVP
• No side navigation displayed while on Police pages (system or facility) for MVP
• May have additional accessibility review compared to widget
• Facility pages don't have link in sidenav, just system page

Option 2 - Embedded widget (ala Access to Care data)

• Each facility page is actually a query parameter, not a true URL path
  • (system)/va_police?=(facilityid)
• No breadcrumbs on facility pages for MVP
• Side nav could be displayed, but it would just always show the system-level page selected, would not update per facility page
• Facility pages don't have link in sidenav, just system page

Option 3 - Drupal creates page per facility

• This would mean adding not 1, but 2 new content types
• 1400 new nodes instead of 140
• This would be the only way to have both system and facility pages in the side nav (for MVP)
• This is only included here as a last resort in case Eli find that options 1/2 couldn't reliably create pages per facility (after Drupal creates System page)

Slack threads

• https://dsva.slack.com/archives/C0FQSS30V/p1698352232159639?thread_ts=1698263874.810089&cid=C0FQSS30V
• https://dsva.slack.com/archives/C0FQSS30V/p1698354948984699

[davidmpickett]

Snapshot of content model. I've taken this about as far as I can with existing information

[jilladams]

We will need a new CAIA IA review to inform the decision here?

[davidmpickett]

@jilladams Our meeting with CAIA isn't until next week, I will walk them through our proposal at that time. I have been responding to their questions and updating them on our progress on their ticket

[jilladams]

Ugh, sorry, I keep getting mental wires crossed on IA state of affairs between VBA and Police. Thank you for clarifying for probably the 3rd time this week.

[laflannery]

FWIW my initial thoughts:
Option 1

• Overall I don't mind this
• Each page will need a unique <title>. it should follow the same pattern that the other pages within the VAMCs follow H1 | VAMC System Name | Veterans Affairs
  • Randi is doing this dynamically on Income limits and PACT because of where things come from (vets-website vs content-build I believe). This solution was fine for IL but I think would cause some issues for Police because it loads just a second or 2 after the page does. So if we do build this the same way, yes it will definitely need to be tested
• I like that the subnav will not have duplicate facility links now, so that's a Pro as far as I'm concerned
• IL hasn't been an issue with the way it's built, I have seen some things occasionally with loading but because of how we are forcing focus and the fact that it's not a "browsing" page, it's generally not an issue.
  • These pages are definitely pages where the user is going to be going between different areas more frequently so I can see that potentially being an issue

Option 2

• I don't particularly like this
• I don't like that there isn't a clear indicator of where the user is in the page hierarchy, no breadcrumbs and no accurate subnav

Option 3

• I know this is a last resort
• Obviously the accessibility would be a non-issue
• I still have weird feelings about duplicative links in the subnav (I know they are hierachical but it's still hard to understand I feel like)

[swirtSJW]

Related to option 2. The in-page widget could alter breadcrumbs and menus if it had to. We just are not suggesting that possibility for MVP as time is a limited commodity.

[swirtSJW]

Also for Option 2

(system)/va_police?facility=(facilityid)

This could be more human readable by using the facility common name instead of the id.
(system)/va_police?facility=bellmont-county-va-clinic

[jilladams]

From scrum:
Option 1:
Eli did some digging re: whether it’s possible for left nav to exist in a single page application. So far: no. (SPA = vets-website) We cannot initiate a React single page app within an existing page, so far as we can tell.

Option 2
Could have System level with Facilities below it in the sidenav, but might not be worth doing for MVP. Could be done with Menu items + self-contained widget. Was a CONSIDER from design intent.

CMS view can be created that has System IDs with nested IDs of Facility pages. This would provide the necessary data to the FE. KISS can then curl for this data that associates Facility with System. This would happen at content-build time.

Option 3:
The only option that will allow a nested sidenav showing all Facilities.

[thejordanwood]

My thoughts:

Option 1

• I prefer this option.
• I feel uneasy about pages not having breadcrumbs, so if this is the option that can give us breadcrumbs then this is my preference.
• If no side nav is present, we can use breadcrumbs and add links onto the pages to give users a way to navigate back.

Option 2

• I don’t like this one
• I agree with Laura that no breadcrumbs and no accurate sidenav is a bad combo.
• If we went with this one, we need to ask IA about this to make sure this design will pass before we take it to Midpoint Review.

Option 3

• I’m okay with not having the nested sidenav showing each facility. We don't need to go with this option.

[mmiddaugh]

Are the only objections to Option 2 related to side nav and breadcrumbs?
-> If so, Steve commented that the in-page widget could alter breadcrumbs and menus if it had to (post-MVP)

[davidmpickett]

Are the only objections to Option 2 related to side nav and breadcrumbs? -> If so, Steve commented that the in-page widget could alter breadcrumbs and menus if it had to (post-MVP)

@swirtSJW @eselkin To make a final call on Option 1 vs Option 2, it might be helpful to have a clearer articulation of which aspects of each approach are permanent vs just for MVP.

Most of the downsides of Option 2 are in the "Just for MVP" category but that doesn't mean that Option 1 necessarily has downsides that are permanent. What long-term structural decisions are we making with SPA vs Widget that can't be addressed via iteration?

[laflannery]

I am also very wary of the lack of breadcrumbs/sidenav - I believe this is going to get flagged as launch-blocking at Collab Cycle, in which case it couldn't be omitted from the MVP and would have to be resolved. Examples of tickets where something like this was labelled as launch-blocking.

I do think that if this is being considered, we need to run this by IA sooner rather than later

[jilladams]

Mid-sprint: CAIA meeting will help determine next steps.

[davidmpickett]

Added a little more detail to the content model to reflect discussion about content drafting from meeting today

[mmiddaugh]

Recording @eselkin's feedback about the level of effort here
Both the SPA and the widget require about the same amount of work. The additional feature available in the SPA of having the breadcrumbs makes it a little more effort, but probably not much more. But the SPA is more navigable because it has those breadcrumbs and in MVP the widget would not (nor would the widget have working facility links in the side nav).

In terms of total length of effort to produce the system page, probably less than 1 sprint (though some of that is dependent on a CMS view being produced first to provide system/id/url/name and nested facility/id/name). This CMS view will also help in producing the breadcrumbs. The individual facility pages would probably take 1 sprint or 2 if problems arise. There is a 1 sprint before any of this of converting whatever they give us on the 9th to whatever we need for the facility pages.

[jilladams]

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

Summary of conversation just now with Mikki and Dave P - we're going with a version of Option 2 - single app page using a query to dynamically present facility level data (preferably by passing a query so the page can default to data for the facility the user has come from). This allows us to avoid blowing out the node count and creating duplicate high level police content while leveraging left nav, breadcrumbs, and URLs. We'll need to think through the accessibility points Laura made earlier related to page title and live regions.

[davidmpickett]

@mmiddaugh @xiongjaneg One lingering question here. For MVP do we need to add a link on each VAMC facility page that points to the associated facility query on the System Police data page?

If so, here's a quick mock-up of what that might look like: https://app.mural.co/t/departmentofveteransaffairs9999/m/departmentofveteransaffairs9999/1698092447003/c969debf289d4e43e3cdd293d90053c2c137c338?wid=0-1699292283883

Previous conversations around this involved trying to add that via a Prepare for your visit / Security accordion, but that is not a viable approach for MVP since those accordions are blobby.

[davidmpickett]

@jilladams @xiongjaneg Moving this to PO review. This ended up being larger than a 5 so the last AC was out of scope for this sprint:

• After a decision is made about overall approach, modeling can move into more detailed specification of content fields

Rather than leaving this ticket open, I'd suggest just updating the Drupal tickets with time for me to assist with spec ala #15710

[xiongjaneg]

#15710 updated with the last AC, that can be struck out from this ticket

[mmiddaugh]

For MVP do we need to add a link on each VAMC facility page that points to the associated facility query on the System Police data page?

We don't need to do this centrally. We can ask editors to add the link (and an accordion, if needed) or update existing Prepare for your visit content. Facilities which already have a police page will need to archive the existing content (or ensure they are not duplicating content).

[jilladams]

Sounds like this is officially wrapped -- closing based on the notes, but please reopen if we missed anything here.