Add "other" option to utility selector

[oyamauchi]

Description

Because we can't be sure that the API's set of utilities is 100%
comprehensive, or that its location-to-utilities mapping is 100%
correct, we should have an escape hatch, so users don't have to give
an answer they know is incorrect.

The "other" value is not submitted to the API because it's not a valid
utility ID and the API would thus error. I'm pretty confident that's
sensible behavior for the API, so I'd rather not change it. We'll be
able to tell when someone chose "other" in API logs, because the
utility param is absent in the /calculator request.

I'm not sure about this Spanish translation. It's "otra" (feminine)
because it's referring to the feminine noun "empresa" (company), which
is part of the translation of "electric utility". Anyone who knows
Spanish better than I do (i.e. most people), feel free to correct me.

https://app.asana.com/0/1206661332626418/1206700057950880

Test Plan

On a fresh page load, make sure the utility dropdown is not
clickable.

Enter a zip; make sure utilities load, the first one is selected, and
the "Other" entry is present. Submit the form with a real utility
selected and make sure its incentives come up. Choose "Other", submit
the form, and make sure no utility incentives come up, but state and
federal ones do.

Enter an invalid zip (00000) and make sure the utility dropdown is not
clickable and you see the error message below the field.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
embed-rewiringamerica-org	✅ Ready (Inspect)	Visit Preview	Apr 22, 2024 10:54pm

[oyamauchi]

I should note a couple more things:

• If you enter a zip that's in a non-covered state, you get only the "Other" option and the message under the utility selector that says "We don't have utility data for your area yet". It's a little weird to have an "other" option and nothing else.
• Not specific to this PR, but it's still the case that if you enter a zip and select a real utility, you still see the message "enter your zip to select a utility", which is also a little weird: you already did that. To me the most obvious thing is to remove the message entirely, but that would change the spacing of the form fields and maybe look janky?

[oyamauchi]

Waiting on this until we expose utilities for all states including non-covered ones.

[veekas]

"Otra" makes sense to me!

[oyamauchi]

I've done a new thing here, updating the logic of what to display as helper text. Previously we'd display "Enter your zip code to select a utility" even after the user had done both of those things. This replaces it with:

• Error message if there is one
• Same as before if no zip has been entered
• blank help text while loading
• blank help text if a non-Other utility is chosen
• Continue to see other incentives if Other is chosen

The blank help text is one of several non-ideal options, which are:

• Allow blank help text, maintain the vertical space for it. This causes uneven spacing between rows when the text is blank.
• Allow blank help text, collapse the vertical space. This causes the entire page below to reposition as the text appears and disappears: very janky-looking.
• Don't leave vertical space for the help text ever. This looks terrible when the text is present.
• Don't allow blank help text; make up some copy for the blank cases. Doesn't feel great because it would be non-actionable in the loading and non-Other-selected cases.

This code implements the leave-space option. Here's what it looks like:

Blank text:

Populated text (the ZIP is Puerto Rico):

Blank text on narrow layout:

[RandomEtc]

I think "Other" can still be considered to be on the happy path, it may give the user a moment of pause but hopefully they just move onto the next field. I think the helper text could be blank in that case?

But I'm also OK with where we're headed as-is, it seems to be a material improvement vs losing people when they don't "see themselves" in the options.

One thought re: layout for Emiola when he's back, perhaps our forms need to leave space for helper text on all fields by default always? That might be too much whitespace, but it might be preferable to redoing layout and preferable to uneven looking forms. Probably one for the longer term Design System conversation though. Also noting we cannot be alone in trying to solve these problems (though the embed constraint does mean we can't make the form multi-step easily, which is what we'd probably do in an app context).

[RandomEtc]

Re: "We don't have utility data for your area yet." - I'm personally not sure if we ever need to say this. It might be better to push that to a footer status or some other area of the page, if we draw attention to it at all. I would focus on getting the user through the form with the most accurate representation of their current status, and then we can focus on improving data coverage for them.

One other thought is that we might want to feature flag or A/B test this, if we're worried it would make conversion worse. But I have a strong hypothesis it will make conversion better, I'm happy to go with gut on this to keep us moving. (Famous last words ha)

[oyamauchi]

The "we don't have utility data" message will now only show up for territories, and we can fix that pretty easily (AFAIK each territory only has one utility; we can hardcode it in the API).

The idea of removing the help text in the "Other" case makes me think of another alternative:

• In the initial state, put "enter your ZIP code to select a utility" as the placeholder, and don't have help text
• Have help text only in the error case (which should be very rare, especially if we add utilities for territories)
• Collapse the space if there's no help text (which is the vastly common case)

I feel like it goes a little bit against the spirit of placeholder text, but it's something to think about.

Anyway I'm going to go ahead with what I've implemented here for now (blank text allowed; uneven spacing in blank case. Keeping the "continue" copy in the Other case because that's what Emiola spec'd).