Skip to content
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

Recommended 0.4 JOURNALIST UI fixes #1540

Closed
ninavizz opened this issue Jan 29, 2017 · 3 comments
Closed

Recommended 0.4 JOURNALIST UI fixes #1540

ninavizz opened this issue Jan 29, 2017 · 3 comments

Comments

@ninavizz
Copy link
Member

ninavizz commented Jan 29, 2017

Basic/qwik updates... implementation notes in PDF and PNG.
/cc @heartsucker

I'll need to create three SVG files for this, should full implementation be desired. Lemme know @heartsucker (or whomever) if that'd be of interest. It's no biggie to do, just like to be efficient. :)

Tangentially: A screen like this is precisely where RITE testing would be ideal—and because specific journalists ARE SecureDrop users, it'd be silly not to.
http://www.answerlab.com/blog/2013/10/22/rite-when-you-need-to-know-fast/
SD_JournoOhDotFour-01g.pdf
sd_journoohdotfour-01g

Diary studies w/ Journos of their use with actual Sources, would be helpful for longer-term product development. Do they really use all those goofy check-box controls? What do they want when hearing from Sources? Users don't keep wish-lists of those things, even if you ask them to. Contextual Inquiry and diary studies are the way to go—and help so much.
About diary studies: https://blog.dscout.com/dscout-people-nerds-diary-studies-ux-research

Future Rev Issue:
I read through the documentation, and the messaging and interaction around flagged Sources for Journalists, is pretty confusing. That'd be a good issue to tackle, eventually. It's not clear what's going on, from the screenshots provided (and I wasn't willing to pay attention enough to authenticate into the demo version correctly). On a separate note—it'd be nice for folks to just be able to poke-around the Journalist demo, with required authentication/key entries fudged but indicated. So, like a prototype, basically. Yet Another Topic for another day.

.n

P.S.: @justintroutman @fowlslegs @redshiftzero a wiki page here just for UI stuff wd be nice... but let's all chat 'bout options & solution oppties. My week is open. :D

@ninavizz ninavizz changed the title Recommended JOURNALIST 0.4 UI fixes Recommended 0.4 JOURNALIST UI fixes Jan 30, 2017
@ninavizz
Copy link
Member Author

Added functionality into the above wireframes, for journalists to share Source accounts with one another, assuming each Journalist has their own login. I think I saw a discussion with folks contemplating how to do that, a while ago. If not, then ignore!

@redshiftzero
Copy link
Contributor

Overall I think these mockups look really great. Here are some answers to the questions embedded in the PDF and feedback on the mockups:

  • The “Change codename” icon just cycles the codename - journalists are not able to manually input nicknames that make sense to them (by design). They might cycle the codename if for some reason the name was hard to remember or memorize.

  • Re your “purpose unclear” unclear - the icons at the right of every row are meant to show if the item is an uploaded file (e.g. an image, doc, etc.), a message (text submitted through the web app) or a reply from the journalist (not shown in your image - would be in an additional row on this screen).

  • One big thing to realize is that right now SecureDrop is like one big shared inbox for all users. I went ahead and filed an issue to fix this (Retire SecureDrop's shared inbox for journalist users #1550). More details on the possible flow is in that issue.

  • Following the email UI paradigm makes a lot of sense. Note that right now we display all starred sources at the top of the inbox (kind of like “pinning” them), which I think seems reasonable (feel free to correct me there). Otherwise, I think your mockup of the journalist interface is much more intuitive and I would support those changes.

  • On the last page's assumptions: At some point we might have documents encrypted to individual journalist keys on the SecureDrop server (refs: Allow sources to contact specific journalists #98, Enable journalists to upload their GPG public key #1523) but for now there is only one master key for the SecureDrop instance. So this simplifies things significantly. We do have a journalist assignment feature that assigns one journalist to a source - we could (and probably should) modify this to enable assignment to multiple journalists. But since currently all journalists have access to the master key that all documents are encrypted to, we can just implement this multiple assignment functionality in the webapp without worrying about decrypting and re-encrypting documents/messages to the right journalist keys.

@eloquence
Copy link
Member

These are really outdated recommendations at this point, good as a historical point of reference but no need to keep open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants