Bring export dialog language closer to spec, add filename

[eloquence]

Description

Towards #560.

Status

Ready for review. I have tested these changes in Qubes.

[sssoleileraaa]

I tested in Qubes here's what I noticed:

• The "Please insert one of the export drives provisioned specifically for the SecureDrop Workstation" is confusing because often the drive is inserted, just not attached. I think this should say "Please insert or attach..."
• "DONE" is more confusing than "CONTINUE" in my opinion. What the user wants to do is continue to export. However this matches this screen (I didn't realize until I did user-testing on myself that the language feels off here, and I'm curious what others testing on Qubes think -- we can update outside of this PR but thought I'd mention it):
  
• "Enter the passphrase for this drive" is title text, not body text. You'll need to either include title text changes in this PR or remove this line until title text is added to get it closer to the most recent changes in the design.
• Having more text in the first window that only appears on average ~0.5 seconds is a little stressful -- there's not enough time to read filename
  • We can ignore since this will change when we completely rewrite the first window to include the "speed bump":
    
• "File export in progress:" -> "File export in progress..."

[eloquence]

The "Please insert one of the export drives provisioned specifically for the SecureDrop Workstation" is confusing because often the drive is inserted, just not attached.

This is true now, but with auto-attach logic, it not being attached would be a bug in the logic, no? If so I'd prefer to keep the message just to "insert", unless we have reason to believe that users will have to routinely manually attach devices to VMs. If we do, then we'll have to explain how to do that.

[eloquence]

"DONE" is more confusing than "CONTINUE" in my opinion

That's per spec but I don't disagree, I also prefer "CONTINUE". "DONE" suggests to me that the process is finished.

[eloquence]

"File export in progress:" -> "File export in progress..."

I admit I intentionally went against the spec here to parallel with "Preparing to export file:", but happy to go back to "..." if folks feel strongly one way or another.

[sssoleileraaa]

I admit I intentionally went against the spec here to parallel with "Preparing to export file:", but happy to go back to "..." if folks feel strongly one way or another.

I don't have a pref here.

This is true now, but with auto-attach logic, it not being attached would be a bug in the logic, no? If so I'd prefer to keep the message just to "insert", unless we have reason to believe that users will have to routinely manually attach devices to VMs. If we do, then we'll have to explain how to do that.

Yes, the question is how unusual would it be for someone to detach a drive from the export vm. Also, if auto-attaching doesn't work for some reason at some point because of a bug with some devices or mutliple devices being inserted at the same time, or something else... then it would be a frustrating experience if we keep telling the user to insert their device when it's already inserted. They'll just keeping clicking "Done" and nothing will happen. We also already expose users to the concept of device attachment when we ask them to remove or detach a device from the export vm when there are multiple devices found, I believe.

All that said, this shouldn't block your PR.

[eloquence]

Yes, the question is how unusual would it be for someone to detach a drive from the export vm. Also, if auto-attaching doesn't work for some reason at some point because of a bug with some devices or mutliple devices being inserted at the same time, or something else... then it would be a frustrating experience if we keep telling the user to insert their device when it's already inserted. They'll just keeping clicking "Done" and nothing will happen.

That's fair. I think though that "or attach" is not sufficient to help with this. IMO this belongs in the troubleshoot text -- the kind of language we want to show inline in the dialogs for contextual help when something isn't working. And this really is troubleshooting.

[eloquence]

Regarding "CONTINUE" vs. "DONE", Nina and I kicked this around a bit today. She made the point that it's important to signal to the user that there's something that they have to do (i.e. insert the drive), because many users have been trained to click "Next" or "Continue" in dialogs like this, without actually reading the text.

We both agreed that "DONE" has its own problems, so upon discussion, I'm going to change this to "OK" for now, which is a more explicit acknowledgment than "CONTINUE". Let me know if that doesn't work for you, otherwise we can stick with that wording pending additional feedback / user research.

[sssoleileraaa]

Both "continue" and "ok" are ways of acknowledging some kind of message. What I like about "continue" is that it indicates that there is a process that has been started that you will move forward in. So "continue" still gets my vote. How about we discuss with @redshiftzero et all in the next ux meeting?

[eloquence]

Both "continue" and "ok" are ways of acknowledging some kind of message. What I like about "continue" is that it indicates that there is a process that has been started that you will move forward in.

Yup; the counterargument is that a gazillion install wizards have trained users that the thing to do when they see buttons like this is to move the mouse to the button as quickly as possible without actually reading what it's asking them to do. :) I don't know if "OK" is likely to perform better in that regard, and I don't know if we'll find out until we put this in front of users -- but also happy to discuss further.

[eloquence]

"Enter the passphrase for this drive" is title text, not body text.

Correct; this is currently displayed as a label in the position where the title of the dialogs should be, but now at least no longer uses the outdated "safe USB drive" language. I would suggest getting this PR in if it otherwise looks good, and then I'd kick it over to you to add the titles (or update the formatting of the label in this case). How does that sound?

I have fully tested this in Qubes now, which caused me to discover a content duplication issue which I otherwise would not have noticed :)

[sssoleileraaa]

lgtm