Permittee data entry form: As a permit purchaser, I need a secure way to enter required permit information online so that I can get my permit quickly.

[MelissaBraxton]

Background This story covered the design and development of the permittee data entry form.

We've been working on the assumption that login.gov will be the ID verification solution, but we've also flagged the concern that the login.gov account creation process may be a high bar of entry for some folks. Explore whether there is any flexibility around ID verification for firewood permits, esp. considering current COVID-19 policy workarounds and that handbooks are being revised. The team may want to begin by bringing this up with Forest Mgmt and LEOs.

Consider validation that helps people avoid purchasing the wrong product for them (e.g., permit for the wrong location).

Acceptance criteria

• [x] Permit purchasers can securely enter and edit name
• [x] Permit purchasers can securely enter and edit their valid email address
• [x] Permit purchases can securely enter additional information that is required to be printed on the permit (e.g., vehicle info, home address)
• [x] Permit purchaser knows how their information will be stored and used
• [x] Permit purchasers will know how their information is secured

Tasks ~- [ ] Research policy re: "required information" and decide what permit purchasers are required to enter~ This is covered by #33

• [X] Design and test low fi mocks
• [X] Design refines mocks based on research insights
• [x] Devs build page from mocks
• [x] Validation of acceptance criteria completed
• [x] Design review
• [x] Code review
• [ ] PO Approved

Definition of Done

• [x] e2e tests are updated for application routing changes.
• [x] e2e tests are functioning.
• [x] Child routes for existing pages are working.
• [x] Pull requests meet technical definition of done.
• [x] Usability tested.

[MelissaBraxton]

Here is a link to the mock

[MelissaBraxton]

Revised to reflect design work that had been done as part of phase one, and added a link to the mock.

[Dmac26]

@csstarling - I was looking through the card here to make sure we had all of the bullet points checked off and it looks like there was a bullet calling for the user to enter vehicle information. However, it seems like that got changed somewhere along the way since the current mock for this page doesn't include a vehicle information section. Is that a change we wanted to make or should we be requiring users to enter vehicle info?

[Dmac26]

@carlsonem - As we're finishing off this card I'm wondering about the dropdown selection for the number of cords a user can choose. I'll post a screenshot below here of what it looks like.

Currently a user can only select the minimum number of cords, 4. I'm guessing we want more options than that. Look back over the content documents, some of the forests allow for a maximum of 20 per household per year, some 12, and some 10.... Some don't even mention a limit.

So do we want to just give the user the ability to choose up to 20 or do we want that option and validation to change with each forest?

[MelissaBraxton]

Added design and code review tasks.

[MelissaBraxton]

Happened to see your note, @Dmac26 - That is a great design Q! I'd imagine @aQuib and @jstrothman will have ideas here as well.

[csstarling]

@Dmac26 @aQuib @jstrothman : If it were my forest in this pilot I wouldn't want the customer to be given the option to buy more cords than the forest allows. So I would think we would want the option and validation to change with each forest.

[jstrothman]

@Dmac26 @csstarling @aQuib I agree that for the number of cords, we should only allow a number within the range that the given forest allows to make the process most efficient. Drop-down inputs are cumbersome when there are many options, such as when 20 cords is the max.

I recommend using a text input instead of a drop-down, validating that the person enters a number between the min and the max, and changing the form text so it is:

Number of cords * Cost: $5 per cord You can get between 4 - 12 cords [Input field, class: usa-input-tiny] Total cost for firewood permit

with an error message: 'Number of cords must be between 4 and 12'

[aQuib]

@Dmac26 @jstrothman @csstarling - Julie's recommendation on using text input instead of a drop-down field sounds good to me. Inline validation based on the forest cord min/max would also be needed.

[carlsonem]

@briandavidson can this be moved to validation?

[jstrothman]

@mtlaney Is this available for review on stage? If so, could you share a link? And if not, would you (or whomever is working on implementation) mention @mgwalker and me when it's ready for review? Much appreciated!

[briandavidson]

@briandavidson can this be moved to validation?

Hey @carlsonem, it's up on the dev environment and we're looking to get it onto staging for validation tonight or early tomorrow.

[jstrothman]

Design Review Notes I'm reviewing this at: https://open-forest-staging.app.cloud.gov/firewood/forests/flathead/buy @Rebekah-Hernandez or @aQuib Would you add mock-ups to this issue for page 1 and 2 of the buy permit? Also can you confirm if the content on page 2 is the correct width? Thank you!

@briandavidson Is there still an intention to change the number of cords drop-down to be a text input? (based on comments above)

In the usability reviews, people liked the page a lot and found it easy to use!

Adjustments needed There are some styling inconsistencies between the forest pages and the first step of the permit:

• [ ] Name of forest is an h3 on Forest page and an h2 on the Permit page. For accessibility purposes we shouldn't go out of order, e.g. staring with an h3 instead of an h1, though it does make sense that the h1 be the more specific title, e.g. "Firewood permit information" or "Buy a firewood permit." Let's make the forest name a <p> instead of a heading, and use css to style it like the h3.
• [ ] The h1 is styled differently on the two pages (700 weight on permit info page; 500 weight on buy page). Let's make these consistent

You are purchasing section

• [ ] Change to an h3: "2019 Personal-use Firewood permit" as it is subordinate content to the h2 "You are purchasing..."
• [ ] Make "Personal" and "Firewood" lower case and update year: "2020 personal-use firewood permit"
• [ ] Remove 'the' from "For the xxx Forest" so it reads, e.g. "For Flathead National Forest"
• [ ] Add a hyphen in "non refundable" so it reads "non-refundable"

[Rebekah-Hernandez]

@jstrothman The design mockup was a low fi version from 18F that we'd used for testing at an earlier date. At the time, we didn't make many changes from the original mockups. Here is what it looked like:

[jstrothman]

Thank you @Rebekah-Hernandez for the mocks. Could you or @aQuib review whether you'd like any changes to the width of the content on pages 1 & 2 on staging? (e.g. the brown intro block is full-width and the form fields are the same width as the page 2 rules box--perhaps fine, but not a match for the wireframes so your direction would be helpful.)

cc @csstarling (copying you on issues with design review notes)

[tram]

@Dmac26 It's not reflected in the lo-fi mock, but just wanted to call out @aQuib 's approval to switch from a drop-down to an input field that's validated.

Julie's recommendation on using text input instead of a drop-down field sounds good to me. Inline validation based on the forest cord min/max would also be needed.

[Dmac26]

@tram - Thank you for that info! That makes things a lot easier. I'll adjust accordingly!

[jstrothman]

@Dmac26 Could you tag me when the changes from the Design Review above, and the switch of the input for the cords are on dev? Thank you.

[jstrothman]

@aQuib @Rebekah-Hernandez There's still a question here about the width of the content: Could you review whether you'd like any changes to the width of the content on pages 1 & 2 on staging? (e.g. the brown intro block is full-width and the form fields are the same width as the page 2 rules box--perhaps fine, but not a match for the wireframes so your direction would be helpful.)

[aQuib]

@Dmac26 - Please expand the width of the page column to utilize full page (like other pages). See mockup:

[jstrothman]

@Dmac26 It looked from today's demo like this width adjustment still needs to be made.