Update Read/Unread to Include Files Status

[ninavizz]

Problem

When a journalist clicks on a Source when a new file, message, or both, have come-in, the view of that source in the list changes states from "Unread" (bolded/black) to "Read" (un-bolded/gray).

It has been decided that it will be useful to similarly mark files after they have been downloaded, and opened in a Disposable VM. This Issue is to demonstrate that implemented design and behavior.

Discussion about potentially delaying that "marking" of the file as Read until the user elects to close the Disp-VM did happen; validating the potential usefulness of the added dev complexity for that, in Pilot research, was determined as an appropriate handling of that escalation. For now, we'll keep it simple and simply add the marker once the user-acted-upon downloaded file has successfully opened in its Disp-VM.

Considerations

• Keep the Files area in the Messages pane from getting too busy or cluttered; easy opportunity with this, for that to happen.
• Would be lovely if somehow this non-interactive thing could elegantly scale-up in a future release, to become an interactive entry to view "Seen By"

Acceptance Criteria

• Clickable wireframe demonstrating interactivity
• Play'able animation or clickable wireframe to demonstrate timed events & animations, for nesting inside the dev ticket.
• Anything else @creviera may need?
• Get on the needs testing punchlist

---

This is a sub-task within #18 and #31 and #17

[ninavizz]

Ok! Here's a first-stab with a few different versions. Both show options for how using those parts of the screen could scale to support "Seen By" functionality. I can haz feedbacks @redshiftzero @eloquence @creviera?

https://drive.google.com/open?id=1BF40zsK5zfoKmqCrTafQCIu-Lw4fw8cV

Tangential notes wrt shown mockups:

1. Once all files are downloaded, the “Download All” button (below the big blue rectangle) goes away.
2. For stupid-long filenames, see truncation of the 4th file in mockups.

• Beyond “x” character-count, omit filename’s middle characters to bring the character-count within spec, and add the … elipses with one   on each-side.
• Said editorial standard is cited in the Yahoo! Styleguide authored by Havi Hoffman (now Mozilla) pg. 215.
• Rationale, is that users will gain insight into both file-type (by seeing it’s addendum) and content theme,
  by seeing the beginning and end tidbits, vs seeing all of the middle and losing the addendum, when truncating.
  • Hypothesis: Stupid-long filenames rarely contain super important info for people new to its contents or organization,
  so the ugliness of wrapping as an alternative treatment, does not seem to be worth it.

[ninavizz]

BTW, Slack's patterns wrt this:
https://drive.google.com/open?id=1SI2FCy9TJIFz7iwJBtKW42VVvh8VoRZh

[ninavizz]

@eloquence The checkmark direction is what we'd decided upon, correct? Do you want to do any more design-y work on this before I hand off to Allie to implement?

@redshiftzero also piped-up in support of the checkmark direction

[eloquence]

@eloquence The checkmark direction is what we'd decided upon, correct?

Yep!

Do you want to do any more design-y work on this before I hand off to Allie to implement?

Implementation is still blocked on the server-side spec, but I think this is fine to add to freedomofpress/securedrop-client#187. Note that there's currently a wireframe in that issue demonstrating the Source List "new/not new" indicators (bold formatting of source designations); it might be nice to have a single combined image that shows both a "seen file" and a "new source" in the source list.

If we use a version with the briefcase iconography in the issue, it's also worth noting explicitly that it's separate from and unrelated to the seen/unseen/new functionality.

[ninavizz]

Aye aye @eloquence!

Taking a page from the Erik book, tho, I'll still then close this Issue as it's now been deemed complete w/in its determined scope. Final art for the icon, I'll plop into securedrop-client/#187. It's also linked-out to from #17, here.

Also, fwiw, I'm trying to track all content for the client (icons, images, text) in #17. I've created a table in that Issue for icons, so you/Allie can track what's up with each item's status.

Until all VisDe is wrapped & as new things arise, it'll be tough to deliver wireframes and/or animations with 100% final attributes from corner to corner.

p.s.: if my attempts at "being organized" just add more chaos than order, pls to let me know! order is teh goal.