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

Group pages into hierarchy in form-filler view #408

Open
26 tasks
JennyRichards-Flexion opened this issue Dec 13, 2024 · 0 comments
Open
26 tasks

Group pages into hierarchy in form-filler view #408

JennyRichards-Flexion opened this issue Dec 13, 2024 · 0 comments
Labels
story User story

Comments

@JennyRichards-Flexion
Copy link
Contributor

JennyRichards-Flexion commented Dec 13, 2024

Overview

As a form-filler user, I feel overwhelmed by the large number of items in the navigation sidebar. I want to feel like the application is doable for me and that I can find my way back to a specific question if I need to change something. (Should we consider only showing page titles the user has interacted with so far? Maybe plus a %age done progress bar?)

Context

Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.

  • [ ]

Acceptance Criteria

Required outcomes of the story

  • Form filler users do not feel overwhelmed from the moment they begin
  • Form filler users can easily get back to a question from a previous page they want to update

Research Questions

  • Optional: Any initial questions for research
  • How do form builder/filler needs for navigation differ?
  • Are pdf page # references the best navigation "landmarks" for form builders or is there something else that will accomplish quick navigation when beginning work on a draft?

Tasks

Research, design, and engineering work needed to complete the story.

  • Design mocks new navigation features, including potential enhancements/items to test, focus is on learning
  • Engineering determines how much builder/filler page nav components can/should overlap under the hood
  • Engineering builds minimum testable implementation

Definition of done

The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.

  • Behavior
    • Acceptance criteria met
    • Implementation matches design decisions
  • Documentation
    • ADRs (/documents/adr folder)
    • Relevant README.md(s)
  • Code quality
    • Code refactored for clarity and no design/technical debt
    • Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies; dependency rule followed
    • Code is reviewed by team member
    • Code quality checks passed
  • Security and privacy
    • Automated security and privacy gates passed
  • Testing tasks completed
    • Automated tests pass
    • Unit test coverage of our code >= 90%
  • Build and deploy
    • Build process updated
    • API(s) are versioned
    • Feature toggles created and/or deleted. Document the feature toggle
    • Source code is merged to the main branch

Decisions

  • Optional: Any decisions we've made while working on this story
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
story User story
Projects
None yet
Development

No branches or pull requests

1 participant