Recommended 0.4 JOURNALIST UI fixes

[ninavizz]

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

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]

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]

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 (#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: #98, #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]

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