Open yaelberger-commits opened 1 month ago
Hey team! Please add your planning poker estimate with Zenhub @YedidaZalik @amazingphilippe
our testing confirmed that the scheduler is in the sender's local time, based on their IP address
Pages we can consider updating:
Specify "local time" on these occurences:
Add a guidance section to make it clear that all times are local, unless marked otherwise.
Can we convert the daily limit reset time string to local time? Not here, but good to consider later. Can we indicate timezone in column headers. Sure, for a future iteration
Started on content here: https://www.figma.com/design/fRVRKm7cM8MUuBWUJbrfgU/Sending-from-web-interface-%7C-Envoyer-par-interface-web?node-id=6678-16627&node-type=FRAME&t=P9vWKfPN2EEPaTao-0
Realized that several instances of "local time" could be viewed by team members in different time zones. As a result, the lengthier content is used for this intervention eg. All times on this screen are local to {name of team member}.
Sync with Phil and Yael - clarified that each team member sees their local time based on their IP address. Eg. a team member in Ottawa schedules the send in EST. Another team member in Vancouver accesses the screen that gives the scheduled time. The Vancouver team member's screen will give the time in PST.
Designs ready for review by Phil & Yael
Yael & Phil reviewed with Yedida at our weekly sync this morning. Bringing to Dev/Design Review today to share with the devs for implementation handoff
Yael & Phil reviewed with Yedida at our weekly sync this morning. Bringing to Dev/Design Review today to share with the devs for implementation handoff
Discussed during dev-design review, decided:
Yedida looked back at the support requests and both have the word "use": ". . . which timezone is used?" " . . . guess that this application is using Eastern Time..." So changed to "The calendar and clock use your local timezone". Did not go with "Use your local time zone" as that could be interpreted to mean that the person must figure out what their time zone is and then use that time zone to schedule their send.
Then moved closer to picker on advice from Phil- shortened sentence for the new position.
Designs for the [2 screens we decided to revise in figma]https://www.figma.com/design/fRVRKm7cM8MUuBWUJbrfgU/Sending-from-web-interface-%7C-Envoyer-par-interface-web?node-id=6676-365&node-type=canvas&t=bCuv1POvL7m998H1-0
FR figma screens are underneath for when MSB is ready to localise
Ready for localisation when MSB has time The FR screens are prepped for her under the 2 EN screens https://www.figma.com/design/fRVRKm7cM8MUuBWUJbrfgU/Sending-from-web-interface-%7C-Envoyer-par-interface-web?node-id=6716-1296&node-type=frame&t=UsLn0OAL2i9EGFmc-0
Description
As a Sender scheduling a bulk send, I need to be able to know if the time zone is EST, UTC or something else so that I can control when the messages will arrive in recipients' inboxes.
WHY are we building? https://cds-snc.freshdesk.com/a/tickets/18502 https://cds-snc.freshdesk.com/a/tickets/18789
Feedback from a client We don't have the timezone in the scheduler
WHAT are we building?
VALUE created by our solution Better UX, less friction. A reference for future support requests, and for the team.
Documentation and Artifacts
Document Figma?
Acceptance Criteria
Given a sender is scheduling a bulk send, when they go to schedule their send, then see the time zone the product uses and can figure out what time to schedule so that messages arrive in recipient inboxes when expected.
[ ] Add content to clarify timezone when scheduling a bulk send
[ ] In guidance, reassure that time strings are local
[ ] Add content at sign-in history to clarify timezone is local
[ ] Cypress UI tests if needed.
A11y
Bilingualism
Privacy considerations
Security controls in place
Measuring success and metrics
QA Steps