"Safe Delete" project delivery

[ninavizz]

Description

Last quarter we endeavored some user research to learn about the deletion experience for Journalists. Based on observed learnings and chosen paths forward, we named this project and the subsequent outputs "Safe Delete."

This Issue is to be an Epic to capture all related issues for frontend implementation w/in SecureDrop Core touchpoints.

User Research Evidence

Yup.

User Stories

We are a happy shiney SecureDrop product team that desires an epic within which all materials for this project can be tidily co-located and tracked across 2-3 releases.

[ninavizz]

Stuff

• Backend work completed in Make it easier to delete all source data without preventing source login #5675
• Nellie Bly UXPin prototype · Maisie Clemens UXPin prototype
  • Clicking on login/auth row of text will "reset" each prototype to the beginning, and for most screens clicking on the NYWorld logo will toggle the prototype into non-JS mode.
• Project Delivery Guide (JI and SDW Client)
• Notes from Meetings (most recent at top)

[ninavizz]

Prioritizations per Nina/Mickael/Kev/John 01 Feb meeting; "Must" ≠ a release blocker, just try doggone hard.

Agreed-to "Must" targets for 1.8

• All Sources page: menu-ish (or overlays) spawned by "Delete" button
  • Text styling (see below comment for typography spex)
  • Button styling (see below comment for typography spex)
  • Positioning of menu or overlays
  • Windowshade opacity to 30%
• Individual Source page: "You Sure?" overlay
  • Updated styling per CSS in Delivery Guide + new "x" icon (art in comment below!)
  • Bulleted text from overlay on MClemens prototype
  • Windowshade opacity to 30%
• Nomenclature update: "collection" becomes "source accounts"
  • Across docs
  • In flash messages (see updated strings, in UXPin prototype)
  • On individual "Source" page (see updated strings, in UXPin prototype)
• Bug Misplaced "No Collections Selected" error on JI #5754 (only for JS version; "fix" not possible for non-JS)
• "Success!" flash messages
  • Update flash.success style per Update JI/AI Flash Messaging Styles #5767
  • Update HTML for All Sources and individual Source page deletion actions to use flash.success in place of flash.notification style
  • Update messaging text strings to match what's in NBly
• Individual Source page et cetera
  • Nuke trash can icon on "Delete Selected" button
  • Nuke text above account deletion button (overlay says the same thing but more clearly)
  • Nuke cut-out class hr at bottom of page (baaaarely visible, #c3c3c3)
  • Delete Account button
    • Nuke trash can icon
    • Update style to match the "Delete Selected" button in top row of table
    • Update text on button to match NBly
  • Add #F8F8F8 gray box that's ~220px tall and the same width as the table, behind button
  • Update style on flash messages confirming a successful reply
    • Technically this is really a "should" but it would be weeeeird to have all the other confirmation messages change for journalists, but this one.
    • Change-out "Thanks" for the bold green "Success!" in text string.
      • I mean, ideally the rest of the text string would match what's in the client, or say something less odd/literal than "Your reply was stored" (match non-techy user's mental-model w/o implying "sent"). "Your reply has been posted"? "shared"? Maybe "Your reply will be available to this source when they check their SD next" or something less wordy.

Agreed-to "Should" targets for 1.8, that become "Must" for 1.9 if not hit in 1.8

• All Sources page polishes
  • Nuke trash can icon on "Delete" button and add ellipses per NBly prototype
  • H1: add "All" before "Sources," title-case (both words uppercase)
  • Listed source items, when selected
    • Yellow background #FFFEEB
    • Files/Docs icons reduce to 50% alpha
    • Numbers change from gray to #2A319D
• Nomenclature update: "docs" to "files"
  • NOTE: No URL structures included in this; GPG files to download, individual source page .../col/blahblah
  • Across docs
  • In "source item" text from All Sources page (next to the icon)
  • In flash messages (All Sources, Source)
  • In Admin UI (blurb about disallowing instance from accepting files)
  • Static page text on individual Source page.
• Individual Source page polishes
  • Create & assign new style to reduce size of text below breadcrumb and "Reply" H2 (see below)
  • Update text strings below breadcrumb and H2 to match text in NBly

Agreed-to "Could" targets for 1.8, that become "Should" for 1.9 if not hit in 1.8; or get nixed, altogether

• All Sources page: menu-ish (or overlay) "## Unread Items Selected" warning
  • Potentially high-complexity feature to warn users how many total items across all selected sources, are unread.
  • If 3 sources are selected and one has 4 unread items and another has 6 unread items, while the third has no unread items, the message would read "10 Unread Items Selected."
  • Only possible for JS-enabled users
• All Sources: Super groovy JS fade of yellow background on Source item
  • In NBly select 2 items towards the top, click "Delete," and delete messages/files. When the page re-loads with the Flash message, it will load with the previously selected items no longer selected via checkbox, but they will still be yellow; then, the yellow quickly fades. This was identified by users as a nice touch to let them know what items they'd acted upon.
  • More neat-o than essential; John had thought it may be possible with CSS.

Agreed-to "Won't" targets for this delivery, that should be considered for future implementation

• All Sources page Move purged sources to bottom of Source List
  • Web UI only, as "managing" it is far harder than the Source List in the client, as the latter provides more visibility into allthethings.
  • Desire to seek user feedback before proceeding.
  • MVP approach had metadata date change to sort to bottom; consensus that changing metadata is unlikely to be desired behavior/function, and that this should be tackled more holistically as to not impact last-action-for-source info.
  • Per above, non-trivial implementation on Web UI

[ninavizz]

Updated CSS Things

• All Sources initial dialog/Menu Pane
  • Binary Buttons text: font-size: 0.9em; font-weight: bold; line-height: 1.4em; color: #FF3366;
  • Text is not all caps
• "Are You Sure?" Dialog/Menu Panes
  • For the pane styling itself, see browser screenshots from Nina hacking
  • Kev, I-O-U an "x" icon
  • Typography
    • H1: font-size: 22px; letter-spacing: 0.1em
    • better-body: font-size: 0.9em; line-height: 1.4em; color: #303030;
    • better-bold: font-size: 0.9em; font-weight: bold; line-height: 1.4em; color: #000000;
    • coral-bold: font-size: 0.9em; font-weight: bold; line-height: 1.4em; color: #FF3366;
    • buttons
      • Text is not all caps
      • All "border" buttons (and existing "danger" butts in journalist.css), make border 2px instead of 1px
      • padding: 7px 15px; font-size: 0.8em; font-weight: normal; letter-spacing: 0.1em;`
      • Solid button hover: background: #E3305C
      • Open button hover: color: #E3305C; border: #E3305C; background: rgba(255, 51, 102, 0.8);
        (urgent coral @ 8%, if my css sucks)
• Individual Source page "description" text (below breadcrumb and Reply H2)
  • Use "better-body" and "better-bold" per above

---

KEV: Ping me in Slack if I missed anything... :)

[ninavizz]

/cc'ing @zenmonkeykstop @rmol @emkll for visibility

[ninavizz]

^^ transparent window close-x, @zenmonkeykstop! It's 60x60, so you should be able to downsize it as much as you need w/o degradation.

[ninavizz]

@zenmonkeykstop Per Slack convo yesterday, here's an updated version of the overlay close-x with the #0006c6 circle behind it. Also wanted to tripple-check (after the PR preview earlier today) that the outline on the updated modal styling is also #0006C6 and not black. :)

[zenmonkeykstop]

Thanks - yup, #0006C6 confirmed.

As an aside, it might actually be worthwhile using the color names in https://github.com/freedomofpress/securedrop/blob/develop/securedrop/sass/_variables.sass rather than hex vals, partly because it'll make refactoring them easier if/when we start taking accessibility reccos re: contrast into account.

[ninavizz]

@zenmonkeykstop Did not know about those SASS values, thx for sharing!

All current UX reccos are considering accessibility, so I don't expect any will need refactoring. Will also need to be adding the classes requested up above, at some point. Thx again for passing along the SASS, will document on my own to use going forward!