"Safe Delete" parity with JI

[eloquence]

The SecureDrop Client currently only allows you to delete a source in its entirety, including their account, which prevents future submissions from that source. Depending on a news organization's workflow, it may be desirable to delete submissions quickly upon review, while still allowing future submissions from the same source.

We should therefore make it possible to preserve the source account when deleting the source.

We are planning comparable functionality in the Journalist Interface (freedomofpress/securedrop#5675) and will need to make sure that the SecureDrop Client implementation is consistent with the JI implementation.

Note that this does not necessarily imply batch selectability of multiple sources for deletion -- that can be tackled independently, and potentially at a later date.

User Story

As a journalist, I want to be able to quickly move stuff off the server & workstation, without preventing sources from sending more stuff.

[ninavizz]

Ohai! Issue #5766 was created in the SD Repo, to track the broader Safe Delete effort; this project is a part of that, so cross-tagging here.

[ninavizz]

JPG for @rmol's use in TBD timeboxed exploration of Menu possibilities in QT.

Yellow border is not the preferred way of doing the menu, but this JPG was endeavored on the tip that doing the dark blue stroke on these might not be possible (@creviera ??)

[ninavizz]

Assumptions:

Deletion is only actionable at the per-source level, from the ··· menu in the upper-right of the client’s conversation pane.
Individual messages, files, and replies, are not currently deletable. It’s “all or nothing.”
This may change, but is not a near-term priority.
Extending the capabilities of deletion within the Client, beyond parity with Safe Delete as implemented w/in the Web UI, is out of scope for this project.

Open Questions

• When a Source has all of its data purged, should it automatically move to the bottom of the list in the Sources pane?
• How to reflect “In Progress” if only data is being purged, vs whole Source
• If a Source’s data is purged from the JI, or the Source itself deleted, how to reconcile on Client?
  • “Things Happening” that a user does not invoke, can be confusing; some kind of an “FYI” barre message should flash to let user know Client updates from Web UI?
    • Needn’t be part of this project’s deliverable; can be a Q3 (maybe?) priority addition to Client.
    • Should consider other Web/SDW parity actions.
• The opposite of the above: things happen in the Client, how to reflect in JI?
  • Tentative hypothesis = no need, as JI always loads from scratch; no “Offline Mode” or UI refresh from previously-used state, kept in Tails.
• Would require additional Conversation Pane screen state, for “No Data” (or something)?
  • Different from current “No Sources” screen; slightly (text only)
  • For opsec, should or should not speak to choice of newsroom having deleted previously captured data—Mickael?
    • Nina’s $0.02: it’s confusing to obfuscate why some sources may have “nothing” there but still exist; only hesitance
• Two current proposals: “Binary on Dropdown,” or “Binary On Pane”
  • Nina’s pref is to keep Client investment minimal, for now, to shape a Web UI that can hold-up for 1-2 yrs.
    • 1-2yrs is an eternity for “Consumer Web” users to use an experience; so balancing a desire to not over-invest in the web UI, imho needs to be weighed with delivering an experience that at least manages expectations and user anxiety ok. :)

Proposals

Binary on Dropdown

• Would take existing ··· menu to the next-step of UI maturity, with being a proper menu.
  • Would make room to more easily add new actions to the menu, such as Export-y things, Mute, Tagging, etc. Things on the implied roadmap for 2022-25.
  • Do we want to do more UxR to learn about user expectations for the ··· menu and/or Conversation Pane Header icon actions, or just jump into this now?
• “Delete All Data” actionable from menu
  • Has no additional prompt, just executes
  • Wd need failure message composed
• Only pane is “Are You Sure?” prompt
  • In theory could remain ugly
• For users desiring purges of Source data but not accounts, this = more streamlined experience

---

Binary on Pane

• Potentially quickest to implement? Above using what I think is the Export pane + a windowshade.
• Would prefer pane maturation to better align with Export, with this direction
• Potentially annoying for users via “Too many clicks”?
  • Potentially not, via feedback from Read/Unread UxR, when delete functionality was asked about. Most users said they “are ok with a few extra steps on Delete,” because it’s such a big deal.

[ninavizz]

Notes from UX Review of above

• Open-Qs around
  • Menu or Button language: “Files, messages, and all data…” vs “Files and Messages”
    • No noted resolution
  • Deleting metadata for newsrooms (eg: datestamp)
    • No noted resolution
  • For both Client + JI, spoke to re-ordering of data-purged Sources to end of list, to keep inboxes clean/tidy.
    • Soft agreement this wd be good?
    • John had idea for eventually adding a sort-widget to Sourcelist in Client
    • Nina flagged benefit for implementing “Find by codename” feature in Client to support newsrooms sending responses to purged Sources
  • Do we still want to not test these options, or do we want to do testing?
    • No noted resolution
    • I consulted Erik for his thoughts on budget/timing for prospective testing, and of the general “problem” and he had a badass solution idea (below) that’s eliminated my desire to see this tested. Woo!
• “Binary On Menu” option = preference from team
  • LOTS of open questions around styling feasibility points w/ menu in QT, after inability to style w/ dark blue outline flagged.
    • DISCUSSED: Implementation limitations from how things are presented in mockups, wireframes, and prototypes should be flagged to UX sooner rather than later, as prototypes need to match what can be implemented… and 2yrs in it kinda sucks to learn about this only now.
    • Nina circulated PNG (above) to team for John to do discovery against

Chosen/Updated Version

Following some discussion about text particulars, and then a separate discussion with @eloquence to discuss budget options for doing some user testing between the two versions, he suggested a "You Sure?" dialog for Messages & Files, too... which eases my anxiety about wanting to test, so I'm ok not doing any testing now.

Binary on Menu

• Text on buttons simplified, slightly; small character-count maintained for parity with JI
• Both binary paths now have "You Sure?" dialogs

[eloquence]

We won't be working on the SecureDrop Client implementation yet in the 2/18-3/3 sprint due to competing commitments, but we've agreed that the Safe Delete team should convene to finalize the delivery guide for the SecureDrop Client implementation, as well as any outstanding UX design work, once @ninavizz is back.

[eloquence]

We're picking this work up again in the 3/24-4/17 sprint, starting with finalizing the design & delivery guide. The core implementation team will likely comprise @rmol @creviera @ninavizz and @emkll. We'll aim to start implementation this sprint, but are constrained to a 16 person hour timebox total.

[eloquence]

Next steps discussed today between @emkll @rmol @zenmonkeykstop @ninavizz @eloquence:

• We agreed on the "paper tear" pattern as a good way to indicate to the user that previous files/messages have been deleted, in the first iteration of this feature
• We agreed to consider additional indicators (e.g., "this source is new" vs. "this is a returning source") in the source list based on user feedback and research
• We agreed that file/message deletion should ideally be very fast from the user's point of view, i.e. at least as fast as the initial API call(s) requesting file/message deletion
• @ninavizz will update the prototype to include the "tear pattern" for previously deleted files/messages, and a progress indicator
• @rmol will continue research on the implementation strategy, including queuing logic and how we can update the UI as quickly as possible), so we can ideally avoid the pattern of long "Deletion in progress" indicatos that Delete sources as soon as API action succeeds #1101 is proposing to change
• We're unblocked on beginning the implementation work, with @rmol and @zenmonkeykstop dividing up the work, consulting with @creviera for implementation details

[sssoleileraaa]

including queuing logic and how we can update the UI as quickly as possible), so we can ideally avoid the pattern of long "Deletion in progress" indicatos that #1101 is proposing to change

See #1101 (comment) for my initial thoughts about whether we should show the pending state until the information has been removed from the db locally VS show pending state until the job (or batch job) is finished processing and the server responds successfully. If we want to switch to the latter, it's just a GUI change (we would not be changing the way the client and server sync).

[zenmonkeykstop]

@ninavizz should we consider adding an "are you sure?" for files+messages on the JI All Sources as well? Development-wise it's not much effort.

[eloquence]

Just as a recap, the rationale for not doing so (as I understand it) was that file/message deletion may be used more commonly and is less destructive, so the "speedbump" of an additional confirmation may be frustrating for users.

We've reached out to a couple of orgs for feedback on the use of the JI version so far and I would suggest waiting for those user research sessions before making further changes to the JI implementation.

[ninavizz]

@zenmonkeykstop As I understood the initial concern, it was from an admin who's not themselves a daily-user. Even if it had been a daily/regular user, it's typically not a good thing to react to each piece of feedback we get... and to let a feature "percolate" for a while amongst folks. Everyone who uses the JI, will encounter it, likely, at some point over the next 2mos. I'd prefer to just wait and see how it goes.

[eloquence]

During 4/15 sprint planning, we tentatively agreed on the following work breakdown:

• frontend implementation and integration, including functional tests: @rmol with support from @creviera
• backend implementation: @zenmonkeykstop with support from @creviera

[ninavizz]

Awesome! I'll post the link to the prototype here, today.

[ninavizz]

...or, y'know, next week. 😺

Added design tweeks to initial "You've deleted all the files/mssgs but kept the account!" page following Mickael's feedback (made the messaging bigger—and quite pleased with this version, actually!).

UXPin prototype is in-progress, and was endeavored mostly to demonstrate choreography of messaging and timing with the #1101 update—so apart from providing a backwards-demonstration of a scrollable conversation page after a purge, it's not much of a priority, atm. Also doing it to help guide polish work Allie and I are doing.

UX Implementation Deliverables

• InVision basic screen step-through
• UXPin prototype
  • Read annotations, before poking around—button below yellow VM frame, to hide/show annotations.
  • "Tear" pattern w/messages sent after the purge, should be at the top of the scroll—so, out of view upon load, if it's a long thread after an earlier purge. UXPin's scrolling feature is a bit half-baked.
• Mockups + Zeplins + SVGs
  • Zeplin mockup showing tear, sparkles, and big text
    • SVG Artwork for sparkles
    • SVG Artwork for big tear
  • Zeplin mockup, showing "tear" pattern with a new Source message having been received after a purge.
    • SVG Artwork for right side of above tear (@rmol do you need both right and left, or is it easy to "flip" the right side one?)

[ninavizz]

Hi Gang! Lots of updates in the past month, to the above.

Current UXPin Prototype

• https://preview.uxpin.com/9421d3f55e0495d6894b7c1f92fc1b2e7318c9f1#/pages/138921997
  • No passphrase required
  • Recommended viewing @ 100% on an external monitor, or ~75% in a laptop browser window (control is in the top white bar below your browser's bookmark's bar, in the far right near the lightning-bolt icon)
  • To "reset" prototype, clickable area in the top-right over "JDoe" username for Qubes, should work no longer works as a functionality of UXPin. Sorry, refreshing the page is probably best, to "reset" prototype.
  • Text may be cut-and-pasted from the UXPin prototype, for dialogs & such

1. Delete Files/Messages only, for Benign Artichoke
2. Delete Source Account for Cuddly Antelope
3. Must be in that order; not the other way around. Because, yay, visual prototyping tool constraints.

Updated Zeplin Screens

• Yet to create Zeplin/Sketch screens for the dialog windows.
• Hover values for Grimace Blue = #6C71AE and #EBECF1
• Delete Zeplin folder
• Older depreciated screens moved to Depreciated folder.
• None of the objects change positions or size in the conversation pane or source widget, when a deletion happens. Some may disappear, many change colors, and a few may get replaced by animations. Annotations in Zeplin. Will also include a punch-list as a follow-up issue.

[ninavizz]

Animations for production, both generated at ~3x their placed size to help with crispness

[ninavizz]

@rmol Don't know if you started working from either of the Zeplins that I posted last night, but I just realized I'd left-out one state spec. Left you a note that I'd @'d you on, in the Zeplin file itself. Just FYI. :)

[eloquence]

@rmol has this feature in a good working state and will open PRs into securedrop-client and securedrop-sdk soon. During this sprint, we will aim to land these PRs, which will include a 1:1 session between @ninavizz and @rmol.

[ninavizz]

@rmol Hey John, Allie just resurfaced this Issue onto my radar. Apologies for dropping the ball with getting those Zeplin screens to you, but they are now present at the above link! https://zpl.io/bz35z4M