Resources and Support: allow editors to choose what categories are shown on main landing page

[aklausmeier]

Status

[2024-07-29] [Fran] Amanda and Michelle weighed in after Daniel presented to options. The decision was made to go with the hard-coded option. Fran updated the ticket. [2024-07-25] [Daniel] Daniel unpacked the engineering aspects and discovered some risks and options [2024-07-24] [Fran] Dave Picket indicated that this needs to go through refinement. I've removed the 8 points and added the Needs refining tag. [2024-07-23] [Fran] Amanda mentioned that a decision needs to be made as to how this will be implemented. I commented with questions to Dave Picket and Daniel S. [2024-07-23] [Fran] Per Michelle M, targeting Sprint 9, if possible.

Background

With the new Family Member and Caregiver Benefit Hub being published, the Resources and Support landing page should accommodate showing this Hub topic and related articles without it being hidden or pushing down the Health care topics to the truncated/hidden area.

Resources and support will be undergoing a future redesign but in the interim, we need a way to show this topic with a light lift for an MVP solution.

Description

Drupal editing screen shows listed in user-specified order. FE is alphabetical with exception of first and last ones, and truncated to limit to 6 categories.

Some potential options:

• remove "show all topics" button and no longer hide topics
• allow editor to rearrange order of topics, not dependent on an alphabetic order

Decisions

Hard-Coded Conditional (fastest, but with tech debt): Points 3️⃣

• Add a conditional that checks if the page is /resources (there is another part of the codebase doing exactly this) and
  • Renders all the categories
  • Removes the show all categories button

Note that Daniel has confirmed that the conditional option won't change the sort order, we'll leave the existing sorting behaviors intact so as not to cause regressions or unexpected bugs.

Acceptance criteria

• [x] New topic has capability of being shown without hidden content shown after button is clicked
• [x] Sort order is preserved
• [x] Test the happy and unhappy paths to ensure no unintended issues arise
  • [x] Need to determine which paths to test.
• [ ] Per comments below, update "Go to all articles" links for each category to be more descriptive:
  • [ ] Go to all articles about VA account and profile
  • [ ] Go to all articles about decision reviews and appeals
  • [ ] Go to all articles about disability
  • [ ] Go to all articles about education and training
  • [ ] Go to all articles about health care
  • [ ] Go to all articles about other topics and questions
• [x] Design review
• [x] Accessibility review

[aklausmeier]

New concern came up during discussions with Mikki and Danielle, stubbed ticket for consideration, hoping it might be a quick/light lift. Let me know if you have any questions.

cc @FranECross @Agile6MSkinner

[FranECross]

Moved to Next Refinement for review by engineers/Amanda next week. cc @aklausmeier @Agile6MSkinner

[davidmpickett]

Adding the frontend label as the work this ticket describes will require changes to the FE template, regardless of the implementation path. Drupal effort may or may not be involved

[aklausmeier]

@FranECross @Agile6MSkinner This is pointed but not clear on which solution will be implemented. I suggested a few options but was hoping an engineer could refine to inform best solution to move forward with as an MVP solution and hopefully lighter lift.

[FranECross]

@dsasser @davidmpickett We'd like, if possible, to pull this ticket into the sprint tomorrow, but as Amanda indicates above some thought needs to go into what the implementation will actually be. Do you want this to be a Spike, that you can either then implement using this ticket, if the Spike efforts isn't that big, or attempt to refine before tomorrow's meeting? Apologies for this late question, but when I saw it was pointed, I thought the path forward had already been determined.

[davidmpickett]

I don't think we should skip the normal refinement process on this. Doesn't seem like there's been any engineering feasibility / lift conversation yet. IMO, SPIKEs should be reserved for complicated technical investigations. I think this just needs clarity on what the requirements are so that the right technical implementation can applied.

1. Display Family Member Benefits category on R&S landing page in position (x)
   • Probably entirely FE work, might only be 3 points
2. Allow CAIA editors to control order of topics on R&S landing page
   • Requires Drupaling in addition to FE, is that MVP?

[FranECross]

I imagine the points should be removed and Needs refining tag should be added? I (and I think Michelle) thought it was ready to go. Thanks again!

[mmiddaugh]

Display Family Member Benefits category on R&S landing page in position (x)

Yes, the goal is to make the new Family Member Benefits category visible but not at the risk of bumping another category out of view and not necessarily dictating position.

I'm guessing there might be other low lift options here.

• If the number of visible categories is currently limited, could that limit be removed? If so, what would be the outcome?
• What would be the outcome if the "Show all topics" button were removed?

@aklausmeier

[aklausmeier]

@FranECross I provided 2 options in the ticket, an engineer should weigh in on which one is the lightest lift and move forward OR suggest an even lighter lift solution.

Some potential options:

• remove "show all topics" button and no longer hide topics

• allow editor to rearrange order of topics, not dependent on an alphabetic order

If removing the "Show all topics" button and showing all hubs on landing page is the lightest lift, that is my preference.

[jilladams]

Assigned to @FranECross for follow up / refinement, and moved to top of Next Refinement.

[dsasser]

Engineering Pre-finement notes:

The categories are coming back from GraphQL in the order that they are arranged in the UI, but they are ultimately being re-arranged by a liquid filter formatVaParagraphs before being rendered.

The filter re-orders the categories, placing 'VA account and profile' first, 'Other topics and questions' last, then everything else alphabetically.

⚠️ The challenge here is that this filter is being used not only by Basic Landing Pages but also any entity that uses the corresponding paragraph type, Lists of Links. So any change we do to the filter could affect other pages if we are not careful.

On the FE, the template affected is the basic_landing_page.drupal.liquid. This template hands over the rendering of the categories to the lists_of_links.drupal.liquid liquid template, which leverages the formatVaParagraphs filter.

formatVaParagraphs liquid filter

{ const FIRST_SECTION_HEADER = 'VA account and profile'; const LAST_SECTION_HEADER = 'Other topics and questions'; // Derive the first and last sections. const firstSection = _.find( vaParagraphs, vaParagraph => vaParagraph.entity.fieldSectionHeader === FIRST_SECTION_HEADER, ); const lastSection = _.find( vaParagraphs, vaParagraph => vaParagraph.entity.fieldSectionHeader === LAST_SECTION_HEADER, ); const otherSections = _.filter( vaParagraphs, vaParagraph => vaParagraph.entity.fieldSectionHeader !== FIRST_SECTION_HEADER && vaParagraph.entity.fieldSectionHeader !== LAST_SECTION_HEADER, ); return [ firstSection, // Other sections is sorted alphabetically by `fieldSectionHeader`. ..._.orderBy(otherSections, 'entity.fieldSectionHeader', 'asc'), lastSection, ]; }; ```

Graphql query

Possible Solutions

Hard-Coded Conditional (fastest, but with tech debt): 3️⃣

Add a conditional that checks if the page is /resources (there is another part of the codebase doing exactly this) and

• Renders all the categories
• Removes the show all categories button

Drupal Field (more complex, but more adaptable): 8️⃣

Add a Drupal boolean field to Paragraph to control display of the categories. This would include:

• A new Drupal boolean field to the lists_of_links paragraph. A single checkbox which indicates that all categories should be displayed. (Drupal engineering)
• Checking this box in the Drupal /resources node (Content)
• Adding the new field to the GraphQL query
• Adapting the liquid filter to accommodate the new field. If set, the categories will all be rendered and there will be no 'Show all topics' button.

[FranECross]

@dsasser Thanks so much for the research and prefinement notes. Are you able to swag estimates for the two options above? I messaged Michelle in Slack (for when she's back on Monday) asking her to review.

I do see in the description this note, and wonder if the hard coded is the fastest/least effort if that would be the way to go, and then a different, adaptable solution be implemented during the redesign?: "Resources and support will be undergoing a future redesign but in the interim, we need a way to show this topic with a light lift for an MVP solution."

cc @aklausmeier @jilladams

[dsasser]

@FranECross

Are you able to swag estimates for the two options

Hard-coded FE: 3 Drupal Field: 8

[FranECross]

Amanda responded in the Slack thread: My vote is the hard-coded, lightest lift but would like Michelle to weigh in on Monday.

[FranECross]

@Daniel Sasser Updating ticket with Slack question from Michelle I assume adding the conditional will not change the existing sort order, which is 'VA account and profile' first, 'Other topics and questions' last, then everything else in alpha order. Can you confirm? I agree with hard-coded approach (but if the sort order is affected, we may need to add a separate task to restore the order)

[dsasser]

@daniel Sasser Updating ticket with Slack question from Michelle I assume adding the conditional will not change the existing sort order, which is 'VA account and profile' first, 'Other topics and questions' last, then everything else in alpha order. Can you confirm? I agree with hard-coded approach (but if the sort order is affected, we may need to add a separate task to restore the order)

@FranECross @mmiddaugh yes the conditional option won't change the sort order, we'll leave the existing sorting behaviors intact so as not to cause regressions or unexpected bugs.

[FranECross]

Thanks so much, @dsasser . I've updated the ticket with a Decision section, noting the hard-coded decision, and added "Sort order is preserved." to the AC for posterity. So you consider this ready for the Ready pipeline, or do you want to look at it one more time in refinement this week?

[randimays]

Pulling into sprint 9 as stretch.

[randimays]

This will carry over to sprint 10. Adding and testing on the Resources & Support landing page was straightforward, but it is not clear where else this component is used, so I'm working on adding test data into a Tugboat.

[randimays]

I made the changes for the R&S landing page ✔️ But I'm stuck on how to check the Lists of Links component on other pages (the version with max 6 categories).

@davidmpickett and @omahane helped me discover that Benefit Hub Detail Pages can use Lists of Links. I added test data in a Tugboat to these pages:

• https://web-w4azz2khpzdi53uymp1gxkpi0fbqdlqu.demo.cms.va.gov/housing-assistance/home-loans/how-to-request-coe
• https://web-w4azz2khpzdi53uymp1gxkpi0fbqdlqu.demo.cms.va.gov/change-direct-deposit

But the test data doesn't show up in the web view. I looked at the Metalsmith data to see what was coming through and it's missing content:

Here's what that same data looks like on R&S landing page:

This is a GraphQL issue, so I looked at the query for lists of links. The only place this query used is in the BasicLandingPage GraphQL. The basic_landing_page template in content-build only maps to one page: R&S landing page.

Noteworthy CMS warning:

@dsasser (@jilladams, @FranECross): Is it safe to say that we can remove the truncation / "show all" button from the Lists of Links component? It doesn't look like there is another public-facing use case for it other than R&S landing page.

[FranECross]

@randimays I would love to defer to @dsasser and/or @jilladams, since they have so much more historical knowledge. My knee-jerk is to say 'yes'.

[randimays]

@dsasser to your point from scrum: it is possible to add this content type to Benefit Hub detail pages, but considering the Resources and support or User Guides only! messaging: is it possible to remove this content type from those pages so no one can try to add it?

[dsasser]

@dsasser (@jilladams, @FranECross): Is it safe to say that we can remove the truncation / "show all" button from the Lists of Links component? It doesn't look like there is another public-facing use case for it other than R&S landing page.

@dsasser to your point from scrum: it is possible to add this content type to Benefit Hub detail pages, but considering the Resources and support or User Guides only! messaging: is it possible to remove this content type from those pages so no one can try to add it?

@randi great discovery!

B.L.U.F.: I suggest we do as Randi is recommending, and remove the truncation / "show all" button from the Lists of Links component.

My thought for the fast version when originally refining this ticket was to just use a conditional check for the /resources path such as what is done page.js. Which admittedly is not ideal and pretty ugly.

I looked at all current uses of the lists_of_links paragraph (some nodes use the same paragraph type multiple times, but we only list unique instances below):

Node Type	Uniqe Count
Landing Page basic_landing_page	1
Centralized Content centralized_content	1
CMS Knowledge Base Article documentation_page	9

Landing Page There is only one Landing Page with a lists_of_links, which is the landing page for the Resources and Support home page at /resources. This is the primary page we want to affect.

Centralized Content The only node using lists_of_links is an archived 404 page, so this page never gets built by content-build, and so changing the behavior of the component would have no affect here.

CMS Knowledge Base Article These are not rendered on VA.gov, so changing the content-build behavior would have no affect.

[randimays]

Thank you @dsasser for looking into this! I'll remove the truncation from the Lists of Links component.

[randimays]

@FranECross

In PR reviews, @laflannery asked if we could update the "Go to all articles" links on R&S landing page categories to be specific to each category since the links as-is are duplicative. See #2 in her comment.

Note that these are editor-managed fields in Drupal, so we can change them now and they have the ability to change them back. But if/when editors add new categories they will have our new pattern to follow.

This would require a change in prod Drupal that would then propagate to lower environments over the next day or so. The FE work for this ticket is already complete.

Are you OK with us making those link text updates as part of this ticket?

[randimays]

@laflannery For those proposed link text updates, here's what I'm assuming we'd use (the last one I'm not sure about):

• Go to all VA account and profile articles
• Go to all burials and memorials articles
• Go to all decision reviews and appeals articles
• Go to all disability articles
• Go to all education and training articles
• Go to all health care articles
• Go to all life insurance articles
• Go to all pension articles
• Go to all other topics and questions articles

[laflannery]

The last one could be "Go to all articles about other topics and questions" which makes a bit more sense to me.

And if we did want to follow the same pattern we could flip the other ones:

• "Go to all articles about health care"
• "Go to all articles about VA account and profile"
• "Go to all articles about education and training"
• etc.

But I don't have a preference on that either way.

[FranECross]

@FranECross

In PR reviews, @laflannery asked if we could update the "Go to all articles" links on R&S landing page categories to be specific to each category since the links as-is are duplicative. See #2 in her comment.

Note that these are editor-managed fields in Drupal, so we can change them now and they have the ability to change them back. But if/when editors add new categories they will have our new pattern to follow.

This would require a change in prod Drupal that would then propagate to lower environments over the next day or so. The FE work for this ticket is already complete.

Are you OK with us making those link text updates as part of this ticket?

@randimays I am okay with you making the link text changes. Should I or will you be stubbing the drupal ticket? Thanks!

[randimays]

@FranECross I think we can make those changes as part of this ticket; we can just add ACs. I'll do that now.

[randimays]

The category truncation has been removed, and the link text has been updated and validated successfully in production. Closing as complete!