Q&A consolidation to Reusable Q&A node type

[jilladams]

Background

Ported out of https://github.com/department-of-veterans-affairs/va.gov-cms/issues/8630, where this content was originally defined by @msbtterswrth . That effort was scoped down to adding Single Q&A nodes as Q&A Groups to Resources & Support as a content block option. This effort tracks the remaining work that would be required to consolidate the various kinds of Q&A content across CMS options & simplify the content model.

Q&A content within the CMS is complicated and hard to find/reuse and there are currently several methods for adding it.

1. Q&A paragraph - This exists on Benefits detail pages, Campaign Landing pages, Centralized Content and VAMC detail pages. It has a plain text field for the question, a rich text field for the answer and the ability to add a number of other content components including (more) rich text, accordions, process lists, number callouts, alerts, react widgets and tables.

2. Q&A group paragraph - This exists on Centralized Content and FAQ pages. It has a plain text section header field, a checkbox to display these Q&As as accordions and an entity reference to select Q&A nodes to be displayed.

3. Q&A Section paragraph - This exists on Benefits detail pages, Centralized Content, CMS Knowledge Base articles and VAMC detail pages. It has a plain text section header, a long plain text section intro, a checkbox to display these Q&As as accordions and a nested paragraph reference to the first Q&A paragraph.

4. Q&A - single node - This is a standalone content type (which is referenced within Q&A group paragraph) and allows for Q&A content to be reused across the CMS. It has a node title as the question, a paragraph reference to character limited rich text field as the answer, a checkbox to create a standalone page and the ability to add several content components such as alerts, calls to action, related information links, contact information, article categories and tags and related benefit hubs.

5. FAQ node - This is a standalone content type which creates a list of multiple Q&As. It contains a paragraph reference to the about Q&A group paragraph, along with several other common content components (nearly identical to the list above in Q&A single nodes).

User Story or Problem Statement

• How might we improve the UX of Q&A within the CMS and improve duplicative/confusing content models
• How might we clarify which method of adding Q&A is the right choice for the editor's needs
• How might we guide editors to create content once and publish it to multiple locations so that Veterans know that the information they are reading is accurate and in a consistent format and place
• How might we better support the AP content API, so that the data structure is clean and ensures fast delivery of information to Veterans

Affected users and stakeholders

• CMS editors of R&S content, Benefits Hubs, Facilities
• Developers of new Next.js content build, PW teams
• Veterans looking for information

Hypothesis

We believe that refactoring Q&A content models into one or two components will drastically cut down on editor confusion and improve both efficiency in the CMS (by making content reusable via COPE methods) and findability on the Veteran-facing website by providing consistent patterns and locations for Q&A content.

A few questions we'll need answered:

Content strategy (in partnership with Sitewide content team)

• Do we really want to rely so heavily on Q&As? (Assuming we still need them and want them to be reusable, continue with epic)

Content modeling

• What would it take to do a straight migration from paragraphs Q&As to Node Q&As
• How might we want to simplify the content model for Answers in the process… possibly remove support for certain paragraph types in the answers? Should that happen pre- or post-migration?

Editor experience

• Who would need to be able to create Q&A nodes (not just R&S editors)
• How to support non-reusable Q&As… just tell people to use rich text fields?
• How to add reusable Q&As from various content types.
• How to handle the “inline” Q&A editing experience in various situatinos, including in “Content block” (paragraph) fields. How would that work for editors with access to editing the original, vs not having access.

Change management triage

The change represented by this user story will:

• [x] Be a site-wide change to appearance or key functionality (such as log-in process)
• [ ] Be a specific change that requires more than 30 minutes of work by a user to meet a publishing requirement
• [ ] Remove a piece of functionality (such as restricting editing functions, or “hardening”)
• [ ] Require action by some or all users by a specific deadline
• [ ] Change the front end and be highly visible to the public
• [ ] Noticeable performance improvements (publishing speed, predictability)

Design principles

Veteran-centered

• [x] Single source of truth: Increase reliability and consistency of content on VA.gov by providing a single source of truth.
• [ ] Accessible, plain language: Provide guardrails and guidelines to ensure content quality.
• [x] Purposely structured content: Ensure Content API can deliver content whose meaning matches its structure.
• [ ] Content lifecycle governance: Produce tools, processes and policies to maintain content quality throughout its lifecycle.

Editor-centered

• [ ] Purpose-driven: Create an opportunity to involve the editor community in VA’s mission and content strategy goals.
• [x] Efficient: Remove distractions and create clear, straightforward paths to get the job done.
• [ ] Approachable: Offer friendly guidance over authoritative instruction.
• [x] Consistent: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.
• [ ] Empowering: Provide clear information to help editors make decisions about their work.

Labels

(You can delete this section once it's complete)

• [x] Issue type (red) (defaults to "Epic")
• [ ] CMS subsystem (green)
• [ ] CMS practice area (blue)
• [x] CMS workstream (orange)
• [ ] CMS-supported product (black)

CMS Team

Please check the team(s) that will do this work.

• [ ] CMS Program
• [ ] Platform CMS Team
• [ ] Sitewide CMS Team (leave Sitewide unchecked and check the specific team instead)
  • [x] ⭐️ Content ops
  • [ ] ⭐️ CMS experience
  • [ ] ⭐️ Offices
  • [ ] ⭐️ Product support
  • [ ] ⭐️ User support

[FranECross]

@jilladams The tickets in this epic all belong to the CMS team. Should Public Website be on this epic, or I can remove it? Thanks!

[jilladams]

Interesting. Scope-wise: all the Q&A types belong to CAIA as the business and Public Websites as the product team.

However: whether we ever get around to auditing / deprecating / migrating content automagically is up in the air. When we built out Reusable Q&As further in 2023, we opted not to programatically migrate any of this content, because CAIA wanted to review it and clean up content as they go, which is a long term project. So: it's PW work, but it could probably be Iceboxed or Closed as a no-op with Dave C and Danielle T's sign off, if that's still CAIA's strategy.

[FranECross]

Thanks so much for the background! I'll ping them both in the PW OCTO channel and ask.