securedrop-client icon indicating copy to clipboard operation
securedrop-client copied to clipboard

Implement "Seen By" on Files and Messages

Open ninavizz opened this issue 4 years ago • 11 comments

Problem

In user testing for Read/Unread, concepts around surfacing which Journalist users may have seen items in the UI were incorporated into prototypes. Participants commented favorably, that such functionality would help their workflows in a non-trivial way—namely, reducing the need for both encrypted and non-encrypted records keeping to track case management.

User Research Evidence

I checked the spreadsheet, and we did not track this—so, no. However, anecdotally, users did respond favorably to seeing the feature alluded to in prototypes. Likewise, many user interviews have spoken to the above. Which I would link to in a report, but we don't do reports (because they serve no purpose in lean ux).

Solution

  • [ ] "Read By" on Messages
  • [ ] "Opened By" on Files (TBD on how Export, Print, and Open, factor into that)

This issue has two core phases (above check-boxes) to completion. Nina/Allie both agreed that the below image reflects a great direction to target.

Screen Shot 2021-12-01 at 10 48 05 PM

Icon would only show for messages that have shown in a user's Conversation Pane, and files that a user has either opened, downloaded, or printed. While the icon shows a dual-checkmark, it will not have variances or states; and for single-user instances, the feature should not show at all. A Gherkin salad is on my (nina's) to-do list, to spec out in more detail—and I totally welcome collab on that, if desired!

Nina and Allie agreed that for an MVP the named journalist users may be shown as Tooltips. The Figma prototype shows a couple variations on how this display might be done in a richer fashion post-MVP.

For said richer fashion, Allie suggested a QT spike to learn how to do "overlay" panels as UI-integrated/non-floating elements (so no Qubes OS border)—as QT has some issues with z-axis handling of objects. Related to that, would be targeted styling of Journalist badges and the Auth Widget (for a truncated user's name) on hover.

Figma Assets

Figma Design File · Figma Prototype

ninavizz avatar Dec 02 '21 07:12 ninavizz

From the Outreachy description (and yes, we are sooo excited to welcome the person soon-to-own-this-issue, next week!)

Project Description

Add read receipts for journalists using SecureDrop Workstation The SecureDrop team is looking to add a feature to SecureDrop Workstation that will enable journalists to see who on their team has read a converstation or opened a document. The work can be broken up into two phases: Phase 1: Implement the frontend for the "Seen by" feature for messages Phase 2: Add "Opened by" feature for attachments During phase 1, you will show read receipts (with journalist names) for each message in the GUI. For phase 2, you will implement the frontend and backend for the "Opened by" feature.

ninavizz avatar Dec 02 '21 07:12 ninavizz

@ninavizz this looks great. a couple clarifying questions so far:

  • should the currently logged in user's name also get displayed in the read receipts?
  • what happens when the list of names is really long? should this tooltip display one name per line or wrap after a certain length?
  • should the names follow a similar rule structure for how we display names in badges (full name if both first and last name is set, first or last name if only one is set, username if neither first or last name are set)?

sssoleileraaa avatar Dec 07 '21 19:12 sssoleileraaa

Current Prototype and some answers in response to Allie's questions, above! :)

Context: Allie and I banged through a hasty design-review last week, and an implied design goal for why this direction was picked, was to reduce cognitive load on users—show them the least amount of visual/written information, to get the most bang for their buck. As such...

  • First names only; then, yeah, username if no first name is set
  • Nah, no need to show the currently logged-in user's name on the bubble
  • Yeah, wrap the text at ~200px. Russian and Swedish names, I've found to be helpful for "testing" resiliency with that sort of thing! Related, keep the notch at the same position, and extend the box down if at all possible. Or, that's not a concern for the MVP. Namely, I don't want the bubble to have a yellow/qubes-colored border on it
  • Also, the Replies should get these icons, too—tho not within the bubble, to the left of the bubble. It felt too busy with them inside the bubble.

I don't know if what is currently being done as a "tooltip" has the qubes yellow border on it, but I will also create a separate issue to do a spike on how to style all of the hover-overlays the way each should be done—and, without the yellow border wrapping Qubes gives it.

Some screenshots for measurement specs, below. Erika, the icon atop the white bubble background is 80% Dusty Lilac, which is #B0B0C9 as a straight hex.

Screen Shot 2021-12-07 at 11 17 32 PM Screen Shot 2021-12-07 at 11 18 46 PM Screen Shot 2021-12-07 at 11 19 52 PM Screen Shot 2021-12-07 at 11 16 51 PM

ninavizz avatar Dec 08 '21 07:12 ninavizz

  • Also, the Replies should get these icons, too—tho not within the bubble, to the left of the bubble. It felt too busy with them inside the bubble.

My understanding from previous discussions was that the checkmark icon would only show up in the bottom right-hand corner of a speech bubble, whether it's a message from a journalist or a message from a source. @ninavizz and @eloquence: we might need a followup review of this new prototype idea before implementing it (re: https://www.figma.com/proto/YejZGCIGZikX55LDcfvcYY/Client-%E2%89%A5-Q4-2021?page-id=321%3A39615&node-id=511%3A58327&viewport=241%2C48%2C1&scaling=scale-down&starting-point-node-id=511%3A58327&show-proto-sidebar=1). We might also want to review the journalist badge idea displayed in the prototype.

I think showing the checkmark in the same spot of a speech bubble looks cleaner and more consistent (less cognitive overload) and, if we need to, add some extra space between the text and the checkmark -- that could also make it less busy. This sounds like it's up for debate, so please tell me how you'd like to proceed.

I don't know if what is currently being done as a "tooltip" has the qubes yellow border on it, but I will also create a separate issue to do a spike on how to style all of the hover-overlays the way each should be done—and, without the yellow border wrapping Qubes gives it.

I believe John looked into how to remove the yellow border a while back and wasn't able to find a way to achieve this in Qubes (for dialogs or menus and other overlays). Creating an issue to track this would be helpful (thanks :)). Then we can pull it into a future sprint, which might be a good one for @gonzalo-bulnes to look into after "Download/Export All".

sssoleileraaa avatar Dec 08 '21 19:12 sssoleileraaa

@creviera I think showing the checkmark in the same spot of a speech bubble looks cleaner and more consistent (less cognitive overload) and, if we need to, add some extra space between the text and the checkmark -- that could also make it less busy. This sounds like it's up for debate, so please tell me how you'd like to proceed.

So, before presenting prototypes or wireframes, designers always (or always should) "play" with layouts to see what is working and what is not working. To put the checkmarks always in the lower-right of the bubble boxes, would require users to "dart" their eyes around too much, to see what's been seen vs not. So, for the Reply bubble, putting the checkmark in the lower left corner, is what makes the most sense (as that restricts the "column" of eye movement to a much narrower field)—but then when I did that, it was visibly cluttered. Which resolved when I moved it to just outside the bubble. That is the backstory—and I feel it'd be better resolved in a design review, than async in GitHub.

ninavizz avatar Dec 08 '21 20:12 ninavizz

I believe John looked into how to remove the yellow border a while back and wasn't able to find a way to achieve this in Qubes (for dialogs or menus and other overlays). Creating an issue to track this would be helpful (thanks :)). Then we can pull it into a future sprint, which might be a good one for @gonzalo-bulnes to look into after "Download/Export All".

#1372 was crated to track this! :)

We might also want to review the journalist badge idea displayed in the prototype.

Heh... :D So, that design/direction was done & pushed up to Zep-lin ~2yrs ago. I think you were "ok" with it, then—which I say with massive air-quotes, as you/jen were doing about 10,000 things when it went in. This is a great thing to factor into a review of the design system. No rush—but, context. :)

ninavizz avatar Dec 08 '21 20:12 ninavizz

@Er1kkkaaa Hey hey! FYI, Allie and I are still chatting to resolve the "Where does it go?!" question on the checkmarks icon... but we're both in agreement, that the padding needs to be increased between the bubble-edges and the text, to 35px on the sides and 27px on the top/bottom. For both Journalist Replies and Source Messages. More l8r!

ninavizz avatar Dec 08 '21 21:12 ninavizz

Alrightee!! @creviera got her UX on, and took a stab at the icons placement in Figma... and I think she mighta nailed 'em!

Take a peek at the prototype or the design file.

They're 13px offset from each bubble, and the alignment follows the guides in the below image. The bubble should probably be smaller in total/max-allowable width, so it never exceed perhaps 150px?

@eloquence @gonzalo-bulnes Allie requested your eyes on this, too, as she's now out for the week—but we both just casually chatted on Slack, and we're both happy with this for a first run.

Screen Shot 2021-12-08 at 7 21 28 PM

ninavizz avatar Dec 09 '21 03:12 ninavizz

The checkmark positioning looks great to me. How do you want to resolve naming ambiguity e.g. if there are two Mikes? Usernames are required to be identical, but first names are not. If real names are defined, IMO we should use them, and show the full name.

eloquence avatar Dec 09 '21 05:12 eloquence

Yes, the current proposal is to use first names only. If there is no first-name, then the username. If there are two users (journo or admin) in an org with identical first names, than we should use the first name and the first character in the last name, if both exist.

When you say "usernames are required to be identical," what do you mean by that?

ninavizz avatar Dec 15 '21 07:12 ninavizz

This will need to be implemented in the new client, though likely as a post-1.0.0 feature. Keeping open for now, but can be closed and re-scoped if needed.

eloquence avatar Jul 02 '25 23:07 eloquence