Homepage: Implement design iteration for next round of Veteran research

[wesrowe]

Description

Updated design: Desktop: https://www.sketch.com/s/3aa40506-4be2-46cc-876b-93f1a9f3a857/v/mqqkog/a/oYGg9Wx/

• Copy edits to happen week of 9/12. Don't worry about exact text yet, just markup / styles / images. We'll finalize text in Sketch, then prompt for update in the code.

Mobile: NOT YET PROVIDED (9/12). Will be provided after copy edit

POINTS ARE APPROXIMATE for purpose of placeholding until designs are in hand.

As a Veteran, I want to try executing several common tasks using the latest version of the home page design so that I can help the VA determine if it's ready to release.

Changes Punchlist

Top concerns:

1. 508, semantic markup
2. Parity with designs. 2nd pair of eyes design review with Wes and/or Jill required internally before we hand off as complete / ready for UAT

Homepage hero -> "Benefit spotlight":

Prototype update (new 9/16):

Design comparison


• [ ] Area currently occupied by Sign in/create account button will be replaced by new pattern (The PACT Act and your VA benefits).
• [ ] Header copy will visually be H1 but will marked up as an H2. (this still in accessibility discussion)
• [ ] Page will have invisible H1 announced to screenreaders, We'll review with 508 folks what semantic markup should be for each of these. (this still in accessibility discussion)
• [ ] Style to match, and know that semantics may change later.

• [ ] In some cases: the 3 veteran images in current prototype will replace the new "PACT Act and your VA benefits" pattern. We don't have notes yet on the logic for when these will show, and this state isn't represented in the comps yet. So it shouldn't show for update to prototype (afaik), but don't delete the code completely.

• [ ] (updated 9/16) Login hero: will become "Create account" area similar to what is currently displayed on the left but button in a small div floated right. "Get access to the tools you need to manager your VA benefits and care" heading with "Create account" button

• [ ] Gradient switches to darkest right to left

Search & Tasks block

Search:

• [ ] Search button switches from magnifying glass to Search text
• [ ] (Updated 9/16) Other search tools: now 3 prompts, float left, add icon indicator
• [ ] Background from lightest gray to light blue

Common tasks:

• [ ] Header becomes "Popular on VA.gov"
• [ ] Will display 10 links in 2 columns of text. Intent is to decrease the number of links over time.
• [ ] Link text determined as of 9/16
• [ ] Links to come

OPIA blog promo block

Promo design comparison _(new 9/16)_


Prototype updates:

• [ ] image update to 1:1 ratio, using new static image
• [ ] Add VA News subtitle (New 9/16: design adjusted the subtitled slightly from what is in Drupal - we should discuss this)
• [ ] New 9/16: link to full article follows VA News subtitle
• [ ] Title & teaser should be clickable. Image is not clickable. May consider an event to track attempts at clicking.
• [ ] "More from VA News" treatment is updated.
• [ ] Update to link styles in general.

Benefit Hub block

(updated 9/16)

New benefit block


• [ ] Order of benefits is updated to match megamenu order (NOTE: this may be a Drupal operation)
• [ ] New as of 9/16: Benefit hub blurbs have changed compared to prototype/prod
• [ ] New as of 9/16: New hub for "VA Department information" with new icon
• [ ] New as of 9/16: diminished white space between hubs and Veteran portraits is not yet reflected on Sketch)

New section pre-footer

(updated 9/16)

New area


• [ ] email signup, similar to pattern on form on https://choose.va.gov/ New 9/16:

  <form class="usa-form display-flex flex-row flex-justify align-center width-mobile tablet:maxw-mobile-lg" id="email-capture-form-main" action="https://public.govdelivery.com/accounts/USVACHOOSE/subscribers/qualify" accept-charset="UTF-8" method="post">
      <input name="utf8" type="hidden" value="✓">
      <input type="hidden" name="category_id" id="category_id_top" value="USVACHOOSE_C1">
        <label for="email-capture-test1" class="usa-label text-no-wrap text-middle margin-right-2 usa-sr-only">Email Address</label>
        <input class="usa-input margin-right-0 margin-top-0 maxw-card-lg" id="email-capture-test1" type="text" name="email" placeholder="Email Address">
        <input type="submit" name="commit" value="Submit" class="usa-button margin-top-0 height-5 radius-left-0 maxw-15">
      </form>

• [ ] For prototype/UAT, users won't be tested on this, form does not need to submit.
• [ ] New 9/16:Form should validate email address format and notify user of error before submission (may need accessibility input on this)
• [ ] Veteran images now with blue background
  • NOTE: This row of Veteran images is in the current Prod version of the homepage but was cut from the prototype

Acceptance Criteria

• [ ] Design changes implemented on FE
• [ ] Copy changes implemented on FE
• [ ] 508 concerns addressed / header levels complete
• [ ] Requires design review with Wes & Jill to compare Sketch to prototype locally before merge to Staging

CMS Team

Please check the team(s) that will do this work.

• [ ] Program
• [ ] Platform CMS Team
• [ ] Sitewide Crew
• [ ] ⭐️ Sitewide CMS
• [x] ⭐️ Public Websites
• [ ] ⭐️ Facilities
• [ ] ⭐️ User support

[wesrowe]

@mmiddaugh, FYSA this issue will be a placeholder in the sprint starting Monday.

[jilladams]

@apisandipas We got a preliminary look at the design update, not finalized, but this is approximate scope. https://www.sketch.com/s/3aa40506-4be2-46cc-876b-93f1a9f3a857/v/mqqkog/a/oYGg9Wx/ Copy edits will happen to this, so don't worry about text for now, only markup / style / image changes. Copy will get finalized later this week and come back to us in finalized file. Same with header levels. Match for style, and the actual semantic header levels will get established in a review with 508 folks, and indicated in the file a little later.

Top concerns:

1. 508, semantic markup
2. Parity with designs. 2nd pair of eyes design review with Wes and/or Jill required internally before we hand off as complete / ready for UAT

Homepage hero:

Prototype update:

• [ ] Header copy - semantic header / visual treatment won't match. We'll review with 508 folks what semantic markup should be for each of these. Style to match, and know that semantics may change later.
• [x] Login hero: will become "Create account" button, move into a small div floated right
  • [ ] In some cases: the 3 veteran images in current prototype will still show. We don't have notes yet on the logic for when these will show, and this state isn't represented in the comps yet.
• [x] Gradient switches to darkest right to left

Final:

• Drupal content - governance should expire homepage content. (TBD)
• Long-term: the live homepage-news section will move to the top, reduce to 1 promoted item, no graphic (text only). Adds a call to action link / text. We need to ask more questions about this.

HUB

Search:

• [x] Header = serif
• [ ] Search button switches from magnifying glass to Search text
• [x] Other search tools: now only 2 prompts, float left, add icon indicator
• [x] Background from lightest gray to light blue

Common tasks:

• [x] Header = serif
• [x] Header becomes "Popular on VA.gov"
• [x] Becomes 2 columns of text

OPIA blog promo

Prototype updates:

• [x] Header = serif
• [x] image update to 1:1 ratio, using new static image
• [x] Add VA News subtitle
• [x] Title & teaser should be clickable. Image is not clickable.
• [x] "More from VA News" treatment is updated.
• [x] Update to link styles in general.

Final:

• Long-term Intent: convo with OPIA to ensure that images do not include rendered text
• Content comes from homepage-news content in Drupal:
  • needs governance
  • Teaser text needs Drupal thinking around truncation / character limits. SWC / Design will provide guidance. Won't be enforced in the CMS technically, but will/should provide guidance about char limits in helptext.
  • We'll need to talk about how to manage featuring homepage news both in hero area and this area.

Homepage benefits:

• [x] Header = serif
• [x] Order of benefits is updated to match megamenu order

New section pre-footer

• [x] email signup - form exists like this on https://choose.va.gov/ . We don't have code access to that form, just need to mimic it. For prototype/UAT, users won't be tested on this, form does not need to submit.
• [x] Veteran images now with blue background

Final:

• Need to understand form action

FYI @ryguyk @wesrowe . If you have edits to this please directly edit my comment so Bryan has 1 place to look, vs. trying to merge in his mind.

[jilladams]

Target for turning these around in the prototype is by end of sprint, 9/23. @apisandipas it's a big bite. Feel free to proactively schedule time with whomever you'd like to talk to, to get this moving.

[mmiddaugh]

Content finalized with Danielle on 9/15 and reflected in Sketch. New screenshots and other changes are noted in body of issue

[cindymerrill]

Will the 2 accessibility fixes being made to the VA Benefits and Health Care megamenu (in the header) also be made to this design iteration in Staging?

[jilladams]

@cindymerrill re: #10678 : The health care megamenu change is in code review but we need to test the injected header use case before that merges. So: once that change merges, yes, it will propagate to Staging. Bryan is working both tickets, so prototype changes will come first.

I am not recognizing the VA Benefits reference - do you have a ticket number for that? In general: any change that ships to prod will also apply to Staging, unless we've done specific work to prevent that.

[cindymerrill]

@jilladams Both accessibility issues concern the "VA Benefits and Health Care" megamenu. "VA Benefits" isn't a separate issue :).

[apisandipas]

@mmiddaugh The proposed design for the Search Input has a few conflicts with the existing VA Design System Search Input Component.

1. Sizing - The existing component is 296px wide by 48px in height, while the proposed design includes a search component 280px by 37px. With the proposed mobile view having padding of 20px on each side, it's currently too large to fit on the smallest screen size of 320px.
2. Button Text - It's currently possible to add text to the button. However, the button by default includes a magnifying glass icon which doesn't appear to be optionally toggleable.
3. Responsive Layout - The current search input doesn't adjust it's layout on smaller screens as proposed on the design, where the button wraps below the input and becomes full width to it's container.

In most other cases I could typically override these styles in a targeted manner, however being that it's a web components residing in the, pardon the jargon, "Shadow DOM", it's styling is intentionally isolated from being overridden from the outside in such a way.

[jilladams]

@mmiddaugh from talking to Bryan about his notes, our options to address are:

1. Use the design system component as is, until these changes are integrated into the component. This is preferred from the team.
2. Write a custom module for search in the homepage body. Doable, more time needed (haven't estimated yet but can), and downsides are: maintaining custom code to keep parity with the design system component. Not optimal. If we opt to go this route, it would help to know if this piece factors into the next round of testing + governance reviews, in order to understand timing to complete it.
3. Try to override the design system styles by injecting CSS into the Shadow DOM using JS. This is not an existing paradigm, and is creating some tech debt for maintenance, as most engineers wouldn't look for CSS in JS. (Strongly not preferred by engineering, just documenting, since we discussed it.)

It would be good to understand from you & RyanT how critical he perceives these differences to be, and where we should invest effort in lining up with the design. (cc @wesrowe)

[wesrowe]

@apisandipas, fyi I added an H1 semantic markup to Sketch for the new "Welcome to VA" item at the top of the page.

[jilladams]

@apisandipas Talked through these notes with Michelle & Wes, notes:

1. Sizing - Michelle to clarify this with RyanT
2. Button Text - For now, use the magnifying glass + Search word. Michelle will follow up on this as well re: removing the magnifying glass, but we think we'll lean on the design system component.
3. Responsive Layout - We did find a case where the search button behaves on the live site as it is in the design. We'd like you to take a look at this, and see if it's possible to identify / use how that's working. to repro: On va.gov, if you search, land on search results, then the search input on the results page does show a la RyanT's designs: input over full width button, with both magnifying glass + Search text in button. e.g. https://www.va.gov/search/?query=test&t=false .

If that doesn't work, Michelle made note of the design component width + padding issues & will run that past RyanT (296px wide component + 40px total of left/right padding = > than mobile 320px-wide smallest screen). For now: if we can't get that stacked version on mobile, and you assume we're using the design system component, do you have any suggestions to make the mobile presentation work for now?

And an additional note: In designs, search box on Desktop has title "Search" and on mobile, "Search on VA.gov". @mmiddaugh to clarify with RyanT if that's intentional.

Re: deviating from design system component, Michelle noted she'll have to defend deviations to the Collab Cycle, so she'll take the Qs to RyanT and just confirm how much of this is high priority from design perspective, etc.

[mmiddaugh]

@jilladams @apisandipas Answers from Ryan:

Sizing - The existing component is 296px wide by 48px in height, while the proposed design includes a search component 280px by 37px. With the proposed mobile view having padding of 20px on each side, it's currently too large to fit on the smallest screen size of 320px.

• Question: Can we accommodate the component as is out of the box, a la design system?
• Answer: Absolutely. My advice would be to not use fixed pixel sizes (ever) and use CSS classes and the flexbox grid to dictate the width.

Heading label - In designs, the search box on Desktop has the title "Search" and on mobile, it’s "Search VA.gov".

• Question: Is this difference intentional? If not, which should it be?
• Answer: My mistake! It should simply be "Search". I have updated the Sketch file to reflect.

Button Text – The design system component has the magnifying glass, rather than the word “Search” as indicated on your designs. We found an example on the search results page which uses the magnifying glass and the word “Search” and are evaluating this to see if it is a design system component option. Responsive Layout – If we can use the implementation from the search results page, it will display as the input field over a full width button but the standard search component doesn't adjust its layout on smaller screens as proposed on the design.

• Question: Is the magnifying glass an acceptable label? Would you prefer the combo magnifying glass + “Search” (if we can use that one)? Or is there a particular reason that you selected “Search” alone?
• Answer: I would use whatever is easiest/conforms to the design system. I prefer the form field/button stack on mobile.

[jilladams]

Search results page is a separate React app so the button treatment there doesn't easily translate to the homepage. Might be a component we could add in. Will need to investigate effort.

To preview / review changes, will need both vets-website & content-build PRs to merge and deploy to Staging.

[apisandipas]

@jilladams In investigating the effort involved with using the search input implementation from the results page, I found that the implementation on the Result Page is large one very big components rather than one split into atomic components.

In experimenting with what I found I was able to copy the styles and plug in the functionality to the existing Home Page Search component. It's not a completely 100% match style-wise, but could be with some additional tweaking.

My main concern with this approach is I'm not 100% certain the typeahead suggestions will work as intended out of the box like this. I'm uncertain as this functionality doesn't appear to work in a local development instance. I feel confident that will some time, I could likely get this functionality working, if I were able to point the API_URL to a known working instance of the API endpoint and test against that, adding the missing pieces as needed.

Let me know if I should pursue this now, or if you think tackling it as a separate ticket next week would work best.

[jilladams]

Let's break it into a separate ticket and get the 2 open PRs moving toward Staging. Better to work it in parallel. (fyi @mmiddaugh )

I'll draft the ticket and pass it off to you to make more technically accurate and add points.