Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
6 of 13 tasks
aklausmeier opened this issue Jul 5, 2024 · 30 comments
Closed
6 of 13 tasks
Assignees
Labels
Public Websites Scrum team in the Sitewide crew Resources and support CMS managed product owned by Public Websites team sitewide VA.gov frontend CMS team practice area

Comments

@aklausmeier
Copy link

aklausmeier commented Jul 5, 2024

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

Screenshot 2024-07-05 at 9.36.34 AM.png

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.
Screenshot 2024-07-05 at 12.56.09 PM.png

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

  • New topic has capability of being shown without hidden content shown after button is clicked
  • Sort order is preserved
  • Test the happy and unhappy paths to ensure no unintended issues arise
    • 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
  • Design review
  • Accessibility review
@aklausmeier aklausmeier added sitewide Drupal engineering CMS team practice area Needs refining Issue status labels Jul 5, 2024
@aklausmeier aklausmeier changed the title Resources and Support: allow editors to choose what categories shown on main landing page Resources and Support: allow editors to choose what categories are shown on main landing page Jul 5, 2024
@aklausmeier
Copy link
Author

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

@aklausmeier aklausmeier added the Resources and support CMS managed product owned by Public Websites team label Jul 5, 2024
@FranECross
Copy link

FranECross commented Jul 9, 2024

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

@FranECross FranECross added the Public Websites Scrum team in the Sitewide crew label Jul 22, 2024
@davidmpickett davidmpickett added the VA.gov frontend CMS team practice area label Jul 23, 2024
@davidmpickett
Copy link
Contributor

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

@FranECross FranECross removed the Needs refining Issue status label Jul 23, 2024
@aklausmeier
Copy link
Author

aklausmeier commented Jul 23, 2024

@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
Copy link

@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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Contributor

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

@dsasser
Copy link
Contributor

dsasser commented Jul 25, 2024

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 liquid.filters.formatVaParagraphs = vaParagraphs => { 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 queryfragment listsOfLinks on ParagraphListsOfLinks { entityId fieldSectionHeader fieldVaParagraphs { entity { entityBundle ... on ParagraphListOfLinks { fieldSectionHeader fieldLink { title url { path } } fieldLinks { title url { path } } } } } } query MyQuery { nodeQuery( limit: 25 offset: 0 sort: { field: "nid", direction: ASC } filter: { conditions: [ { field: "status", value: ["1"], enabled: true }, { field: "type", value: ["basic_landing_page"] }, { field: "nid", value: "8296"} ] }) { entities { ... on NodeBasicLandingPage { fieldContentBlock { entity { entityBundle ... listsOfLinks } } } } } }

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
Copy link

@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
Copy link
Contributor

dsasser commented Jul 25, 2024

@FranECross

Are you able to swag estimates for the two options

Hard-coded FE: 3
Drupal Field: 8

@FranECross
Copy link

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

@FranECross
Copy link

@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
Copy link
Contributor

dsasser commented Jul 29, 2024

@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
Copy link

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?

@FranECross FranECross removed the Drupal engineering CMS team practice area label Jul 31, 2024
@jilladams jilladams removed the Needs refining Issue status label Jul 31, 2024
@randimays randimays self-assigned this Aug 5, 2024
@randimays
Copy link
Contributor

Pulling into sprint 9 as stretch.

@randimays
Copy link
Contributor

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
Copy link
Contributor

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:

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:
Screenshot 2024-08-06 at 3 30 38 PM

Here's what that same data looks like on R&S landing page:
Screenshot 2024-08-06 at 3 30 44 PM

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:
Screenshot 2024-08-05 at 2 35 21 PM

@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
Copy link

@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
Copy link
Contributor

@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
Copy link
Contributor

dsasser commented Aug 8, 2024

@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
Copy link
Contributor

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

@randimays
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

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

@randimays
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Public Websites Scrum team in the Sitewide crew Resources and support CMS managed product owned by Public Websites team sitewide VA.gov frontend CMS team practice area
Projects
None yet
Development

No branches or pull requests

8 participants