[EPIC] Benefit Detail page hardening using VA Benefit Taxonomy

[wesrowe]

Background

The Benefit Detail Page is an older blobby content type, that allows for a very loose content structure. That's not ideal for the future, where we want more structured content entry.

To begin, we will create a taxonomy to manage VA Benefits as taxonomy terms that can contain their own metadata. This taxonomy can be used much the same way the VA Services taxonomy is, and can act as a single source of truth for VA Benefits content that should appear in multiple places throughout Benefit Detail Pages, and the rest of VA.gov.

• Stakeholders: Sitewide Content, Accessibility & IA team
• Timeline: Dependent on CAIA

Planning

Pre-requisites/dependencies

• CAIA sequencing the work – Should Taxonomy population be done before we start this modeling work? Must it?

People who we'd like to have thinking about this at the same time/sprint

• CAIA
• DaveP
• PW Drupal Eng

Steps (issues?)

• Draft content model for hardened Benefit Detail content type(s)
  • 4 candidates: How to apply, About, Eligibility, After you apply – this is the going-in assumption
  • Do we have a separate type for all the various hardened types? how do things interrelate?
  • Can one giant content type be split up into multiple FE pages?
  • Can multiple content types be consolidated by one FE template?
  • See Airtable for the audit that would help us understand these questions
  • Outcome: drive toward an engineering conversation to get input on the overall approach (LoE, tech debt, flexibility, etc)
  • May be multiple tickets, engineering spike, etc
• Collab-cycle the model
• MILESTONE: MVP/1st content type is chosen
  • Pick first one to deliver based on LOE, value, etc
• Spec the content model for at least the first content type (spreadsheet)
  • Figure out what fields (blobby) are needed beyond what comes from Taxonomy
• At this point we're in the implementation cycle
• Consider schema.org on the FE side

Acceptance Criteria

• [ ] Testable_Outcome_X
• [ ] Testable_Outcome_Y
• [ ] Testable_Outcome_Z
• [ ] Requires KB article update

[jilladams]

CAIA feedback was shared via SharePoint doc today: https://dvagov-my.sharepoint.com/:w:/g/personal/danielle_thierry_va_gov/EZi5OJA1om9Fj_fl3IXmwYQBKKmKbkUhAXQuYyQFcG_Gjw?email=JILL.ADAMS1%40VA.GOV&e=31dcA4

Next step:

• Review the feedback doc within the team
  • [ ] @FranECross
  • [ ] @jilladams
  • [ ] @davidconlon
  • [ ] @davidmpickett , tbd prioritization with DaveC
  • [ ] Daniel / Michael, tbd prioritization discussion with Dave
• [ ] Schedule review meeting with Danielle / Randi H on CAIA to talk through the feedback, including Fran / DaveC / Amanda / DaveP / Drupal folks and whomever else is required

[davidmpickett]

Notes following quick review of the feedback.

1. Some of what they are asking for are things that were intentionally cut from MVP scope (see decision log). For instance, while "How to Apply" was an area I audited with the hopes of hardening, pretty much all of that was removed from the scope because it was determined that those details might better be part of the Forms Content Model.

2. The question of how does this relate to the Benefit Detail Page (Drupal Content Type) and the corresponding VA.gov Benefit Hub pages (FE pages) is very much an open one. This diagram gestures towards a path forward, but we'd need to do work to actually connect the Benefit Taxonomy in any meaningful way to the front end.

From a Product standpoint, want to make sure we're distinguishing between 1) Adding features to the Benefit Taxonomy vs 2) Wiring up the Benefit Taxonomy (as is) to power portions of the Front End.

3. More of a side note, but one of the ways we framed this last year was that there would be other consumers of the Benefit Taxonomy. How much should we keeping that perspective in mind when reviewing feedback / deciding on direction?