[ ] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
[ ] Comment on this ticket:
If the Platform reviewer has any Thoughts/Questions that require responses.
When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
[ ] Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members.
[ ] Close the ticket when all feedback has been addressed.
Thoughts/questions
This is a very IA-heavy review and I appreciate y'all thinking about information hierarchy and tertiary navigation.
I love that you're incorporating point of need help instead of FAQs.
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
[ ] Should: use descriptive page titles For the h1's on the different mail list views (inbox-sent-draft-trash), updating the page h1 and the first segment of the <title> tag to indicate the current view would give the page much better information scent, and would cue users with what tab they're currently viewing. Y'all had an idea about approaching this with an eyebrow, or a plain text change like Messages: Inbox could work too. For individual message detail pages, work with @sterkenburgsara to ensure h1's and title tags are structured to avoid potential for PII making it into analytics.
[ ] Should: research mental models for flagging messages + accessing them later It could be helpful to do some research around:
(1) What types of words/symbols folks might use for flagging messages: Flagging a message may be familiar for folks using Microsoft products, but for others, that model might be a star, a pin or a save. Flag also has connotations as a negative - like, flagging as spam or flagging for review.
(2) How users might expect to find those flagged messages later on? Should flagged messages be a filter, or a button, or a hanging link like the other inboxes (which adds some complexity to the nav...)?
[ ] Consider: mental model for email vs. direct messaging Would it be helpful to think of this tool as being similar to a messaging app-within-an-app (a common pattern on mobile apps nowadays)? If so, how might we follow design cues for that type of interaction, and move away from an email inbox model? Does it make sense to have a conversation model organized by person/recipient (messaging model) - instead of by conversation (email model)? I recognize this is a big shift for the data model, but wanted to toss it out there as a way to inform your thinking on the tertiary nav.
[ ] Consider: IA for replies Currently in the IA, the URL to reply to a message is /secure-messages/reply/%messageID% and the URL to view a message is /secure-messages/thread/%messageID%. Is there an engineering constraint that prohibits reply from appearing as a child of the messageID in the URL - like /secure-messages/thread/%messageID%/reply? This would remedy the empty folder issue if the url were reply/%messageID%.
Governance team actions
[x] Format feedback as individual tasks (check boxes)
[x] Assign this ticket to the VFS team member that opened the Slack request
[x] Add the VFS team product label
[x] Add the VFS team the feature label (if applicable)
[x] Add the touchpoint labels
[x] Add the practice area labels
[x] Add the Collaboration Cycle initiative milestone
underpaid1ntern
commented
3 weeks ago
Next Steps for the VFS team
@platform-governance-team-members.Thoughts/questions
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
[ ] Should: use descriptive page titles For the h1's on the different mail list views (inbox-sent-draft-trash), updating the page h1 and the first segment of the
<title>tag to indicate the current view would give the page much better information scent, and would cue users with what tab they're currently viewing. Y'all had an idea about approaching this with an eyebrow, or a plain text change likeMessages: Inboxcould work too. For individual message detail pages, work with @sterkenburgsara to ensure h1's and title tags are structured to avoid potential for PII making it into analytics.[ ] Should: research mental models for flagging messages + accessing them later It could be helpful to do some research around:
[ ] Consider: mental model for email vs. direct messaging Would it be helpful to think of this tool as being similar to a messaging app-within-an-app (a common pattern on mobile apps nowadays)? If so, how might we follow design cues for that type of interaction, and move away from an email inbox model? Does it make sense to have a conversation model organized by person/recipient (messaging model) - instead of by conversation (email model)? I recognize this is a big shift for the data model, but wanted to toss it out there as a way to inform your thinking on the tertiary nav.
[ ] Consider: IA for replies Currently in the IA, the URL to reply to a message is
/secure-messages/reply/%messageID%and the URL to view a message is/secure-messages/thread/%messageID%. Is there an engineering constraint that prohibitsreplyfrom appearing as a child of the messageID in the URL - like/secure-messages/thread/%messageID%/reply? This would remedy the empty folder issue if the url werereply/%messageID%.Governance team actions