As Poppy, I want the license status Task to update its status automatically

[aloverso]

Activities include:

• [x] I see a question icon instead up/down arrow icon next to the task's status label. It looks like I can't change the status by myself. When I hover or click on the label, a tooltip appears explaining why the task status can not be manually changed.
• [x] The status automatically switches from NOT STARTED to IN-PROGRESS when the license status comes back as Pending
• [x] The status automatically switches from IN-PROGRESS to COMPLETE when the license status is Active

Dev notes

We will query Consumer Affairs to find out if the license status has changed: every time we try to load their data (backend-only) but with a timestamp so that it's no more than every hour. Otherwise we'd be querying way too often.

• [x] when we get user, we should make a search & update the license data (if it's been more than an hour)
• [x] once we get the license data status, then we update the Task Status
• [x] fix the license router so that it also updates the taskProgress when it does a search
• [x] change the frontend task to be un-editable and instead show the computed task status
• [x] make sure that the new LicenseData on the user gets updated when the user searches from the frontend
• [x] Refactor the license search so that it determines license type on the backend (instead of frontend)
• [x] make it so that the frontend does not do a search when skipping directly to the receipt screen (does not need to)

[skeeJay]

@aloverso What is the feasibility of throwing a chron job into the mix? Could we do it every hour, or every 6 hours? Every time they visit the Roadmap seems like overkill (unless you think that's doable), but we'll want them to be able to scan the Roadmap to see if it's updated itself without having to go to the license Task page.

[aloverso]

@skeeJay from a technical perspective, every time they visit the roadmap would be the easiest thing to do because all of the building blocks already exist. And it could be written in a way that they don't have to wait for that API call to complete in order to view the rest of the page. So I think I'd lean towards that first over building out new infrastructure for a cronjob

[skeeJay]

@aloverso Then that sounds good to me. I was only worried about rate limiting or something like that. Until that becomes a problem, let's just ping everytime they go to the roadmap for now.

[aloverso]

Hm, that's fair. Could be a lot of volume, but it's hard to know if that will be a problem or not... A cron job is also definitely feasible if we want to avoid the volume problem from the get-go

[skeeJay]

@aloverso In the agile spirit, I'd do the easiest version first. We may not need a chron job for a while.

[aloverso]

@skeeJay @guy-nj realizing we didn't resolve the question of when the status is considered IN-PROGESS instead of UNSTARTED?

Some options that come to mind:

1. when they click the primary CTA button to visit the consumer affairs link for the first time
2. when they submit information to the Check Status form (no matter whether we find their info or not)
3. when they submit information to the Check Status form and it finds their in-progress license application
4. something else?

[skeeJay]

None of the options are perfect, but for my money the clearest is option 3, "when they submit information to the Check Status form and it finds their in-progress license application." And in all the prior cases, the mouseover tooltip would clarify that NOT STARTED can mean, "This could mean you have not submitted your application yet, or the Division of Consumer Affairs is still processing your application and it doesn't appear in the system yet."

Also, small minor grammatical note I've been meaning to bring up: I believe the grammatically correct version is "IN PROGRESS," without the hyphen.

[guy-nj]

Agreed that option 3 is better than other scenarios. Should we update the current messages when there is no result returned to this: "We can not find your application. This could mean you have not submitted your application yet, or the Division of Consumer Affairs is still processing your application and it doesn't appear in the system yet." Anyway to shorten it?

[skeeJay]

Yes, good call on updating the error message as well. An error message also needs to encompass the situation that the information was mistyped. It's still long, but what about: "We couldn't find your application. Please check your information. This could also mean that the Division of Consumer Affairs is still processing your application and it doesn't appear in the system yet."

[aloverso]

That makes sense. I think I was probably leaning towards Option 2 because as soon as a user searches in a form, it would probably indicate that they have submitted it & expect it to be found?

It also makes sense because we have logic that if they have entered info in the form and searched, even if it got a Not Found, then the next time they visit the task, it will drop them directly on the Check Status tab with their info saved in the form. Since we're putting them somewhere other than the starting page, that seems to me to be consistent with the task being "in-progress" for them, since we've saved their address-lookup form info for that task.

And perhaps in general, it seems more user-friendly to me to show something as in-progress earlier than later. If I've submitted the form and I try to check my status, but it hasn't been processed by Consumer Affairs yet, I think I'd want to see it be In-Progress. If it appears as Unstarted for a while, that would be kind of disheartening. And also if you're scanning the roadmap looking for tasks you still need to complete, it would inaccurately look like this one requires action to start it.

[skeeJay]

@aloverso What you're saying about aligning the status with when we update the default tab you land on sort of makes sense, to have those in agreement. The main thing that feels wrong to me is that we're saying the status is updating "automatically" but that we're still making it "manually" changed by something the user does, instead of going all in on only updating it based on the availability of government data. But that might be something that's totally dependent on the user's perspective.

A ton is going to depend on how long a user has to wait between when the application enters the system and when the final checklist item is approved. If the paper application sits on a desk for weeks and gets entered into the system the same day they mark all the checklist items complete, then it's probably better to go to "IN PROGRESS" earlier.

[guy-nj]

I would prefer option 3 after comparing the worst scenario in option 2 and 3:

In option 2, if a user hasn't submitted the application but has clicked Submit for some reason. Then the user would freak out if the status turns to In Progress. I can't think of a way to solve this issue.

In option 3, if a user has submitted the application but it's still being processed and doesn't show in the system yet. It returns no result. The user would be confused but it seems we can explain this in the error message that EJ proposed above. It's not ideal but it could be understood.

Is there an even worse scenario in option 3 that I didn't consider? Or my worst example in option 2 might be too rare to worry about?

[aloverso]

@guy-nj I guess I'm struggling with why they would have a problem / freak out if the status changed in option 2? If they're interacting with the form (enough to fill in all the fields such that it doesn't give them the "fields required" error and actually submits their data), isn't that a pretty solid indicator that they're "working on" the task?

[skeeJay]

@aloverso I can think of a counterexample to that. Let's say they haven't sent in an application yet, get confused, think that the form is some kind of license submission form, and type in their address and hit submit. Now the Dashboard says their license application is In Progress, and they may think they don't have to do anything else. I don't think "In Progress" is an accurate readout for them in that situation… it's not manual, so they're going to "trust" it to be accurate more than a dropdown that they can manipulate directly.

[aloverso]

@skeeJay that's definitely a fair point. It sort of raises the question of who we should be designing for - the user who's using it "correctly" and wants the roadmap to show In-Progress when they go looking for the their application, or the "confused" user who misinterprets the function of the form.

[skeeJay]

@aloverso In my view, for any user, the most straightforward and predictable interface is the one with the clearest rules. If a Task's status is manual, it is always controlled directly by the user. If a Task's status is automatic, it's always controlled by a user's status in a government system. A user will be able to understand the fact that the government system might be "wrong" or slow… but there are a lot of ways it can cause confusion if we try to create a Task status that is "manual" (by a different mechanism than other manual Tasks) when it changes to "In Progress" but automatic when it changes to "Completed." To me, that's sacrificing the user's mental model of the system to try and be predictive.

[guy-nj]

Thanks EJ's that scenario is a better speaking about the confusion when the user hasn't done anything with Consumer Affairs's application but seeing In Progress status. Ideally the status of "Task" and "Applpication" should be essentially the same. But our mvp restriction gives a bit tricky unsync between these two.

If we change the copy "Submit" to "Look Up My Application", would that be more clear and prevent the user mistaking the check-status form for application form?

[skeeJay]

@guy-nj For a couple of reasons this had to be deployed to staging already, but want to give you the opportunity to review this from a design perspective and we can create new tickets for any bugs you discover.