(Placeholder) Review Page work to do/functional notes

[taylorkaren]

Using this ticket to record decisions made about work to be done on the review page.

More complex editing paths

• Implement the editing scenario for changing previous name selection from No to Yes (enter data for additional fields on the same page).
• Implement the editing scenario for adding the plot or interment benefit (enter data for additional fields on a separate page).

---

Use correct section headers

• There are two "Deceased Veteran Information" sections, referencing the military history and previous military names. We decided to give these sections unique headings, which match the headings in the steps of the form. See the correct section names (per several team discussions) in the UXPin prototype. This is also mentioned in Align demo form with UXPin prototype #584.

---

Messages displayed after edits are made to previously entered data

• The Your "x" has been updated text message remains on the Review Page until an action is taken; e.g., selecting an Edit link or submitting the application.
• Message display on the review page after changes to existing form data have been saved (Slack thread):
  • User updates 1 field: "[Field name] has been updated"
  • User enters 2+ fields in a single section: "[Section name] has been updated"
• Message display when more than one review page section is affected; for example, if you add plot or interment allowance when editing, show a message in the Benefits selection section that communicates an update has made made to information in that section AND show a message in the Plot or interment allowance section that communicates that section has been added. See page 9.3 of the UXPin prototype for an example.

---

Buttons on edit versions of form pages

• Likely changes to buttons on edit versions of the form pages, based on research work on ticket (Placeholder) Candidates for further Review Page Research #541.

---

Review Page construction (Ticket #600)

• Provide a Review Page template for teams, OK if there is some configuration available in the template.
  • Teams should not need to deviate dramatically from what is provided in the template.
  • Let people come to Collab Cycle with the use case to deviate from what is provided, and if the use case merits a deviation, design to that use case rather than trying to provide out of the box "flexibility."
  • What is the right component here? Once we get to V3 on the US WDS, we can focus more on these kind of composed components and make patterns easier to implement by pulling those parts “off the shelf.”