SPIKE: Address potential challenges around homepage soft launch modal

[wesrowe]

Description

Before implementing #11535, we need to understand the mechanics around a few UX/tech risks:

• AUDIT: Competing modals on VAgov – there is already a modal that appears for users redirected from explore.va.gov. We need to see how/where that modal is coded and determine a way to prevent our modal from displaying in that use case.
  • Desired behavior: No other VA.gov modals should appear on page load
  • NEW ISSUE: get rid of exploreVA modal
• Injected header/footer – we need to understand how modals like our soft-launch modal are handled in injected-header/footer scenarios and thus how to ensure it doesn't display anywhere except the actual VAgov homepage
• "don't show me modal twice in on session" logic – if there is any doubt among the team how we would implement a cookie to prevent re-displaying the modal within a single user session, now is the time to explore that. Possible questions relate to:
  • Governance: do we need any other team's buy-in to add a cookie?
  • Do we understand how to define a "user session" in this context? What are our options? (e.g., time-since-interaction, 24 hrs, etc)

Acceptance Criteria

• Document findings for all three areas in this ticket
• Review Redesigned homepage - soft launch modal #11535 for compliance with findings

CMS Team

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

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

[ryguyk]

Findings

The most important finding coming out of this spike is the discovery of an existing framework for "Announcements". The framework allows for the creation of announcements via a config file. Here is that file at the time of this writing.

This framework gives a foundation to discuss how to proceed with each of the three areas/questions of interest outlined in the ticket description:

1. Other modals

   • Audit competing modals on VAgov
     • The config file as it currently exists contains only one entry. This would conflict in certain circumstances, but it's set to be removed (see "Remove explore.va.gov modal" below).
     • Notably, the existing framework allows for the definition of relatedAnnouncements that can be dismissed automatically when the main announcement is dismissed. If necessary, this feature could be utilized to implement a sort of "hierarchy". I don't think this should be necessary given the current absence of any additional announcements.
     • There remains the possibility that competing modals would be defined in a separate fashion, but none of those were discovered in this spike.
   • Remove explore.va.gov modal
     • The config file, as it currently exists, defines only the existing modal for the redirect from explore.va.gov. Removing it amounts to removing that entry from the configuration. This is straightforward and has its own ticket here.

2. Injected header/footer – we need to understand how modals like our soft-launch modal are handled in injected-header/footer scenarios and thus how to ensure it doesn't display anywhere except the actual VAgov homepage

   • This is a non-issue. The injected header/footer is unrelated for a couple of reasons. First, the code for this announcement framework is not injected. Second, the configuration for a homepage modal should explicitly define the homepage as the desired path. It should not fire on any other pages.

3. "Don't show me modal twice in on session"

   • This is the thing that will require some iteration on the current framework. The current framework defines a boolean config property called showEverytime that allows for only two states:
     • When false: dismissing the announcement triggers a save to localStorage indicating that the announcement in question should never be shown again.
     • When true, dismissing takes no such action. Nothing is saved to localStorage.
   • This will need to be expanded to allow for a third state (via storage to sessionStorage). My recommendation is to change this from a boolean to a string/enum field called, more simply, show, with the following options:
     • once
       • Dismissing will hide forever (or at least until a user empties localStorage).
       • This is the equivalent of the currently implemented showEverytime: false.
     • every-page-load
       • Dismissing will hide announcement but it will show again on subsequent page loads.
       • This is the equivalent of the currently implemented showEverytime: true.
     • once-per-session
       • Dismissing will hide until the next time a user visits (in a new tab/session).
       • This is the essence of the necessary iteration.
         • We'll need to implement the fetching from and saving to sessionStorage in addition to the existing fetching from and saving to localStorage. Announcements that have been previously dismissed will be spread between these two entities depending on the configuration for each as it relates to the newly suggested show property.
         • One important thing to note is that the existing implementation does not access localStorage directly. Instead, there is an abstraction that implements a check and fallback in the event that the browser does not allow access to localStorage. In this case, a fallback tries to use any storage that's available. This is fine for an implementation that simply wants to store something "forever". In our new case, though, a fallback for sessionStorage doesn't really make much sense. We'll need to decide how we want to proceed if a user's browser does not allow access to sessionStorage. Would we want to show the modal on every page load or dismiss it once and for all? My recommendation would be to show on every page load. We would rather give a user more opportunity to visit the new homepage rather than remove that forever. In addition to it seeming like the right solution, it's also the easy solution. Showing on every page load amounts to simply not taking any action (saving to web storage) when the user closes the modal.

[jilladams]

Great write up, @ryguyk . After tomorrow's meeting to review, @wesrowe we need to decide if #11535 should encompass both the build of the modal and the session logic, or if refactoring the session logic needs/warrants its own ticket.

FYI @mmiddaugh re: findings above. Michelle currently isn't invited to the review meeting tomorrow as it's intended to be technical, and intent is to make sure our work is satisfying the existing ACs on #11535.