`Enrollment index`: Update for CalFresh

[thekaveman]

This page will be substantially different from other flows for CalFresh eligibility.

Full page

Informational Alert component

Figma links

• Enrollment index page (Desktop)
• Enrollment index page (Mobile)
• Information Alert component

Acceptance Criteria

• [x] Headline and first paragraph remains the same.
• [x] Remove the “Please use a debit and credit card by Visa or Mastercard.” paragraph that is in the other flows’ screens.
• [x] New component - Alert box (Informational alert), links to the same CalFresh modal from #1918
  • [x] Space between bottom of media item and top of alert box: 48px
  • [x] Space between bottom of alert box and call to action button: 64px
  • [x] Bottom margin of alert box heading: 4px
  • [x] Background yellow: #FFF1D0
  • [x] Border yellow: #FDB714
  • [x] Link: #045B86
  • [x] Link focus ring: #045B86
  • [x] Border width: 8px
  • [x] Left padding from border to text: 16px
  • [x] Right padding from text to edge: 16px
  • [x] Top/bottom padding from text to edge: 16px

[thekaveman]

Starting to get into this and one immediate question that comes up:

How to override the enrollment:index template for CalFresh?

Background

We typically override templates by storing the name of the template to use on a particular model. Today we have:

• AuthProvider stores its sign_out_button_template and sign_out_link_template for defining those UI components
• EligibilityVerifier stores the selection_label_template and start_template for defining the eligibility phase
• TransitAgency stores an index_template and help_template for its own homepage and help page, an eligibility_index_template for the beginning of its eligibility phase, and an enrollment_success_template for the end of its enrollment phase

Options

I can see 3 options for how to override the enrollment:index template:

• PaymentProcessor: I actually don't think this will work, since each agency only has a single payment processor instance, and we need this template to be specific to the flow -- including for posterity
• EligibilityVerifier: this would work in the sense that we typically create a verifier per flow, but it sort of feels wrong though? Since we're talking about enrollment specifically, which is entirely outside of the eligibility phase
• EligibilityType: of the options, this is the one that makes the most sense to me. We already store some enrollment information here (e.g. group_id and the expiry fields), and of course this is the most specific in terms of the flow, i.e. we always have a new instance for each flow.

@angela-tran am I missing any options here? Any thoughts on the above options? Can you think of another way we might want to override this template that doesn't involve a model field?

[angela-tran]

@angela-tran am I missing any options here? Any thoughts on the above options? Can you think of another way we might want to override this template that doesn't involve a model field?

I agree that it makes the most sense to store it on the EligibilityType. Since the message is specific to the flow, our only options are either EligibilityVerifier or EligibilityType, and it does seem wrong to put enrollment information on the verifier.