IA Tracker: WEAMS Comparison Tool migration

[scjwalker]

Overview

Description

Migration of functionality into the the GI Bill Comparison Tool or some other location dedicated to info about the cost of tests including licenses, certification, and national tests.
Give users access to info on what licenses/certifications/national tests they can be reimbursed for, and the cost.

Links

• CAIA Intake Ticket 92369
• Artifact: WEAMS Public Product Outline
• Artifact: WEAMS Public Mockups

Team

• Team name: Education Data Migration
• Product manager: Cassidy Beach
• Designer: Sneha Kulkarni
• Slack channel: edm-team

CAIA Staffing

• CAIA IA: Sam Walker
• Content: TBD

Timeline

• Design intent kickoff: TBD
• Midpoint: TBD
• Content review: TBD

---

IA Support

Work needed

• IA spec: [Needed]
• Feedback for product team: [Needed]

IA deliverables

Preview Give feedback

1. [IA spec]
2. Feedback

Acceptance Criteria

• Feedback is shared with product team in Intake Ticket.

[scjwalker]

Adding my recommendations here, for record-keeping, on the question of how to name institutions sub-pages:

I discussed with Sneha and Jen, and then also discussed in OCTO slack with Ariana.
Two options:

Adjust the breadcrumbs to include the institution name, rather than the current tool behavior of listing "Institution details" in the breadcrumb for each institution. Doing this means that the H1 of any sub-pages of the institution page should generally have lengths that are within the character limit.
The opportunities here are:
a) gives the tool breadcrumbs that are consistent with users' experiences across va.gov
b) brings the tool into alignment with VADS guidance on aligning H1s and breadcrumbs and how breadcrumbs
c) solves the H1 length issue in most cases.
The risks here are:
a) requires development time
b) if there are a few sub-pages with very long titles, the team would need to either define a pattern for shortening these or create one-off manual solutions for shortening those strings.

Retain the current breadcrumb structure, using "Institution details" for all institution pages, in which case institution sub-page H1s would likely list both the institution name and the title of the sub-page, to help the user stay oriented in the tool.
The opportunities here are:
a) provides solution #1 queued up in the backlog for a future team to pick up and implement as part of future work in the tool,
b) short-term solution that allows the team to not re-work the breadcrumbs as part of current scope.
Risks here are:
a) the tool's breadcrumbs, which are currently out of alignment with VADS breadcrumb guidance, would stay out of alignment.
b) H1s would also be out of alignment with VADS character counts guidance

The character limit for these pages is technically 52 characters.

I think option 1 would be the way to alleviate the issue, and that's what I advise. And also, I know that a lot of variables - including go-live timelines and engineering capacity - means that it's not always possible to do everything. Which is why, as part of option 2, I'd advise adding these changes to a future backlog if this isn't the time to implement them. My recommendation is check these two options with decision-makers so that Design has clear guidance on whether the scope can include adjusting the breadcrumb structure (which should solve most of the H1 length issue), or sticking with the current not-aligned approach for now and moving this change to the backlog.

[scjwalker]

On 1/9 I met with Sneha, Jen, and Cassidy to chat through a couple of questions in the Licensing & Certification part of the tool.

H1s and Breadcrumbs - Currently, sets of search results and sub-pages of search results are represented by the generic term "results" in the breadcrumb, and H1s and breadcrumbs do not contain the same content. I recommended a light lift within the current contract, of making sure the H1 and breadcrumb match but sticking to terminology like "Search results". I also recommended a more involved task (probably for the backlog), defining a pattern for how to describe a set of search results in a short string in an H1 or breadcrumb - so that search results can be described uniquely in the breadcrumb.

Description of no-digitized forms - I recommended replacing link text of "print form" with "download form" to make it consistent with how actions for non-digitized forms are described in the Licensing and Certifications benefit page, and in the Find a Form system. The team is planning to make this change in the current contract.

Capitalization in exam names - The team asked me about the best strategy for managing many thousand strings they're migrating in, which are variously in all caps, or a mix of all caps and title case. The engineering estimate of what's possible in the contract is that some cleanup is possible, but getting to everything is out of scope - this is partly because the data contains a lot of acronyms for professions (e.g. CPA), degrees (e.g. BA), etc. that should remain capitalized.
I recommended three things:

1. Define what's possible within the contract, along with a brief clear summary of why, and having that available for Governance meetings and project record keeping.
2. Collect all technical and design work on what a full solution to the issue would take, and document it for future backlogs.
3. Check with stakeholders whether any additional write-up of the issue would be beneficial to them, to include in future contract scopes.