Better UX for mapping form inputs to eligibility checks
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- frontend
Research direction
Start with the form editor's Components section and review issue #357 alongside the current mapping behavior in the main branch. Clarify the two proposed modes or tabs, their validation behavior, and what completion means for both form-focused and eligibility-focused workflows.
Written by the indexing model from the issue text.
Description
Originally surfaced by #357
There is a "chicken or egg" issue when creating the form and sometimes you want to focus on the questions and sometimes you want to focus on ensuring all eligibility checks are accounted for.
Idea:
Allow the user to toggle between "modes". One mode where the eligibility checks are less emphasized but with a way to validate mapping t to form inputs (this is the current functionality in main branch) and another mode that is focused on the eligibility checks with the form possible form inputs that could be implemented for them (this is the concept presented in #357).
This could take the form of two different tabs in the "Components" section of the form editor; one that shows all components, the other that allows you to select/map only the components that are possible for a given (selected) eligibility check.
- Dominant language
- Java
- Stars
- 16
- Forks
- 5
- Avg merge
- 17h 24m
- Merged PRs (30d)
- 23
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeForPhilly/benefit-decision-toolkit
-
documentation Good for newcomer quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
Maintainers usually reply within 1 day
-
documentation quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
Maintainers usually reply within 1 day
-
Make issue templatesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Maintainers usually reply within 1 day
All issues in CodeForPhilly/benefit-decision-toolkit
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
feature triaged
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Graylog2/graylog2-server#27549 ·
Maintainers usually reply within 1 day
-
component/zeebe kind/bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
UniversalMediaServer/UniversalMediaServer#6356 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
googleapis/google-cloud-java#14533 ·
Maintainers usually reply within 1 day