Open jilladams opened 10 months ago
Today, Erika & Michelle talked to VHA DM about the fact that the notifications system emails the last editor of a piece of content. Sometimes, that's not the decision-making owner of the content. They are contemplating making it possible to set an owner or specific email address, to help manage that. They'll loop in @davidconlon as that convo develops.
@swirtSJW FYSA in Q4, the PW team will be piling onto the notification email system to do some aging content notifications (stubbed out in this epic). We'll want to schedule some time with you and @chri5tia @dsasser for a high level step through of what you learned, how it works, powers and limitations. I'm suggesting we do this internal to Sitewide, since it's fresh on your mind, but let me know if you think it's wise to include CMS Team folks when we get there. (Our Q4 work for notifications includes 1 content type, 2 block types, and 1 ~Taxonomy~ Menu, so we do know there will likely be some blocking work required to get the system working with not-content-types.)
@davidconlon - this seems to straddle both CMS and Public Websites, where does this belong?
@EricaRobbins This is going to be for PW, contributing back to CMS.
Update 6.3.2024
We completed the framework in May 2024 and after some change management discussions have begun piloting this work with full-width banners (effective 6/14/2024) and the framework can support many different permutations.
Status:
[2024-07-08] Work is almost completed, at which time notifications can be turned on. Per Michelle M, no review is needed; just notification to manager of editors. [2024-03-13] Framework has been created; notifications/testing/documentation will be worked on in Sprint 106 & 107
[01/09/2024] Outcome of Drupal refinement meeting today: cc @dsasser @Becapa @jilladams
[12/4/2023 Status]
Elevator Statement
Allow for content-type specific time frames for email reminders with unique messaging.
Overview
Content in general, and for the purpose of this Initiative, content types of Full-width banners in VA.gov become stale and aren’t monitored or updated on a regular cadence, allowing many of them to still display after a campaign or event has passed. Full-width banners should be used only for informational alerts or warning alerts.
Currently, there is a Notification system set on a 365 day cadence from set from the banner's Created date or if subsequently edited, Last Edited date.
To provide timely information to Veterans and other users of VA.gov, and ensure banners are replaced and/or monitored, we need to implement the ability for the notification system to send notification emails based on a cadence specific to particular content types, e.g. Full-Width banners will only display for seven (7) days, and notifications will be sent three days before the 7th day (telling them they need to edit to add a note that it is still needed, or archive the banner by the seventh day), then the morning of the 7th day (telling them they need to either edit to add a note that the banner is still needed, or archive).
If possible, this should also accommodate Home Page Benefit Promo Blocks, and Home Page News Spotlight Blocks, which will be set at 30 day notification sequences (future stories/initiative to actually implement). Take note that if other banner types are created in the future, then this framework needs to be extendable to accommodate them as well.
If not possible, then another framework to accommodate blocks should be created in later endeavor.
Headlines
VA stakeholders -
OCTO lead - Dave Conlon
Is this project tracked to an upcoming event or congressional deadline? No
Details
How might we ensure a better site-user experience by encouraging appropriate use of Full-width banners for time-sensitive or frequently refreshed content, and in limited quantity.
Artifacts
Discovery
Affected users and stakeholders
Examples of outdated Full Width Banners still in VA.gov as of 11/30/2023:
Hypothesis
In Scope
Out of Scope
Acceptance Criteria for the Framework and Full-Width Banner Notifications
[ ] AC1: Drupal engineer is able to code an expiration date for any content type
[ ] AC2: Editor receives their 1st notification email informing them they should manually archive or edit to extend the timeframe
[ ] AC3: Editor receives their 2nd notification email on day 7 telling them they need to manually archive, or edit the banner to extend the timeframe
[ ] AC4: Editor edits an existing full-width banner when still within chosen date range, and the expiration date is 'reset'
[ ] Requires KB article update
[ ] a11y review for the new text on the form, and the email body
[ ] Requires KB article update
[ ] a11y review for the new text on the form, and the email body
Change management triage
The change represented by this user story will:
If you selected an item above, use the Change Management Runbook to create a CM epic and associated tickets.
If you did not select an item above, update issues/PRs in GitHub but don’t plan for change management.
Design principles
Veteran-centered
Single source of truth
: Increase reliability and consistency of content on VA.gov by providing a single source of truth.Accessible, plain language
: Provide guardrails and guidelines to ensure content quality.Purposely structured content
: Ensure Content API can deliver content whose meaning matches its structure.Content lifecycle governance
: Produce tools, processes and policies to maintain content quality throughout its lifecycle.Editor-centered
Purpose-driven
: Create an opportunity to involve the editor community in VA’s mission and content strategy goals.Efficient
: Remove distractions and create clear, straightforward paths to get the job done.Approachable
: Offer friendly guidance over authoritative instruction.Consistent
: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.Empowering
: Provide clear information to help editors make decisions about their work.Runbook