-
Notifications
You must be signed in to change notification settings - Fork 0
UX meeting 20190516
Nina Eleanor Alter edited this page May 16, 2019
·
4 revisions
Attending: @ninavizz, @eloquence, @harrislapiroff, @redshiftzero, @creviera, @zenmonkeystop, @olivemartini
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.
-
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
- Why the new state in the Source List after source is flagged?
- 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?
- Possibly add clarification blurb above Reply box, to a confused user in
- 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!
- Brand Use Guide(ish)
- UI Standards + Guidelines
-
Prototypes Archive
- Random things by nina, over the months and through the iterations
- Design Principles
- SecureDrop's Figma
- Meetings Page
-
Contribute!
- Really, we need help from practitioners around the world!
- About Personas
- About Design Principles
- Framework for tackling UI design
- How We Figma (and so can you!)
- General UX Resources
- Survey Resources
- Redaction Guide
-
Template Docs
- FPF Only: UxR Participant Disclosure, New Study Template, Email Templates, etc., from +2019
- Digital UxR Tools
- Sample Participant Disclosure