Closed stephorkandatx closed 4 years ago
jenniferlee-dsva
commented
4 years ago @stephorkandatx - I updated the AC. @peggygannon - for content. @rtwell - for confirming UX behavior and mockups. You can drop updated sitewide downtime banner mocks here: https://github.com/department-of-veterans-affairs/va.gov-team/tree/master/products/content/banners/sitewide-system-downtime-design-files
peggygannon
commented
4 years ago Thanks, @jenniferlee-dsva I have a couple of followup questions below:
rtwell
commented
4 years ago done!
I am referring to these as "System maintenance banners" b/c that's their respective header.
jenniferlee-dsva
commented
4 years ago @stephorkandatx and @kelsonic - I added one more AC, per the display rubric from our governance/ux behavior calls.
jenniferlee-dsva
commented
4 years ago @peggygannon - replying to your questions above - inline here:
Thanks, @jenniferlee-dsva I have a couple of followup questions below:
Looks like we decided to no longer have a "countdown" downtime message? If so, I'll remove that from the error dictionary.
Yes.
For "sitewide across all VA.gov" are we including online tools and apps under that umbrella?[Yes, if all of them are affected and will be unavailable. ] Or does this new banner type only refer to the unathenticated experience? [it would need to be all apps, all tools, including things you start in the unauth -- like sign in; like application forms, which we allow you to start unauth but then you have to sign in to save/submit -- but all of them, e.g., not just the 526ez.]
"System maintenance" header, is the intent to replace all downtime messages, including in-app and sign in, with that standardize heading?[no, just sitewide scheduled system downtimes. i think it's fine if per app/in-app message uses the same verbiage if THAT app is experiencing a system maintenance, but we wouldn't push a sitewide global banner for that one-app-down scenario.]
Re: "Message must have a specific expiration date." Partial downtime and in-app notices don't always have one... (merely say "check back soon") If this requirement includes in-app and tools, we'll need to sync with Platform devs (Disregard is this won't apply to tools and applications).
[This is replacing the sitewide scheduled down messages we were using in the promo announcement banner - no different - so it should always have a start time and end time. This appears on the UNAUTH pages across va.gov. I am not sure that the promo announcement scheduled downtime banners ever appeared inside the authenticated pages - would need someone else to confirm that.]
jenniferlee-dsva
commented
4 years ago @peggygannon - I made a clarification about the header text for these sitewide system downtime banners on your content ticket here: https://github.com/department-of-veterans-affairs/va.gov-team/issues/9536#issuecomment-637027483
ncksllvn
commented
4 years ago Some questions before we implement this too far. Please correct me if any of these assumptions are wrong!
ncksllvn
commented
4 years ago Posting additional info from here - https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/content/banners/banner-alerts.md >
Ability to publish: DEPO.
We can continue to host this config on GitHub ✔️
Sitewide, including VAMC products.
Site-wide ✔️
2 states: In advance of downtime; and during downtime.
I'm assuming that the timeframe of "in advance" will be variable based on outage level
Yellow for advance; red for during.
Alert banner will be driven by advance vs. active state ✔️
300 character count limit including spaces; allow links; needs to be configurable as dismissable per cookie or per session.
I'm a hesitant about enforcing this in code. If devs are given a message to publish last minute and it exceeds that limit, we're gonna have to circle back to content and revise. I think ideally we'd just have a content guideline suggesting we keep under 300 chars.
Must configure schedule and expiration: for in-advance messaging start and end; during message start and end -- dates and times.
This adds sort of a 3rd state - "in advance/impending downtime" message, "active downtime' message, and then "far in advance" (show nothing)
Standardized text with customizable dates and times.
It seems like this conflicts with the other text rule - 300 character count limit including spaces; allow links; needs to be configurable as dismissable per cookie or per session. since a standardized text to me suggests it'll be the same every time. Either way, we should make sure this config is flexible.
So on the dev front, I see this as....
<div id="system-maintenance-banner/>src/platform/site-wide that conditionally renders an AlertBox into the new root nodeThe JSON file could contain -
title: Seems to always be System maintenance
content: Changes based on impact level
startTime: When the downtime starts
endTime: When the downtime ends
warnInAdvance: Hours in advance to tell the user about the upcoming downtime
This message indicate site-wide maintenance. VSP did some work to centralize the site-wide maintenance config so they don't have to hardcode it in vets-website. Some code for that is here - src/platform/monitoring/DowntimeNotification/util/helpers.js. Maybe as a phase 2, we can take this functionality into account for this maintenance banner
jenniferlee-dsva
commented
4 years ago Hi @ncksllvn - Replying to a couple of items in your comment above: https://github.com/department-of-veterans-affairs/va.gov-team/issues/9223#issuecomment-637116386
Posting additional info from here - https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/content/banners/banner-alerts.md >
2 states: In advance of downtime; and during downtime.
I'm assuming that the timeframe of "in advance" will be variable based on outage level
[Default is 12 hours in advance of the start time/date of downtime. Can be modified for weird and exceptional cases, but let's always have a default, so we're not making it up every single time.]
Yellow for advance; red for during.
Alert banner will be driven by advance vs. active state ✔️
300 character count limit including spaces; allow links; needs to be configurable as dismissable per cookie or per session.
I'm a hesitant about enforcing this in code. If devs are given a message to publish last minute and it exceeds that limit, we're gonna have to circle back to content and revise. I think ideally we'd just have a content guideline suggesting we keep under 300 chars.
`[I hear your concern @ncksllvn. At the same time, my concern for this not being configured in the code is that we get into the situation where it's blobby -- e.g., Pittsburgh VAMCs misuse of banner alerts: We had content guidelines for banner alerts, but they were not coded into the design dimensions or in the CMS interface.
I would also like to get us to the place where these sitewide downtime messages are not being revised and manually written, then handed to Dev every single time. The desired state to get us to is: A new sitewide downtime is announced, with the date(s) and times; Dev can simply plug in the date and times, and not touch any other part of the message text, and publish.
Ryan, Dave and I landed on a fairly generous character count for the body text, 300 characters including spaces -- and doesn't include header text count. The main thing that should be customized each time are the dates and time ranges. The basic message text and header text should be templated and reusable for these sitewide system maintenance downtimes.]` <-- @rtwell @davidconlon any thoughts on how rigid we want to be here? I'm okay applying our own rules to ourselves.
Must configure schedule and expiration: for in-advance messaging start and end; during message start and end -- dates and times.
This adds sort of a 3rd state - "in advance/impending downtime" message, "active downtime' message, and then "far in advance" (show nothing) [there's only in advance, and during. No "far" in advance. ]
Standardized text with customizable dates and times.
It seems like this conflicts with the other text rule - 300 character count limit including spaces; allow links; needs to be configurable as dismissable per cookie or per session. since a standardized text to me suggests it'll be the same every time. Either way, we should make sure this config is flexible. [The text should be the same every time. But the date/time ranges would change. I guess that could affect the character count, but I see what you mean. Even if we encountered another weird situation like that 24 hour DSLOGON downtime, we don't want these banners to ever go beyond 300 characters, so I am comfortable forcing this in the code.]
Sorry it's so much. LMK if a quick call would be more helpful.
jenniferlee-dsva
commented
4 years ago And answering questions from your other comment: https://github.com/department-of-veterans-affairs/va.gov-team/issues/9223#issuecomment-637082609
Some questions before we implement this too far. Please correct me if any of these assumptions are wrong!
The configuration for the downtime announcement banner lives on GitHub. [Correct]These changes appear to be design-only, so the configuration continues to live there. This means a deployment will be necessary to publish or change content.
Long term, do we plan for the content to live in Drupal? Or should it always live on GitHub? [The longer term state is up in the air, and will depend on what kind of governance functionalities Drupal can provide - this was the discussion in flight per MC issue. Since building banners with the governance features we need across Drupal nodes will need potentially a lot of product development work, we're going to continue using GitHub process for the time being.]
This is site-wide, showing up on every page, until dismissed once. Once dismissed from one page, it should be hidden on all pages. [Yes - and per requirements, dismiss should be configurable to be per cookie or per each session. Please make the default per cookie. If there's a really weird exceptional case that warrants per each session, we should be able to easily update UX behavior.]
This banner should render above the homepage banner [No, the hierarchy rubric is still what we [noted in the MD](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/content/banners/banner-alerts.md): Not changed: Rubric for display hierarchy is still a) Emergency banner, b) Sitewide downtime banner, [ and someday c) Veteran action needed banner]
The homepage banner continues to be non-dismissible[Correct - for extra clarity: the OPIA homepage emergency banner]
rtwell
commented
4 years ago I will always advocate to keep these as short and concise as humanly possible. If that means they need to be more rigid to ensure brevity, then I'm all for it.
kelsonic
commented
4 years ago @peggygannon @stephorkandatx @jenniferlee-dsva Please spot check this and make sure it's consistent with the content decisions if you could! 🙂 Related: https://github.com/department-of-veterans-affairs/va.gov-team/issues/9536
Quick comment about showing timezones:
For the same reasons as we've had before (moment-timezone seriously bloats the build when we've used it in the past), we're not able to show ET but instead can show the user's local time as we've done for the previous downtime messaging content.
jenniferlee-dsva
commented
4 years ago ^ @kelsonic - I'm going to defer to @peggygannon about the exact text, if they match what was submitted as final.
RE Time Zone - We must show time zone and it must use ET as the reference time zone. After we saw the last downtime message live, we all realized that it did not work for all users. There are people who live in areas that actually border/straddle multiple time zones, and without showing referent time zone for the downtime, it would be unclear to those individuals. This is actually not an edge case. Thank you for your idea though - I really liked it until this user experience was pointed out to me.
jenniferlee-dsva
commented
4 years ago One more comment - @kelsonic - The above screenshots are showing the emergency (coronavirus) homepage banner with the X dismiss functionality.
Just want TBC - We cannot implement the dismiss functionality on the current coronavirus homepage emergency banner.
kelsonic
commented
4 years ago @jenniferlee-dsva I was really thinking about the timezone issue last evening and I found a solution that doesn't require importing another library! Yay!
kelsonic
commented
4 years ago With correct timezones now! 🎉
startsAt) (1+ days of downtime)
startsAt) (less than 1 day of downtime)
jenniferlee-dsva
commented
4 years ago Thanks @kelsonic and @rtwell.
Also - any way you can hide the X dismiss on the Coronavirus banner? We are not adding dismiss functionality to the coronavirus banner at this time and don't want people to get confused/ misled/freaked out.
kelsonic
commented
4 years ago @jenniferlee-dsva Sorry about that, my screenshots were probably confusing! My screenshots show what it looks like locally but the homepage banner does NOT show the close functionality on production until we want to enable it 🙂
You can see that code here: https://github.com/department-of-veterans-affairs/vets-website/pull/12959/files#diff-c574901f95fed95b7445e47752392084R52
jenniferlee-dsva
commented
4 years ago Love it - thanks @kelsonic
kelsonic
commented
4 years ago Just confirming, it looks like the design spec calls for max-width: 650px for inner content:
An example of what this will look like is:
Is that still desired compared to the max-width: 1000px we had previously? 🙂
Comparison of new implementation vs. design spec:
kelsonic
commented
4 years ago CC @rtwell
rtwell
commented
4 years ago max width should be 8 columns (idk how many pixels that is)—the same 8 columns we use on main content on "regular" pages.
May I see the same content in both versions? I have a hunch those hard returns (new paragraphs) are the real culprit.
kelsonic
commented
4 years ago @rtwell Here you go! 🙂
And here is what it looks like full screen on a larger device:
peggygannon
commented
4 years ago @kelsonic thank for you the screenshots.
A couple of things I noticed:
Upcoming site maintenance, when downtime is 1 hour can we drop the (s) from hours? Also for downtime longer than 1 hour, it's preferable to have hours (not hour(s)
Is this possible from a code perspective? I will also update the messaging to make this more clear.
also for the DS Logon message.. Instead of "System maintenance" for the heading, I recommend we use the new standardized heading of "Site maintenance"
rtwell
commented
4 years ago looks like your header type is Bitter, and should be Source Sans (basically just bold <p>)
Could we use Peggy's content for full effect 😄
kelsonic
commented
4 years ago @peggygannon
Upcoming site maintenance, when downtime is 1 hour can we drop the (s) from hours? Also for downtime longer than 1 hour, it's preferable to have hours (not hour(s)
Absolutely! 🙂 I'll make that change right now
also for the DS Logon message.. Instead of "System maintenance" for the heading, I recommend we use the new standardized heading of "Site maintenance"
The screenshots I provided in this comment do not contain the actual content, I just made those screenshots for @rtwell so he could see it better with content parity between his designs and my implementation 🙂
The screenshots with the accurate content can be found on this comment or on the PR.
--
@rtwell
looks like your header type is Bitter, and should be Source Sans (basically just bold
)
Will make the change 👍
Could we use Peggy's content for full effect 😄
I am using Peggy's content except in the screenshot I sent you here, I had thought you asked me here if you could see the same content in both the design and the implementation, let me know if I misunderstood! 😂
kelsonic
commented
4 years ago @peggygannon Updated! 🎉
The maintenance will last 1 hour.
The maintenance will last 12 hours.
@rtwell Updated the header font-family to Source Sans Pro:
rtwell
commented
4 years ago lookin' sharp @kelsonic, thank you! may i see one on mobile?
kelsonic
commented
4 years ago @rtwell Of course! Here you are:
stephorkandatx
commented
4 years ago @jenniferlee-dsva FYSA ^^ screenshots
jenniferlee-dsva
commented
4 years ago I see 2 mobile screenshots, but assume IRL it renders as one thing (LOL). Both desktop and mobile LGTM.
Thank you @kelsonic .
jenniferlee-dsva
commented
4 years ago P.S. We're only seeing the "upcoming" banner. What about the 'during' banner?
jenniferlee-dsva
commented
4 years ago Oh nevermind - I see it. (And I saw it before, just forgot.)
jenniferlee-dsva
commented
4 years ago The during should use the red per Ryan's design - here: https://user-images.githubusercontent.com/12773166/84306847-45b14900-ab19-11ea-8c41-565a7cf688c4.png
(Saw a couple versions ^ still showing the yellow for during, but I think we're all clear that red is for the 'during' message.)
kelsonic
commented
4 years ago @jenniferlee-dsva it does use red for during 🙂 https://github.com/department-of-veterans-affairs/va.gov-team/issues/9223#issuecomment-641550687
jonwehausen
commented
4 years ago Afternoon 👋 ! Thanks all for reading this note.
Today Analytics and Insights noticed as part of this work the event previously in place for tracking the coronavirus banner clicks has been removed.
The event push previously in place for each of the embedded links was
'event': 'nav-warning-alert-box-content-link-click',
'alertBoxHeading': 'Coronavirus'Is it possible we could request this event be reinstated? Thank you all very much for your time.
cc: @ncksllvn @stephorkandatx
User Story or Problem Statement
We need a design component specifically for messaging regarding system maintenance. Our current solution which involves appropriating the promo banner is not sufficient. It also creates a scenario where messaging 'collides' on mobile (Ex: when the Coronavirus banner at the top was overlapping with our DSLOGON downtime alert).
How might we solve for a sitewide system maintenance banner?
This is a new type of banner to be used for communicating system downtimes that affect all services or tools sitewide across VA.gov.
Goal
Sitewide system maintenance banner is available for use in Github with the requested UX, behavior outlined in mockups
Folder, along with notes, at https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/content/banners/banner-alerts.md
Acceptance Criteria
Please follow the design file(s) for specifics. If there is a lot of change, we can detail out the current state here.
Sitewide system maintenance downtime banner requirements:
Design notes:
Adding a note - content ticket for this is at https://app.zenhub.com/workspaces/vsp-5cedc9cce6e3335dc5a49fc4/issues/department-of-veterans-affairs/va.gov-team/9536