cagov / ui-claim-tracker

This repo contains the Claim Status Tracker app, which helps Californians better understand what’s happening with their unemployment claim and benefits.

Claim Status Tracker

This repo contains the Claim Status Tracker app, which helps Californians better understand what’s happening with their unemployment claim and benefits.

Run the application

Prerequisites:

• Node 14 LTS
• yarn

Run this app

1. Clone this repo
2. Run yarn install
3. Define environment variables (see below)
4. Run yarn dev
5. Open http://localhost:3000 with your browser to see the result

Environment variables

• ID_HEADER_NAME: The name of the header that contains the EDD-defined unique ID / "Unique Number" in the incoming request
• API_URL: The url for the API
• API_USER_KEY: The user key for the API
• CERTIFICATE_DIR: The path to the client certificate (certificate must be in PFX/P12 format)
• PFX_FILE: The name of the client certificate file
• (Optional) PFX_PASSPHRASE: The import passphrase for the client certificate if there is one
• (Optional) Environment-specific path prefixes for UIO and BPO links
  • URL_PREFIX_BPO
  • URL_PREFIX_UIO_CLAIMSTATUS
  • URL_PREFIX_UIO_DESKTOP
  • URL_PREFIX_UIO_MOBILE
• ASSET_PREFIX: The static asset path (default is /claimstatus; this env var is required for local development)

For local development:

1. Create a .env.local file in the root of this repo
2. Define each of the environment variables above
   • Obtain a preconfigured .env.local from an existing developer
   • Set ASSET_PREFIX to ""
3. Configure a test header
   • Configure ModHeader (firefox/chrome) to send the ID_HEADER_NAME defined header value to the local dev environment - see Vault for value. Also, we recommend limiting ModHeader to only modify localhost:3000
   • Please add developer_test=YOUR_NAME as an additional header to make it easier to distinguish ModHeader queries

Run the test suite

yarn test

or interactively:

yarn test:watch

Update the snapshots

yarn test:update-snapshots # or yarn test -u

Lint the code

You can manually run the linters:

yarn lint

Changed files are auto-linted on commit.

Set up your editor to automatically lint on save

Run Storybook

To develop or preview our front end components start up the Storybook server:

yarn storybook

ui-claim-tracker's Issues

Setup linting

Description

Integrate ESLint into the UI Claim Tracker application.

Acceptance Criteria

• Integrate ESLint into our project
• Setup a precommit hook to run it automatically
• Document setup in our Technical Foundations doc

Should we use Typescript instead of Javascript (ES6)?

Task

We need to decide whether we want to use Typescript in this repo instead of Javascript

Details / Context

Acceptance Criteria

• Update Claim Tracker Technical Planning doc with research, decision, and justification

Document accessibility requirements

Task

Document accessibility criteria that we are required to meet

Details / Context

• Requires collaboration between engineering and design
• A lot of content already exists in the draft EDD Web Development Standards document

Example EDD Web Development Standards section on accessibility:

Digital content such as websites, documents, and applications must be designed, developed, and tested with accessibility in mind to ensure equal access to people of varying capabilities. Assembly Bill 434 directs all state entities to comply with California Government Code Section 7405 and Section 11135 and the Web Content Accessibility Guidelines (WCAG) conformance level AA and to certify every two years that their public-facing websites are accessible. Section 7405 requires compliance with the accessibility requirements of Section 508 of the federal Rehabilitation Act of 1973, which uses WCAG as the required standard. EDD’s current standard is to adhere to WCAG 2.1 AA requirements.

Acceptance Criteria

• CA UI Claim Tracker team has documented our required accessibility obligations
• Team has discussed how to meet those obligations throughout the project lifecycle

Set up CosmosDB integration and .env

Description

• Set up integration with CosmosDB in staging env (take a look at last year's repo as a guide)
• Setup a .env file with needed secrets for development and update the one in "CA UI Eng sensitive" vault

Acceptance Criteria

• Application should be able to write to CosmosDB; include some tests

Document screen reader basics and share with team

Task

Document and demo some basic screen reader commands so the team knows how to do simple testing for hierarchy and comprehension.

Acceptance Criteria

• Document how to get started with screen reader testing (building on WebAim and Sawyer's work on PFML)
• Ticket any next steps

Review Nava's status content with stakeholders

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Add Storybook framework

Description

Integrate the Storybook componenet development tool into the UI Claim Tracker application.

Acceptance Criteria

• Integrated Storybook into the project base
• Document choices in our Technical Foundations doc

Identify high level questions for web content and policy stakeholders

Task

Document high level questions from initial review of content; bring questions to content stakeholder meeting

Details / Context

See design question doc for running question list

Acceptance Criteria

• Running question doc created and filled out

Draft a product vision statement

Task

Draft a product vision statement based on input from kickoff. Share and/or facilitate feedback from the team.

Acceptance Criteria

• Product vision statement has internal alignment from team and is ready for review and alignment with CA stakeholders

What database should we use?

Description

Research and decide what database we should use

Acceptance Criteria

• Update Claim Tracker Technical Planning doc with research, decision, and justification. Include the database we'd like to use in our request to CDT when setting up the new environment

Create claimant research plan for one status

Sprint X

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Write initial tech spec for BPO integration

Description

Write a tech spec for integration with BPO such that a user logged into UIO can navigate from UIO to our page without being aware of the transition. We'll need to work with the BPO and IDM teams to flesh out the details in this tech spec. We sent a Oauth version last year but they were starting to build a proof of concept in SAML 2.0 before we paused, so that's probably the direction they'll end up going in.

Acceptance Criteria

• Have tech spec reviewed by eng team, then send to BPO / IDM team for approval

Write a planning doc for IDM integration

Description

The planning doc should include a mini tech spec and a proposed timeline

The end goal is to allow logged-in claimants to seamlessly transition from UIO to a CDT Azure-hosted Claim Tracker page, and back, on production, before the MVP release in 2.5 months

The ideal timeline on our end is: "The BPO integration and Azure read access to UIMOD will be working in test environment, with a plan for prod implementation in April; security approvals of both will be initiated." But should accommodate whatever we learn about the BPO/IDM team's capacity this week.

Acceptance Criteria

• Share planning doc with internal team and EDD

Draft archetypes + moments that matter

Details / Context

Should include what we know about the user journey, systems, processes, and status triggers

Acceptance Criteria

• Blueprint have been created in a format that can be reviewed CA EDD stakeholders and used to inform scope conversation

Create usability testing interview guide and note-taking documents

Details / Context

Set up the infrastructure required to conduct usability testing.

As a requirement, the scope of what we are testing should be clearly defined. (#85 Recruiting plan)

Acceptance Criteria

• Create interview guide (link)
• Create note-taking template (link)
• Create schedule sign-up for observers (link)
• Create observation document (link)

After creating moderator guide, #22 Recruit.

Draft logic model for claim tracker impact

Task

Create claim tracker impact logic model

Details / Context

Create an input/output/outcome/impact logic model as a tool to identify the right metrics for measuring outcomes and impact.

Acceptance Criteria

• Logic model created and reviewed by product/design/engineering
• Associated metrics documented

Decide and document approach to using UIMOD as source of truth

Description

Work with ITB and ODI to determine the preferred approach to reading from UIMOD as the source of truth. Two options include 1) executing stored procedures on UIMOD directly via an Azure hybrid network, and 2) ITB building an endpoint for Claim Tracker that executes the relevant stored procedures(s).

Acceptance Criteria

• Have ITB approve an approach with enough fidelity for us to write an initial tech spec detailing the approach

Draft claim status content for usability testing

Task

Iterate on claim status database based on feedback and secondary research

Details / Context

Acceptance Criteria

• Claim status database content is ready to be tested with claimants

Add the Bootstrap design system

Description

Integrate the Bootstrap design system into the UI Claim Tracker application.

Acceptance Criteria

• Integrated Bootstrap & bootstrap-react into the project base
• Document choices in our Technical Foundations doc

Setup accessibility scanning on Staging

Description

Setup Google Lighthouse to scan our Staging environment after each PR is merged to main & deployed.

Acceptance Criteria

• Request from CDT to setup Google Lighthouse to run on staging
• Results of the scan are sent to the teams engineers
• Document setup in our Technical Foundations doc

Gather claim status query data (call centers)

Task

Request data from CA EDD: requests or questions from claimants related to claim status

Details / Context

This might include:

• No. of calls to CA EDD call centers related to claim status
• Time spent on CA EDD call center calls related to claim status
• Relative to # of open claims
• Relative to all calls (as a percentage of calls)

Acceptance Criteria

• Data has been requested and received (if it exists)

Choose and integrate a test framework

Description

Integrate a test suite harness into the UI Claim Tracker application. By default we are leaning towards Jest and Enzyme like our previous project, but we should do a bit of research if there is some NextJS bonus or other best practice that has emerged.

Acceptance Criteria

• Confirmed Jest is a reasonable choice for our project
• Integrated Jest & Enzyme into the project base
• Document choices in our Technical Foundations doc and README

Gather claim status system data

Task

Request claim data from CA EDD

Details / Context

This might include:

• Customer satisfaction
• Measures of customer sentiment
• Visits to the claim status page vs other pages
• Drop off points / bounce rate

Acceptance Criteria

• Data has been requested and received (if it exists)

Identify and review existing status content / identify gaps

Details / Context

• Review status work from past task orders
• Identify questions for the team and gaps in current information

Acceptance Criteria

• Team understands existing content artifacts
• Questions are documented for collaborative session with CA EDD stakeholder

Validate service blueprint with client

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Refine claim status documentation

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Choose and integrate an internationalization library

Description

Integrate a translation library into the UI Claim Tracker application. By default we are leaning towards i18next-react like our previous project, but we should do a bit of research if there is some NextJS bonus or other best practice that has emerged.

Acceptance Criteria

• Confirmed i18next-react is a reasonable choice for our project
• Integrated i18next-react into the project base
• Document choices in our Technical Foundations doc

Gather requirements based on UIMOD data fields and handling

Task

Coordinate with EDD to understand UIMOD fields and data handling (e.g. update cadence), and validate status mappings.

Acceptance Criteria

• Business logic/requirements related to UIMOD data fields is documented (in the product brief or a linked document)

Should we use Next.js instead of our previous Node/Express/Webpack setup?

Task

Work through the Claim Tracker Technical plan NextJS section and make a call for our existing system or moving the NextJS

Details / Context

See Claim Tracker Technical Planning

Acceptance Criteria

• We have chosen our framework

Choose and integrate an accessibility scanner for development

Description

Integrate a accessibility scan harness into the UI Claim Tracker application. By default we are leaning towards eslint-plugin-jsx-a11y like our previous project, but we should do a bit of research if there is some NextJS bonus or other best practice that has emerged.

Acceptance Criteria

• Confirmed eslint-plugin-jsx-a11y is a reasonable choice for our project
• Integrated eslint-plugin-jsx-a11y into the project base
• Document choices in our Technical Foundations doc

Obtain documentation of claim statuses in UIO

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Task [template]

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Coordinate with EDD to understand required pre-launch testing/review processes

Task

Find out what's involved in required pre-launch testing/review processes (e.g. accessibility testing, usability review, user acceptance testing, security assessment and authorization) -- especially timelines.

• @dianagriffin will take point on confirming process/expectations for security assessment (Todd Ibbotson) and UAT (Alex/Al)

Acceptance Criteria

• Process/expectations identified for security assessment and UAT
• Required pre-launch testing/review processes have been incorporated into our MVP delivery plan.

Update Claim Tracker product brief

Task

Update the CT product brief to a state where it can be shared with CA for feedback/approval

Details / Context

Building on the WIP product brief started here, update based on current thinking, priorities, and inputs.

Acceptance Criteria

• Product brief has been filled in and has internal team alignment. Ready for CA stakeholder review.

Integrate Azure application monitoring and set up alerts

Description

Integrate Azure Application Insights (see last year's repo for how we did it)

Setup monitor services on the Azure system (CPU capacity, 500 errors, and failed app services) and subsribe the engineers to the alerts.

Acceptance Criteria

• Request from CDT: Alerts are set for the system on the appropriate environments for the application
• File ticket for near the end of dev to audit which alerts we want for production
• Document choices in our Technical Foundations doc

Review existing blueprints of user journey

Details / Context

• Review existing unemployment insurance blueprints ODI and related documentation.
• Identify gaps in claimant journey, internal processes, systems, and status triggers.
• Document questions related to the blueprint and prioritize them.

Acceptance Criteria

• Teams understands current state of existing service blueprint artifacts
• Questions are documented for collaborative session with CA EDD stakeholders

Work with CDT to set up our initial infrastructure in Azure

Description

We need CDT to set up new environments for us in Azure (test, staging, and production, though we only need staging at this point.) Last year we only had staging and production, which made it tricky for us to enable EDD to test over several days in an environment that wouldn't change.

• Deploys to staging should trigger upon merging a commit to the main branch
• Deploys to test should be manual.
• Deploys to production should be automatic each morning at 9AM ET from the staging environment, but this will likely need to be changed to manual prior to launch.

Acceptance Criteria

• Must be able to deploy application to staging
• staging env should be set up by CDT, integrated with this repo, and include the same set-up-by-CDT features as cagov/unemployment. Current environments should be documented in the technical foundations doc, as well as tickets created for other environments not yet created, if necessary

Coordinate planning and implementation of linking between Claim Tracker and UIO

Task

Coordinate planning for user flows/linkage between Claim Tracker and UIO.

A user needs to be able to move between the UIO homepage and the Claim Tracker.

Dependency: Defining launch strategy

Acceptance Criteria

• There's a clear design for the changes that need to be made on UI Online (button)
• There's a clear method for users to navigate to UIO from the Claim Tracker.

Accessibility checkin

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

Note When you create this issue, remember to add:
an assignee
a label for story points estimate (or comment at the assignee to request that they add an estimate)
a label for priority
the project, so that it will show up in our kanban view

Write discovery sprint brief

Define desirable claim tracker metrics

Task

Define ideal metrics to measure claim tracker impact.
Identify where the data might exist and find out who to request the data from.

Details / Context

This might include:

• New measure: Did this page resolve your question about claim status? (Anticipate up to 3 months to make a change in UIO)

Acceptance Criteria

• [Acceptance criteria here]

Figure out how we want to use browser analytics

Description

• Ideally we'd get a baseline for whatever we want to measure changes in
  Setup Google Analytics. See implementation details from the unemployment repo, and coordinate with EDD/CDT to confirm configuration details.

Acceptance Criteria

• Document where we want Google Analytics events set up on both UIO and Claim Tracker (work with product/design)
• Results are sent to CA partners as directed
• Document setup in our Technical Foundations doc

Integrate automated browser tests

Description

Integrate an automated browser test suite harness into the UI Claim Tracker application.

Acceptance Criteria

• Integrate Selenium into our project
• write a simple proof-of-funtion test
• Document setup in our Technical Foundations doc

User Story [Template]

User Story

As a ______, I want to _______ so that ________.

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Set up content stakeholder meeting

Task

Identify the appropriate content stakeholders and arrange initial meeting to review content status database

Details / Context

May include PAB/WCUG, but could also include relevant legal and policy stakeholders and people who are concerned about communication and fraud

Acceptance Criteria

• Meeting is scheduled and held

Summarize accessibility requirements from WCUG

Task

Start to understand accessibility requirements for claim tracker, specifically as documented by CA

Acceptance Criteria

• Review WCUG documentation for a11y requirements that apply to our project
• Document these requirements and related opportunities for research/testing

Document accessibility check-in criteria

Sprint 2

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Create and execute S4 recruitment plan

Task

Prepare to conduct outreach and create pool of screened users to test with for both rounds 1 & 2

Details / Context

Research participants need to have used the unemployment system within the past year (January 2020 - present). Ideally, we would recruit from a wide variety of dis/abilities and language.

Acceptance Criteria

Recruitment

• Participant pool and sample criteria is developed
• Screener finalized
• Channels for outreach identified
• Write email to follow up for participants from existing database
• Send email to participants
• Write Craigslist Posting
• Post Craigslist call for May research

Identify the content, policy, and legal points of contact for content review

Task

[Describe what needs to be done]

Details / Context

[Add additional information that helps clarify the requirements for this issue]

Acceptance Criteria

• [Acceptance criteria here]

Note When you create this issue, remember to add:

• an assignee
• a label for story points estimate (or comment at the assignee to request that they add an estimate)
• a label for priority
• the project, so that it will show up in our kanban view

Setup securely shared .env file

Description

Setup a .env file with needed secrets for development and share via the "CA UI Eng sensitive" vault

Known envs:

• cosmo connection details

Acceptance Criteria

• development secrets shared securely
• Document setup in our Technical Foundations doc