Beta Export Flow

[ninavizz]

Summary

The client needs to be able to export files.
This issue is to cover all explorations, after determining the Briefcase direction was not right for Beta.

Functional Overview

Ohai, it's changed a lot!

Acceptance Criteria

• Invision presented to team w/ input solicited & iterated upon to team's satisfaction
• Prototype updated and published, with screens published to Zeplin
• Ticket updated w/ MoSCoW scoping for Iteration Zero through any Beta stretch-ideals
• Note: If security protocols change, that will be Yet Another Issue, and this will be closed as satisfactory to what the tbd followed requirements were.

[ninavizz]

Will need to create illustration of this and instruct users to plug thumb drive into marked port

[ninavizz]

Otay! First prototype, w/ my first flowchart in several months.

https://invis.io/58SJAT0HXTP

Primary open question: is the screen "SaveAs—B" in scope? It infers a lot of interactivity which could be just simple QT widgets, or scope creep. Likewise scope question, for multi-queued saves.

Looking forward to discussing.

[eloquence]

We reviewed this on Thursday in the UX meeting, and Nina and I had a separate 1:1 conversation about it as well. Overall this simplified export flow seems to be a good match for what's doable for the beta! :)

For the final specs, we agreed on the following:

• We'll remove "batch export" functionality from consideration for now. In beta, we may be able to do a simple "Export all" workflow for a given source, but likely nothing that allows users to queue up individual files. Whether or not we prioritize "Export all" will be informed by survey data.

• We'll need to spec out some first draft for help texts and error states that aren't currently spec'd out (e.g., bad password). This will be informed by @emkll's recommendations re: error states:
  Return export device state details as part of export attempts securedrop-workstation#264 (comment)

@ninavizz - please jump in if that's consistent with your takeaways, and please add any additional ones. :)

[ninavizz]

24 Jun Design Review

• Thee latest, here: https://invis.io/2GSPJWXJF63
  • UPDATED two things in the above thingy, following below review
    • Omitted inclusion of the drive name in the overlay's text
      • Implementation complexity ≠ priority for Pilot, and it'd be nice to just ask users if they'd find that useful there, anyway.
    • Added "Qubes launching VM" step before the "Insert Drive" step
  • Detailed if/then rules & logic, on second page
  • Global interaction model (basically contain it all to an overlay) on first page
  • Export link to have hover & active state
  • Orange and Red blob objects in the Insert Drive screens, speak to stickers or nailpolish on the user's laptop
• Discussion
• Jen: Is it important to journalists to see the drivename on either the Decrypt or SaveAs screens?
  • Nina: Feeling safe speculating 'yes' but to keep this simple am ok de-scoping that & just asking that question in the Pilot research
• Erik: Concerns with word "Save" on sticker
  • Will users conflate "Save" in export w/ "Save version w/in client"?
  • Cites users in testing all responding well to Export; has strong preference for Export
  • Nina speaks to "Export" as perhaps intuitive, but also offputtingly robotic/mechanical; preference for more human language, but not at the expense of usability.
• Allie: Use of USB hubs?
  • Lots of good chewy discussion! Users likely to also want a mouse or another device; discussion included lookup of the current spec for the machine being recommended, which does include a 3rd USB-C port that could facilitate a hub.
  • Would a hub be desired for disks, or just rando peripherals?
    • Complexity with keeping multiple drives mounted. Thoughts @emkll (NOT a priority)?
  • Erik: Feels we will have to support hubs at some point, but it's a hairy
  • Open Q: Are ports predictably or unpredictably mapped?
• Jen: Design prob of managing user expectations while Qubes opens Export-VM, needs addressing.

[ninavizz]

^ @eloquence @redshiftzero I added a new step to manage user expectations wrt Qubes opening the new VM. Curious to see in production & on a Qubes machine, if it functions as a confusing flash-blip, or if it works well. It's how I'd rather address the core design problem Jen flagged yesterday, vs a seconds-long active state on the "Export" button. Especially since all other clickable options on the screen need to be disabled the second the user clicks "Export."

[eloquence]

I added a new step to manage user expectations wrt Qubes opening the new VM

My understanding was that we'd boot up the disposable export VM the moment the SecureDrop Workstation is booted up, so there should be no delay involved in starting it up. The VM would be destroyed when the laptop is shut down.

@redshiftzero @emkll: Is there a reason not to do that, with the hardware requirements we are considering for the beta (X1 or similar ThinkPad/16 GB)? Is there significant complexity involved in ensuring the export VM is started on boot?

[conorsch]

Is there significant complexity involved in ensuring the export VM is started on boot?

Yes: if the USB device is not physically plugged in to the host machine on boot, then the export VM will fail to start, due to the persistent qvm-usb attachment setting.

[ninavizz]

@eloquence ...because we needed Yet Another Design Tool. ;)

I've pushed the latest Export wires to a new tool I'm exploring called Figma. Figma takes Sketch files and makes them editable by anyone, in the cloud.

https://www.figma.com/file/0q9J1nt8URwppCPQwX7cLfY0/export22?node-id=0%3A1

If you or others feel like futzing around with UI text in all the Export panes, Figma felt like a good tool to do that with. I've sent you and @redshiftzero invites, and am happy to invite anyone else. I'll also be using this workflow for editing/finalizing the Help UI texts. It seems to be a little nicer than GDocs, to be able to edit user-facing text in context.

Nope, not transitioning all work over to Figma. I know Ura uses them exclusively. Zeplin still seems like a preferred solution for delivering rich CSS deets, and I can use Sketch in my sleep I know it so well. Just FYI.

[ninavizz]

Updated version: https://invis.io/TNT1Q7XGH89

• Print/Export share ports
• Notes from latest design review (for Print, mostly)

[ninavizz]

Ok! Had a phat design review of the latest flowchart & messaging on 06 Aug. Design caveats were clarified and updated, per @emkll's continued work on this.

Action Items

• Multiple USB ports marked External for Beta is out of scope
• Cannot check to see if a drive is on other USB ports
  • Need to look at this in pilot observation: how often do users put perripherals into the wrong port and could be helped by messaging flagging that? How often do corrupt or otherwise un-mountable drives get plugged-in that messaging in the client could also deliver value from?
• Whether or not drive is specifically in External dispVM is all that can be checked for, before the disp-VM is open.
  • Cannot check for valid encryption or disk size
• Establish boundary between when External dispVM is already open vs when it's not yet open, as many checks need to be completed by scripts it will run and cannot be done before w/o significant refactor.

[ninavizz]

@creviera Pokie-poke! ^ :)

[ninavizz]

Implementation Updates

• No more persistent attachment; woo!
  • As such, no more required designated ports.
• svs-export (or whatever it's named) VM now to auto-open when Qubes starts
• Auto-attach solution still in flux

What this means?

• Much of the flowchart is now pretty different
  • Which is fine, since flowcharts are to help developers—and the code is close to final, now!
• Lots of mid-pilot enhancements afoot
• Also, given higher priority items requiring focus, no dynamic content other than the filename to go on windows at this time.

14 November Iteration

• PDF Here
• Details
  • Speedbump screens NOT reviewed; need to review in crit/discussion with Kev & Jen included
  • Co-Iterated on with feedback from @eloquence and @creviera
  • Learned in review
    • Showing the name of all attached drives is likely to be very buggy to implement, and could cause security risk
    • Filename likely to delivery little value as dynamic data shown, as drives are likely to be 16GB and most files are small—with the largest possible files, being 500MB; and with drive sanitation practices, it's quite a stretch drives would ever fill.
  • TBD things agreed to from review
    • Updated "pending" animation, that works better than spinner for being visible for one second or less
    • Update text from "Close" to "Collapse" (or something more standard) for collapsing the help pane
    • Yes, Help text is desired on all windows; yet to compose

12 November Iteration

• PDF Here
• Details
  • Nina created, after abundant conversation with @creviera
  • "Speedbump" screens at end, per updated understanding of broader task expectations
  • Encryption method changed from VeraCrypt to LUKS

[ninavizz]

25 Nov Iteration + Meeting Notes

• InVision here
  • NOTE: Mustard/pale "CLOSE" UI buttons, indicate those will go in (at 100% Grimace Blue) mid-Pilot. They have only been pulled for the Pilot Beta, because Concurrence is not an essential feature to launch the Pilot and is a req for those to work w/o crashing the Client
  • "Help" behavior is that the top edge of the pane will remain in the same place, and the window will expand-down to open that section.
  • The windowshade effect will also be triggered, when the first window opens; and will fade-out, upon the Confirmation window being shown.
• Meeting Agree-To Points
  • Agreement that "Entry Speedbump" is the direction we'd all like to take
  • All help content TBD and will be tackled in Content: Contextual Help Panes #61
  • Grey-box placeholder for "Spinner" needs to be completed by Nina per Complete Q animation #93

[ninavizz]

Closing as task was completed and tracked in above linked issues.