Skip to content

UX meeting 20190516

Nina Eleanor Alter edited this page May 16, 2019 · 4 revisions

Attending: @ninavizz, @eloquence, @harrislapiroff, @redshiftzero, @creviera, @zenmonkeystop, @olivemartini

Design Review:

All things Flag For Reply, with Workstation Client stuff as the basis for a paradigm shift around how we communicate this concept to users. Follow-up from initial crit, this past Monday in the Client meeting.

» Invision Wireframes «

Notes

  • Harris:
    • Key/Ignore binary confusing
  • Olivia:
    • Appreciates what Key/Ignore aspires to achieve
    • Verify/Delete likely clearer to journalist users
    • Disagrees with FFR/Delete and no "Ignore" option as paternalistic
    • Prefers succinct presentation with Keep/Delete
    • Discussion wrt broader issue of server hygiene via "Ignore" button option
      • Admins not often enough engaging w/ Journos in best practices steward role as our hopes/assumptions expect; we want to actively discourage Source hoarding, Delete button does that well.
  • Erik:
    • "Verify" is problematic because of social media associations
    • Confirms, "Verify" is a concept about to go into use in SD Directory
    • Skeptical about Source List state to flag Source keypair; pushing to top and marking anew as "New" good enough & doesn't confuse
      • Cites recent convo w/ Nina about confusing blue-bar on the left edge of item in Issues list in GitHub
    • Finds person/checkmark icon in "Reply Pane" footprint confusing
      • Clock icon instead, to present semiotic of waiting?
  • Kev:
    • Suggests "Approve/Reject"
    • Erik: "Approve" too loaded
    • Kev speaks to this as likening a moderation workflow
    • Erik mostly agrees, but then raises necessity of Source user action lost in that inference
  • Allie:
    • Keep/Delete, preferred; likes clean binary
    • Why "binary," why not just a single button
      • ohai, discussion!
      • Erik cites GMail's spam pattern as non-paternalistic/headwhack example of single-button done well
  • Jen:
    • Why the new state in the Source List after source is flagged?
      • Discussion; ensuing consensus = to remove. Not enough value added past bolding and moving to top, potentially confusing as so rarely seen.
    • Why push all lightning-bolt flagged items to the top?
      • Nina clarifies that as not intended, and rather just happenstance in the prototype preso (prototype assumes two DDoS Sources are the latest)
    • Consensus: lightning bolt nice, but shd not be a Beta dependency

Next Steps

  • Remove green/dude/check state of Source List item; behavior will instead be to simply mark Source as unread, as soon as Source activity is detected
    • Possibly add clarification blurb above Reply box, to a confused user in source now keyed state?
  • Explore single-button option
  • Dual-button preference among team seems to be Keep/Delete, buut...
    • Erik (in postmortem public Gitter post): "my sense is that there was some recognition that "keep" alone may not be sufficient, "verify" probably doesn't work, and "accept" or "approve" might be good alternatives to "keep" but no definite outcome here. ultimately my sense is that if it's between "keep" or "approve" or "accept" we'd all be happy to defer to your final decision"

Who Uses SecureDrop?
Learn about SecureDrop's users!

Contributors

Learn!

Et cetera

Clone this wiki locally