Pre-Beta design for Files display in Client

[ninavizz]

The elegant list-ish view currently spec'd in Zeplin is most likely out of scope abreast other priorities for the Pilot's Beta release. That said, the established design is in-scope to be deployed mid-Pilot... which could be an exciting happenstance for soliciting user feedback.

This is the current state of the Client, 28 May 2019:

Following discussion with @creviera and @eloquence the below was established as a prudent implementation to plan for. As such, we need some basic design improvements from what exists today.

Goals

• Not look "Broken"
• Aesthetically consistent w/ Client
• Still clearly usable & with appropriate action cues
• Ideally spec so files can take-up less space in the conversation pane, while not demanding too much dev bandwidth.

For context, many unrelated items have also been listed below for establishing ordering of priorities.

MUST

1. Replace today's uglypants/temporary icon with a less unattractive icon — same size, etc.
2. Add "Active State" to today's widget, that would show Icon and Text both at 40% alpha, and later be expanded to include an animation spinner.
3. Tackle #163
4. Implement basic activity descriptors to replace refresh timestamp next to refresh icon.
5. Add LDS-ring animation atop icon for file's download/decrypt Active state. Animation will begin when user clicks "download" and will end once file displays "Open"
6. Implement Conversation pane timestamp
7. Get all-things errors/success resolved in the UI

SHOULD

8. Get "Help" pane into Client w/ content & contextual links for Whonix, Export, Password/2FA fail
9. Get first version of Export into the Client
10. Implement logic to color different journalist badges uniquely within a single conversation
11. Implement logic to determine grouping in preferred list-view UI
12. Begin to apply list-view/final UI File Pane Styling
13. Unresolved Errors pane w/ per-item details and deletion
14. Enable per-file deletion

[ninavizz]

First Iteration

• Many versions to look at; Nina prefers the last 2 screens (the last screen just shows a variation in view on the prior)
• Core difference in all the screens, speculated to be the amount of work required to close the gap from where we are today, to a less-sucky/Beta-acceptable option
• Screens A & B show what I speculate to be the least-effort-involved implementation... however, the remaining presence of an icon will be problematic (see below). Likewise, the "visually jiggered" list of actionable items when there's many downloaded files (B), kind of really sucks.
• Concerns w/ Icon Use for downloaded files
  • When a file is shown that was pre-encrypted or is a compressed archive, the "document" icon is inaccurate—potentially even deceptive wrt the flow implications (eg: the user will need to act on those files in File Manager, vs opening an immediate preview of their contents).
  • The whole point of this issue, is to bridge the gap between the current implementation of showing files and the current design recommendation (which would require additional logic to make possible, on an aside from abundant styling differences) with a much lower-effort option.
  • If there is a strong desire to show icons in the attachments grouping, a different icon that can speak to either the concept of "Send this to file manager to further act upon, there" or the concept of format differences (encryption vs compression) would be required; adding logic to show 2 or 3 icons in any of the list items. If we're then adding that level of scope-creep, I would prefer just going with the initial recommendation this Issue was created to scale-back effort from.
• Having read Nina's Soapbox... see screens! https://invis.io/AJSH8Z89EUV#/368239467_PBF_-A-
  • See names for each version in the lower-left corner, on the translucent black bar
  • Zoom-out in your browser window to fit the two little pink arrows on the top, into view
  • Navigate with the 'lil pink arrows
• For comparison, see OG Recommendation (that involves custom animations and logic to establish a "batch" of file submissions).
  • @kushaldas I've invited you to Zeplin... see ReadMe at top and check out the referenced GH article, later—for now, you'll just need to accept the invite to see the screen. :)

[ninavizz]

Oops, forgot to include truncation and hover. Added to final screen! :)

[eloquence]

Thanks for these, @ninavizz! I suggest we formally review in an the next Monday client meeting, to keep the weekly UX meetings a bit broader in scope. I've tentatively added it to the agenda.

Extracting filenames for submitted files is on the current sprint (freedomofpress/securedrop-client#163), but I think it's fine if the first iteration of this just inserts the filename into the existing UI element.

Quick asynchronous feedback, I do feel that the next UI iteration should introduce a basic grid layout for files and actions. This screen feels like a good compromise option to me. If we have to choose, I would prioritize disclosing long filenames via hover, over other stylistic improvements.

[ninavizz]

The correct text styles (font, weight, color, size, line-height, etc) have yet to be implemented in the client, anywhere (that I've seen)—and tbh, those should happen before any styling to just the files.

[ninavizz]

Also: at some point in the near future it'd be nice to include into a sprint "Update ALL UI styles to polished-state" so that more decisions about "what next?" could be made from how it all looks in code.

All of my "design decisions" are to-date based on how things look in rasterized, static mockups, and it's been my experience that we'll all want to change some things once we see how logic, behavior, and app-rendered assets look. Especially with all the color/hover/states things. Might this be a possibility?

[ninavizz]

• In conclusion of 17 Jun's design review this was agreed to as the desired direction to move forward with.
• Following the review, the following were prepared per next-steps discussion:
  • Create version w/ download icons isolated in their own column & all else left-aligned to the right (see here, too)
  • Create version with items ordered as Icon - Filesize - download/name - Export/Print??
    • Allie requested, just to see what it could look like per desire to do filesizes and icons each as their own columns
    • Bolding done to assist with visual hierarchy and click areas... and with that bolding, this version gets kiinda wacky.

---

Verdict, gang @creviera @redshiftzero @eloquence ? H1b remains my personal pref, but we're a team and that matters. :)
Shd we get Kushal's $.02?

[sssoleileraaa]

Isolating the download icons on the left-hands side makes it much easier to see what needs to be clicked on for download still. I wonder if changing the color of the icon and "Download " to urgent magenta would make it even more apparent that they are files that can be clicked on?

I'm not finding the screen with the filesize left of the filename or "Download" word.

[sssoleileraaa]

Now I'm wondering if there was ever a prototype version that shows the "DOWNLOAD" action on the right-hand size where we show "EXPORT" and "PRINT"?

Something like:

12 MB   handbook.pdf ........................................ EXPORT | PRINT
144 MB  Scanned from a Xerox Device.pdf ..................... EXPORT | PRINT
6 MB    [Encrypted] ......................................... DOWNLOAD

[ninavizz]

So, I did the mockup you were curious to see—and added clickable-footprint overlays to the other Zeplin mockups.

Thoughts, below:

• "Urgent" colors (magenta or coral—and magenta is unlikely to get used, at this point) should only be used to indicate an error state; blues trigger users to want to click on something (hence, why I want the 'Upload' icon in the Source UI to be grey instead of blue). Not magentas, unless that thing had previously been blue before it was in an error state.
• The schema you did above looks great as ascii. In the visual design though, it's confusing. Also, it doesn't prioritize the information users are most interested in, when they're most interested in it. Like—filesizes will inform choices, but are not the primary point of information for organizing something. LTR presentation of information on each single line, should be in order of how a user needs to read something, with all actions on the right for files already downloaded. The action to download, is more important for a user to see than the fact that a file remains encrypted.
• Regarding the icon as its own column... the whole word "Download" with the icon, is a clickable area. Same with the whole word of a filename—yet both do different things. It's weird to stagger the clickable footprints, and it's not more visually pleasing to me, to have the icons in their own column to the left. That table serves a dual purpose, and users finding what they need in a reasonable period of time for a variety of scenarios, is what's most important—not so much one scenario over another—and within a visually pleasing layout.
• I know I created this ticket to provide a quicker-to-code version of the FIles Pane view than what had already been designed—but I really do not want to optimise around using columns. That creates a sub-par reading experience for users, despite perhaps optimising for developers. It would also create design debt that would make implementing the correct solution post-Beta, take longer, I suspect.

I still prefer H1b as the version to go with. Happy to discuss in further detail when I'm back in the office, Thursday. :)

[eloquence]

Thanks @ninavizz! Per discussion at sprint UX review today, the one revision we'd like to look at is a version of H4 with the position of the file size and the file actions swapped (actions to the left, sizes to the right). That option seemed to have potential consensus as a first iteration to shoot for.

[ninavizz]

Following the above, these have been produced as the final direction Screen · Spec w/ notes, in addition to the Post-Beta design being reconciled with this & the omission of the Briefcase feature.

See Spec notes in Zeplin, regarding l10n challenges. Would be curious if LocLab has any thoughts on those points @eloquence... ??

Post Beta (final desired direction)

• Concept of "Batch" to group all files below message most likely sent in parallel
  • May mess w/ Source expectations of how journalists receive/see their submissions?
  • May be best to defer until mass-file upload possible in Source UI
• "Download All" from "Batch" included as feature
  • For Beta, "Download all files from this source" possible to include as "More" menu item
• Per-file deletion
• Super sweet animations for Download/Decrypt
  • Ideally progress-polling feature built-in to support
    ~
    

For Beta (working towards the above)

• Files and messages each shown in chronological order
• Simple CSS-only animations for Active states (shown in spec)
• Needs to scale to support l10n
  ~
  

[eloquence]

Thanks, this looks great to me, @ninavizz! Closing this issue for now, we can revisit if we need to make further iterations.

Thanks for flagging the grid sizing question. At minimum I think we may want some dynamic sizing for the leftmost and rightmost column, to account for language differences, and that's good to keep in mind early.