-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show which journalist sent a given reply #76
Comments
Static wire demonstrating threading. Sources should NOT see the ID badges, but within the Client journalists should all see their own (upper-right, always; in convo thread when relevant) and their colleague's (in convo threads) ID badges. Letter in the badge is determined by the first letter of a username, or the person's first name (if/when that separate feature is added). https://drive.google.com/open?id=1GxXbYgQAR7nHlnvXxPFZ_oeA1NmZmf0e Cheerio! |
My interpretation of this is that we need a server-side API to pull the list of current journalists. This is a minimum requirement for this feature. Additionally, this would allow journalists to update their display name (see freedomofpress/securedrop#1592) and have that change propagated to the clients. |
so I added |
I've updated the top level comment to reflect the recent addition of first name / last name functionality. Like #411, this is blocked on freedomofpress/securedrop-sdk#87 (SDK support for first names / last names) unless we decide to do a first iteration with just usernames. The current design spec for the conversation view only reflects display of initials; if we ever want to show more than that (e.g., in a hover state), we'll need a design spec for that, as well. |
Still unclear whether this will make it to beta. Leaving a note here to make sure we carefully reason through the behavior when user accounts are deleted on the server:
|
(Kept on beta but marked as stretch for now, more likely Post-Beta IMO) |
As expected, moved to post-beta. |
This is not quite ready for dev yet, but we've agreed to put our heads together (at least @creviera @eloquence @ninavizz) to finalize the design and implementation plan for a first iteration, as part of the 7/23-8/5 sprint. |
update: working on a spike to see how this can be split into a couple or few prs, looks like we need to make a few backend changes to make sure a journalist for a DraftReply cannot be None and to pass around the logged in user when authentication changes (instead of just whether or not the user is authenticated) so that we can get the name of the sender of a reply. can't remember if we discussed hover-overs to show the fullname but that would be a useful thing to add. also: should we change the journalist sender icon to red when the reply fails? |
I created a separate issue for first handling backend changes: #1133 |
We (Mickael/Allie/Nina/Erik) discussed the first iteration of this feature in some more detail today. We agreed that the first iteration will only use two colors, the Once that's done, we can resolve this issue, and track further UX changes (more colors, improved hover behavior) in separate tickets. Still TBD: how to render deleted users in the first iteration. |
For the 8/20-9/2 sprint, we've committed to landing the backend dependencies for this change, including an SDK release (freedomofpress/securedrop-sdk#127), and to get a draft PR for the reply badges functionality up which may not be fully ready for review yet (e.g., handling of deleted users may still be pending). |
Going to make a draft PR of this branch https://github.com/freedomofpress/securedrop-client/tree/journalist-initials-in-reply until freedomofpress/securedrop-sdk#128 is resolved |
(Removing epic from the project board; we are tracking #1142 as part of the current sprint, which may fully resolve this issue as an MVP, or we may split off some follow-up work before we call it ready for release). |
Woop Woop! @creviera
|
UpdateBeforeCurrently, on AfterHere is an example of how the PR that closes this issue (ready for review when things settle down for folks and they have time) shows which journalist sent which message, whether the account exists or not (a deleted accounts show the sparkles/stars svg Nina provided here #76 (comment)) and which replies came from the user who is currently logged in (purple badges): FollowupI opened a followup discussion issue for us to use as a place to capture ideas around how to display errors now that we have reply badges and use colors to mean more than just whether or not there was an error. |
@creviera I polished the twinklies a bit so they're less-retro and more refined. More twinkly, less sputnik. It's subtle, and may not be worth the late inclusion into the merge, but FYI. Communicating ephemerality is their purpose, not how much I want to move to Palm Springs and live in a cocktaillian utopia.
|
Yup! Do you have a preference? TY for the screenshots, as always! |
(oof, wanting that "see attachment" and "cannot decrypt reply" to all be italicized and with the em-dashes...) |
"see attachment" is just a test message from a source, not a software message. |
oh yeah those messages might be confusing too because i was using some old screenshot examples. right now "cannot decrypt reply" is italicized ✔️ but no em-dashes. |
@ninavizz - for now, I prefer leaving it with the original sparkles until we compare the new one with transparency some more with multicolor badges - it's not guaranteed that the badge color will be blue, so the transparency makes it harder to see a distinct sparkle shape with lighter colors. |
@creviera Is this release of the PR shipping with multiple colors?? I'd thought it was only shipping with the SD Blue? No colors will be too light for the stars, because they need to be high-contrast enough for the letters to be clearly legible. That's been a big "limiting" factor in the colors I've recommended. |
good point, i think i was over thinking this earlier. now's a good time to update this in the pr actually, and we can get more people testing it this way. |
Updated dependencies to clear safety checks
Adds docs on generating test data for APIProxy
Each conversation in the conversation view is between one source and multiple journalists. We are storing this information and should show on the conversation view which journalist sent each reply.
If a first name and last name are set, they should be used instead of a username.
Acceptance Criteria
Given that there is a conversation with at least one reply to a source
When I view that conversation in the SecureDrop client
Then individual replies to the source should be identified by the journalist's real name (if set) or user name (if not set).
Given that there is such a conversation
When I view it in the Source Interface
Then the author of the reply should not be identified.
User Story
As a journalist, I want to know which reply was sent by which journalist so that I can understand the conversation history.
[See the user stories spreadsheet for current prioritization of this functionality.]
Updated by @eloquence on 2019-06-10 to reflect first name / last name functionality and add acceptance criteria.
The text was updated successfully, but these errors were encountered: