-
Notifications
You must be signed in to change notification settings - Fork 70
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
Comments
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. |
Moved to Next Refinement for review by engineers/Amanda next week. cc @aklausmeier @Agile6MSkinner |
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 @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. |
@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. |
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.
|
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! |
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.
|
@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.
If removing the "Show all topics" button and showing all hubs on landing page is the lightest lift, that is my preference. |
Assigned to @FranECross for follow up / refinement, and moved to top of Next Refinement. |
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. 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 SolutionsHard-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
Drupal Field (more complex, but more adaptable): 8️⃣Add a Drupal boolean field to Paragraph to control display of the categories. This would include:
|
@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." |
Hard-coded FE: 3 |
Amanda responded in the Slack thread: My vote is the hard-coded, lightest lift but would like Michelle to weigh in on Monday. |
@daniel Sasser Updating ticket with Slack question from Michelle |
@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. |
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? |
Pulling into sprint 9 as stretch. |
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. |
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: 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 @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. |
@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'. |
@dsasser to your point from scrum: it is possible to add this content type to Benefit Hub detail pages, but considering the |
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 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):
Landing Page Centralized Content CMS Knowledge Base Article |
Thank you @dsasser for looking into this! I'll remove the truncation from the Lists of Links component. |
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? |
@laflannery For those proposed link text updates, here's what I'm assuming we'd use (the last one I'm not sure about):
|
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:
But I don't have a preference on that either way. |
@randimays I am okay with you making the link text changes. Should I or will you be stubbing the drupal ticket? Thanks! |
@FranECross I think we can make those changes as part of this ticket; we can just add ACs. I'll do that now. |
The category truncation has been removed, and the link text has been updated and validated successfully in production. Closing as complete! |
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:
Decisions
Hard-Coded Conditional (fastest, but with tech debt): Points 3️⃣
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
The text was updated successfully, but these errors were encountered: