As a member of the public (permittee), I can enter in basic information (email) so that I can get a permit for Arapaho and Roosevelt National Forests

[sadlerw]

Acceptance Criteria

• [x] user can enter information that the forest service requires from the user to obtain a permit.
• [x] user should be able to enter a quantity
• [x] user should see the price per permit/tag
• [x] user knows which forest they are entering information for.
• [x] user should be able to submit the information and have it stored in the db for later retrieval.
• [x] user should see verbiage describing what will happen in the flow after submission and that they will be returned to receive the permit. (will be fleshed out later once pay.gov integration is complete)

Definition of Done

• [x] Code unit / e2e tested and comply with QWASP
• [x] No new security vulnerabilities
• [x] Internal team code review
• [x] Documentation / readme.md / CircleCI updated
• [x] Docker updated
• [x] Compare finished design with mockup
• [x] Usability tested (Bryan)

Tasks

• [x] research and get pricing information for each pilot forest (Jane)
• [x] user task flow model (Bryan, Jane)
• [x] db model (email address, cost per tree and forest org id) (Shekar)
• [x] migration (use dotransaction) (Shekar)
• [x] routes in frontend (Cameron, Seth)
• [x] write up form help text and boilerplate (Jane)
• [x] html design mockup (Cameron, Seth)
• [x] design approval (Melissa, Amber)
• [x] view/component (Cameron, Seth)
• [x] REST endpoints (GET POST)
• [x] simplify/remove e2e functions that are used only once

[ASprinkle]

I would like this story to be focused on the is the entering of the permittee information (before you pay) - #13 addresses this... (The button to get your permit, rules acknowledgement, name, email address etc.)

[MelissaBraxton]

Here is a rough user task flow I sketched out during our chat. its a first take, and I suspect a more ideal user experience that still meets the overall payment goal could be achieved in one or two fewer tasks, but we'll see!

[ASprinkle]

@JaneZC I see you're task is research to determine pricing information. Here is some information that was emailed to me recently from the Forest contacts I have:

Flathead National Forest: -people are limited to 3 tags per household for the Forest. This limit does not vary by district. -Christmas tree permits are $5.00 each across the Forest. This price does not vary by district.

Shoshone National Forest -Christmas tree permits are $8.00 per tree if the tree is less than 20 feet tall. If the tree is over 20 feet tall then it's an additional $8.00 up to 30 feet, and then an additional $8.00 for each additional 10 feet. This pricing structure is consistent across the Forest. -people are limited to 5 trees per household. This is consistent across the Forest.

Mt. Hood National Forest -Christmas tree permits are $5.00 per tree. This pricing structure is the same across forests -There is a limit of five trees per household. This is the same across the forest.

I haven't heard back from the ARNF yet

[JaneZC]

@adsprinkle Thank you!!

A question on terminology - are 'tags' and 'permits' interchangeable? So, for Flathead, you'd buy three permits and get three tags? I suspect it would be best to only user the word 'permit' on the form, but wanted to make sure I understand how that terminology is used.

Arapaho & Roosevelt National Forests

• Permits cost $10 per tree
• Permits are limited to a maximum of five per person.
• It appears that the pricing is consistent across the Forest Districts; ARNF has posted their 2017 information online.

[sethalt]

Attached are screenshots of the basic form application layout. One screen shot is with the fields filled in without errors, the other show the error messages. Lets start thinking about form hint text or error messaging. @JaneZC @bryanmcfadden @MelissaBraxton

[sethalt]

@JaneZC @bryanmcfadden @MelissaBraxton

The language for redirecting to pay.gov. This current is the page that appears when you click "Submit your application," however it can be put inline on the form page or appear as a popup if you all think that is better. From a 508 standpoint, I think the text alone on a new screen might be the easiest/best solution.

On the intake side, handling the login.gov redirect notice, we added text right in the button that told the user they would login with Login.gov. E.g.

[ASprinkle]

@JaneZC and team - let's stick with the word "permit" vs. tags. In the office it seems like they are interchangeable - but for purposes of this project let's be consistent in using the term "permit".

The Apply form looks great - for the "Number of trees" field, can we title it "Number of Christmas tree permits to purchase" or something like that?

[sethalt]

@JaneZC @bryanmcfadden @MelissaBraxton @ASprinkle Updated confirm and pay page

[ASprinkle]

I think that looks great! The only comments I have are: -Change "number of trees" to "Number of Christmas tree permits" or something along those lines. -Does being directed to pay.gov actually "complete" the transaction?

[MelissaBraxton]

Great progress! A few comments:

The checkout button is quite long. Consider not including the pay.gov logo inside the button container, but elsewhere on the page.

In this Peace Corps example https://www.peacecorps.gov/donate/projects/the-marine-sanctuary-revitalization-project-17-492-013/donate/?amount=50, they don't use the pay.gov logo at all. I like the way they address @asprinkle process question--They tell the user that they're going to pay on pay.gov and but that they'll be directed back to the peace corps site, which is the same flow (I believe) users will experience with xmas tree permitting.

Melissa Braxton User Experience Designer, 18F Cell: (415) 696-4216 https://18f.gsa.gov/

On Mon, Nov 27, 2017 at 3:22 PM, ASprinkle notifications@github.com wrote:

I think that looks great! The only comments I have are: -Change "number of trees" to "Number of Christmas tree permits" or something along those lines. -Does being directed to pay.gov actually "complete" the transaction?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nciinc/fs-intake-module/issues/12#issuecomment-347362388, or mute the thread https://github.com/notifications/unsubscribe-auth/ATscnovvOcnC87PnwyLRNqyZ1bBzILj2ks5s60QzgaJpZM4P3IAC .

[JaneZC]

A few suggestions .... @adsprinkle @MelissaBraxton @bryanmcfadden

1) I would recommend user testing the header (or we can change now?) It may be more clear to use "Buy a Christmas tree permit" instead of "Apply for a Christmas tree permit" ... This page doesn't mention to the user that the goal is for them to purchase permit ... just asks them to apply for a permit, gives them a price, and tells them to 'submit' their application. Using the word 'buy' in the header may clarify things a bit.

2) @adsprinkle ... I agree with Number of Christmas tree permits as wording for the field.

3) In the future, can we add how much the tree costs to the page itself? I think it would be nice to have that information up front ... instead of having to backwards calculate it from the form.

5) It is Arapaho and Roosevelt National Forests (with an s). Also, Christmas should be capitalized in the header.

6) The Confirm and Pay page should use the word permit on it somewhere. (Right now, it sounds like you are ordering trees instead of permits.) Is it possible to say Number of Christmas tree permits here as well ... instead of trees?

[JaneZC]

@sethalt @bryanmcfadden

Below are some suggested error messages; I wrote them to focus on what the user could do to fix the message (instead of telling them what they probably have figured out.) Permit holder is a bit long ... but I think a necessary evil for the initial go around. :)

Suggested Error Messages:

Please enter the permit holder's first name.

Please enter the permit holder's last name.

Please enter an email address. (if nothing is entered) Please enter a valid email address. (if an invalid email is entered)

Please enter the number of Christmas trees.

Also, like @MelissaBraxton , I think the the Peace Corp pay.gov message is clean and simple. Can we add to the page with a minor change? (We can leave off the word NOTE though.) So, just the below:

We use Pay.gov as our trusted secure payment processor. We’ll send you on to there to buy your permit(s) and bring you back when you finish.

[sethalt]

@ASprinkle @MelissaBraxton, I've updated the views with the feedback provided. @JaneZC I added some intro text with price per tree and number of trees per household info. Please revise if needed.

[sethalt]

@JaneZC Regarding the error messages. We are using the paradigm established on the intake project, and I'm hesitant drifting from it unless there is strong evidence that we need to. We are using a re-usable error template so changing the messaging would require a new error template just for the trees form fields.

[ASprinkle]

It's looking great - Just a few tweaks: -A household is allowed to purchase "up to" 5 permits. -Confirm and pay page has "Forest" instead of the plural. -We are asking for email so that we may email their permit to them as an option, correct? Maybe it's second nature to most people, but if they don't want to give their email out - should we add info in the error message that explains why their email address is needed. Something like: "Please enter your email address so that your permit(s) can be emailed to you." Looking for some expertise here on the necessity of that or not.

[sethalt]

@ASprinkle @JaneZC what about adding some hint text below the email label, so a user doesn't need to tab past the input to know why the field is necessary?

[ASprinkle]

That sounds even better!

[JaneZC]

@sethalt @adsprinkle

For email hint text .... Hint text should help users fill out the form fields with proper format (ie. passwords, phone numbers, etc.) I am not sure we need it as I think email format is common enough that the error that will occur is largely due to typos and/or mistakes. But, I don't think it hurts anything. If you'd like to add it, I would use this (similar to what is on the DOB input here - https://standards.usa.gov/components/form-controls/#date-input

For example: someone@example.com

One additional thought ... do we need a first name and last name field or can we just say Name? I am not sure the database is built or what the requirements would be for using that data elsewhere (ie on print-outs, etc.), but was thinking it might be easier on users by having less fields for them to fill out.

Edited to Add: For this, I don't think we need labels the fields as required, since all of them are. (It also wouldn't make sense to label only the Email field as required, using hint text, because then we've indicated that only one field is required (which implies the other ones are not).) Here is the material from the Content Style guide ... https://content-guide.18f.gov/forms/#dont-make-optional-information-required

[JaneZC]

@sethalt Agreed on error messages. It should be consistent. Thanks for sharing!!!

[sethalt]

@MelissaBraxton @ASprinkle

The team decided that the confirm page wasn't necessary at this point, so we condensed it down to a single page. We've updated the copy for clarity. Please let us know what you think.

[sethalt]

and here it is with the fields filled in

[ASprinkle]

@sethalt That looks really clear to me. @JaneZC First and Last name is preferred over "name". Their first name/last name, or some combination will be printed out on the permit somewhere.

[sethalt]

@ASprinkle @MelissaBraxton please comment with Approved if you feel like this design meets the acceptance criteria, and if so we will merge this code into sprint-4. Thanks!

[MelissaBraxton]

Looks good to me! I checked the "approved" box! :)

A few minor tweaks to consider in the future:

• Add a line break between "Christmas tree permits cost..." and Your Information to make it clear that the "Your info" header is tied to the form fields below, not the section above.
• Remove the period after "Buy a Christmas Tree Permit" (I know it is an imperative, but it is inconsistent with the header style elsewhere.)

[sethalt]

@MelissaBraxton there is a line break, but it must have gotten lost when i zoomed out to take the screen shot. See below.

As for the period. I'd like to discuss that with you. That paradigm was carried over from Intake (see below), and perhaps we need to re-address how we use periods in headings on our tree guidelines page.

[MelissaBraxton]

Thanks @sethalt

• I am checking on the period issue w/ our content folks. Our content guide is silent on the matter. I'd leave the period in for now to stay consistent with the special uses site style for now.
• One more thing! Please shorten the length of the "number of Christmas tree permits" form field. Since the limit is 5, people's answer will only be a single character.

[sethalt]

Pre-merge screenshot with some of the last recommendations.

[bryanmcfadden]

Based off of Melissa's design.

A few questions:

1. Do we need a flow for pay.gov (I think its needed for the next story)?
2. How does pay.gov work? Does it provide a summary detail?
3. Where does the user end up if they cancel the redirect to pay.gov?

[ASprinkle]

These are great questions, and a bit beyond my expertise.. I will defer to others on the team.

[shekarpendem]

@ASprinkle @MelissaBraxton Direct URL to the permit application form for Mt. Hood is : https://forest-service-trees-staging.app.cloud.gov/applications/christmas-trees/forests/mthood/new Replace mthood in the URL with arp or flathead for other forests.

[MelissaBraxton]

@bryanmcfadden and @JaneZC

Some thoughts on your questions:

1. I think it's fine to flesh out the task and info flow for pay.gov as part of working on #13
2. Another thing to be worked out fully in #13, but it does have implications for this flow diagram. Regardless of whether pay.gov provides a summary detail, I'd want to see a purchase confirmation from the FS. From what I've heard re: the login.gov experience (not analogous, I know), being redirected to fed gov. a site outside the one they intended to visit can be confusing for folks. I'd imagine people getting worried if the order confirmation/summary did not come from the FS, but if this is how pay.gov works, then we'll just need to see what we can do about the design of the summary detail page pay.gov provides (e.g., include the FS logo).
3. I'm not sure there needs to be a separate step to accept or cancel the pay.gov redirect. Seems fine to me to have clicking "checkout" go right to the payment form. If folks want to cancel their transaction from there, I'd imagine going back to the buy a permit screen, rather than the forest-specific page.

[lauraGgit]

One minor thing - I think it could be helpful in the number of christmas tree help text to include the maximum number there too.

[sethalt]

@lauraGgit @MelissaBraxton @ASprinkle

[JaneZC]

@MelissaBraxton @sethalt

I wanted to check and see what was the final decision was on whether a period is needed after 'buy a permit'?

Thank you!

[MelissaBraxton]

Thanks @JaneZC!

Following up re: "." at the end of headings that are full sentences.

I checked in with our content folks, and the verdict is no "."

I know this is different than what had been decided on the intake module, (we do add periods at the end of full sentence list items, and our content folks wondered whether the li guidance got conflated with heading style.) Also, the APA style guide does say that a period is ok at the end of a full sentence heading, but only lower level headings, not H1 or H2.