Explore how to Simplify Save Options

[deeplow]

From user research we found that it's not immediately clear to the user where the document will be saved. The save dialog need to be simplified and clarified. The feedback came from the 0.3.2 versions as well as the 0.4.0 version:

Notes / Evidence

During user testing some users were confused about the location of where the docs were and another wanted to change the location but couldn't find the option:

0.3.2	0.4.0
it looks like it's saving it to Downloads. I guess I just don't know if the original document was stayed in the downloads folder and never made it on something else.	So where will the safe document then be saved?
Does it default to like "name-safe" or is that something which is because you already preloaded it that way?	I can't see an option there if like if you wanted to save it somewhere else.
"I'm wondering where it's going to save it to as like the default"	(same also applies in this version)
"safe safe". There's two words... this word safe is in there twice.

UX (initial) Proposal

These were some of the options originally proposed by the UX designers:

(assumed) User Goals

Make sure the user knows where the original file is (for preservation purposes) Make sure the user doesn’t open the malicious file

Current Options Breakdown

Current Save option	UX Proposal	What the user has to think about
☑️ Save as [document]-safe.pdf	☑️ Add ‘safe’ to the end of file name / ☑️ Add ‘safe’ to the start of file name	Ending of safe files (or start)
-	☑️ Edit file name yourself	Name of saved file
🔘 Move original documents to ‘unsafe’ subdirectory	☑️ Create and move unsafe document/s to a folder called ‘unsafe’	Where Unsafe files are saved (*)
🔘 Save safe PDFs to [choose…]	Save new ‘safe’ document/s to [choose…]	Location of the safe files

(*) we have a caveat here: currently if the file fails to convert, it will stay in the same place, potentially confusing users and leading to them mistakenly opening the malicious file.

Conceptual Model of Dangerzone Conversion

Dangerzone currently moves files in two ways:

• It creates a new safe file with prefix / suffix (optionally in a different location)
• (optionally) It moves the unsafe file to a new location

[apyrgio]

Thanks a lot for presenting the user feedback in a concise manner @deeplow. To get the discussion rolling, here's my suggestion for improving the UX for file saves (hot takes alert):

1. Remove the file prefix option (-safe.pdf). This prefix is only necessary to differentiate between the potentially malicious file and the safe one, within the same folder. Users who find themselves in such a situation may click at the wrong file, especially if they converted a .doc file, and they now see a .doc file next to a .pdf.

2. Always move unsafe files to the unsafe/ directory, irrespective of whether conversion succeeds or not. This makes Dangerzone more robust against conversion errors due to malware. We don't want the conversion to end and users seeing only the file they originally selected. 9 times out of 10, they will probably click on it.

   • :fire: Hotter take :fire: : Create a PDF that explains that the conversion failed, and that the original file is under the ./unsafe directory, but the user is not advised to open it. If they know for sure the file is not malicious, they can file a bug on https://github.com/freedomofpress/dangerzone/issues, with the following error details: cue Python traceback and other details

3. Replace:

   Save safe PDFs to dirname | [Choose...]

   with:

   Store safe PDFs in the original directory | [Change...]

   If the user wants to save PDFs in another directory, they can select a new one and then the message will become:

   Store safe PDFs in path | [Change...]

   We'll have to deal with large paths in that case.

[deeplow]

• fire Hotter take fire : Create a PDF that explains that the conversion failed, and that the original file is under the ./unsafe directory, but the user is not advised to open it. If they know for sure the file is not malicious, they can file a bug on https://github.com/freedomofpress/dangerzone/issues, with the following error details: cue Python traceback and other details

Hum. There's the risk that the user thinks all is good and deletes the original files. Maybe we should create a new directory called "conversion-failed"

[apyrgio]

If we have such concerns we can either change the name of the resulting pdf (e.g., to *-failed.pdf), or ditch this idea altogether. BTW, let's keep in mind that this danger applies to successful conversions as well, where a converted file may turn out to be corrupted or unreadable (like in .xls documents)

[deeplow]

Solution Proposals

1. Standard Default Option + User Education

Define a single default save option and find opportunities in the user education to help them understand where the files have landed. I'd say @apyrgio's proposal above sounds like a pretty reasonable approach. This way we don't have to ask users for where they want to save it.

Educational opportunity examples:

• When conversion is taking place show some animations of where files will land
• After the conversion is finished show the path where the unsafe files are stored (if they were moved away)

2. Reduce to max two options and present them visually

Somehow visually portray the options and help the user understand them. (Maybe without annoying animations and much smaller)

☑️ Move unsafe file away	☑️ Save safe version beside original

3. Embedded Document

This idea is a recognition of the two features Dangerzone has: making documents safe to view and stipping the metadata. One doesn’t necessarily always want to have both.

This proposal consists of including in the safe version the original document but in a way that makes it harmless. This way the document could safely be opened. Should the journalist want to recover the original file, they could recover it using Dangerzone.

However because journalists may also want to make a document safer for publication by removing the metadata, we could add this by having another mode, which does create a new safe file, but asks the user explicitly where to safe it (it would probably not be a bulk thing since if journalists want to publish en-masse, they may as well want to publish the originals).

What could this look like in practice?

(borrowing some of @Erioldoesdesign's design assets)

Fundamental Change in Conversion Conceptual Model

Embedded Conversion (safe mode)	Embedded Conversion (publish mode)
In "Safe" mode, Dangerzone makes the document harmless. This can later be reversed by using Dangerzone.	In Publish mode, dangerzone also remove the metadata and saves the file in a new location.

[Erioldoesdesign]

Always move unsafe files to the unsafe/ directory, irrespective of whether conversion succeeds or not. This makes Dangerzone more robust against conversion errors due to malware. We don't want the conversion to end and users seeing only the file they originally selected. 9 times out of 10, they will probably click on it.

Generally, what happens when a user already has a folder called 'unsafe' (or another version of 'unsafe' folder say i'm a journo that has very good file/folder hygiene and I have a folder called 'Ready to read', 'Ready to send' 'Received files' (maybe in received files I have 'processed' and 'unprocessed' etc.

Does dangerzone make a folder called 'unsafe_1'? does it overwrite the folder and it's documents? does it recognise that there is already a folder called 'unsafe' or 'safe' and save in there? (but only if there is an unsafe/safe folder in the file-level directory).

Essentially what I'm trying to figure out is there are two types of extremes of this user:

User 1 - very particular, structured and safe with how they save and manage files. Has a specific folder (possibly encrypted) for documents. Relies on the location of a file to know whether it should be opened or not.

User 2 - gives zero care to file management, files are everywhere across desktop, folders etc. has multiple places they save files. Relies on the file name to know whether it should be opened or not.

And then all users in between?

So we should think about what both of these user extremes need from both a 'save a document...' journey and a 'what document am i opening...' journey and a 'what the heck happened to my document...did it fail in processing' journey.

[deeplow]

Those are super relevant questions. It seems like a good approach to understand what makes sense for Dangerzone.

Does dangerzone make a folder called 'unsafe_1'? does it overwrite the folder and it's documents? does it recognise that there is already a folder called 'unsafe' or 'safe' and save in there? (but only if there is an unsafe/safe folder in the file-level directory).

For clarity, let's say the user has a directory structure like this:

documents/
 |--- doc1.pdf
 |--- unsafe/
        |- doc2.pdf

After running Dangerzone on doc1.pdf the result is:

documents/
 |--- doc1-safe.pdf
 |--- unsafe/
        |- doc2.pdf
        |- doc1.pdf (original)

If instead the user had ran it on doc2.pdf it would look instead like this:

documents/
 |--- doc1.pdf
 |--- unsafe/
        |- doc2-safe.pdf
        |--- unsafe/
              |-doc2.pdf (original)

This is particular edge-case where Dangerzone can be confusing for users and we haven't considered it much. But it may happen.

Hopefully this clarifies your question.

[Erioldoesdesign]

Those are super relevant questions. It seems like a good approach to understand what makes sense for Dangerzone.

Does dangerzone make a folder called 'unsafe_1'? does it overwrite the folder and it's documents? does it recognise that there is already a folder called 'unsafe' or 'safe' and save in there? (but only if there is an unsafe/safe folder in the file-level directory).

For clarity, let's say the user has a directory structure like this:

documents/
 |--- doc1.pdf
 |--- unsafe/
        |- doc2.pdf

After running Dangerzone on doc1.pdf the result is:

documents/
 |--- doc1-safe.pdf
 |--- unsafe/
        |- doc2.pdf
        |- doc1.pdf (original)

If instead the user had ran it on doc2.pdf it would look instead like this:

documents/
 |--- doc1.pdf
 |--- unsafe/
        |- doc2-safe.pdf
        |--- unsafe/
              |-doc2.pdf (original)

This is particular edge-case where Dangerzone can be confusing for users and we haven't considered it much. But it may happen.

Hopefully this clarifies your question.

Absolutely clarifies the processes thank you :)

It's one of those tricky situations where we ask ourselves, 'As a tool team, how much do we want to help users be better at file management' which is hard to answer

[eloquence]

I want to +1 Alex's suggestion to move the original files out of the way (in some way) independent of conversion success or failure. Basically, the moment the user has chosen to apply DZ to a set of files, it seems reasonable to do all we can to reduce the risk of accidentally opening the unsafe originals.

If we don't go with the embedding approach, I wonder if appending to the original file's extension might be worth considering (with possibly a built-in feature to reinstate the original name). I realize different operating systems rely on it to a different degree, but it seems like that might further reduce the risk of accidental opening with the default viewer.

[harrislapiroff]

My intuition is that the embedded unsafe file is going to add more confusion to the flow, but it's possible we could do some wireframe/mockup testing to see. I also tend to agree with @rocodes's comments in Slack on @deeplow's specific mockup:

this design pre-supposes use cases with user stories (who's to say that "for sharing with trusted parties" is when sanitize should happen?) so I would be more in favour of a flow that describes what they are gonna do, vs bundling the action with our interpretation of the action (so sticking to "sanitize", "keep original", etc)

I think I can imagine journalists (or non-journalists!) coming to this interface with intentions that don't match either sharing the document or publishing a news story and that interface would add some friction to understanding what's going on.

My inclination would be to do something minimal but clear and then trust that the users know how to manage their own files (this may be misplaced trust, but there's a limited extent to which we can make up for users not knowing how to manage files, imo)—something more along the lines of @deeplow's "standard default option + user education." I am intrigued by @eloquence's idea of adding a file extension. Here's a mockup of what that could look like, assuming the modal that pops up after selecting a file to convert:

(I'm just using a default macOS UI kit here, so read this more like a wireframe than a specific aesthetic.)

[deeplow]

Interesting! I like where this is going. The confirmation prompt is a good vantage point for educating users (even if we don't go with the extensions idea).

I am intrigued by @eloquence's idea of adding a file extension.

I like that idea as well. Just wanted to mention that on some OSes (some linux distros) the program which opens is are not inferred by the extension, but instead by the mime type (infered by magic numbers and other aspects).

My intuition is that the embedded unsafe file is going to add more confusion to the flow, but it's possible we could do some wireframe/mockup testing to see.

And I agree that the Embeded Document idea is risky and needs user testing validation. I would understand if we end up not pursuing that. Regarding Ro's comment, I don't think those use-cases are set in stone. Those were just process names, we could label them according to what they'll do: "sanitize" or "sanitize + remove metadata".

[harrislapiroff]

Some notes in advance of our internal meeting today:

I think we're coalescing around a simplified save interface like the one I gave as an example above where we have a default (or possible only) behavior and we explain what it is. This leaves a couple open questions:

• What do we want that default behavior to be?
• Do we want to provide alternative behaviors at all (possibly under an "Advanced Options" foldout)?

I think it's helpful to weigh the pros and cons of each option. Here's a list of some of the options we're looking at that I think we should list some pros/cons of:

• Add .dzpdf extension to original
• Add "safe-" or "sanitized-" to start of name
• Add "-safe" or "-sanitized" to end of name
• Specify name yourself
• Create a "quarantine/" folder and move files there

Please chime in with any other options for consideration!

A couple of my additional thoughts:

• To some extent we have to trust that users can manage their own files (as I said before) and we don't need to offer them every option under the sun when they have the capability to rename files themselves at the OS level.
• This does mean sometimes our default workflow won't be what users ideally want, but I think we should optimize for the most common use cases and think about escape hatches for people who need different workflows (I think dangerzone CLI is a good way to allow people to do more in depth scripting if they need specific filenames; maybe we could provide Shortcuts actions on macOS someday, etc.)

[harrislapiroff]

After discussing internally we've made the following decisions:

• We'll keep the default behavior of creating an unsafe/ (or unsanitized/) directory in the location of the original file and move the original file into it. We felt this option has the most going for it of all the options, despite a few downsides.
• We will improve the messaging about what is about to happen before processing begins.
• We will move the file immediately when processing begins. This may necessitate extra communication if processing fails so users know where their original files are.
• We will add a "-safe" (or "-sanitized") suffix to the processed file to add confidence that it is safe to open.
• If we don't have sufficient file system permissions to rename the file and/or create a new file, we will throw an error that is clear about the issue and explains how to resolve it.

The following questions are still open for exploration:

• Do we prefer the language of "un/safe" or "un/sanitized"? (Or is there a secret third option?)
• Could we take a more aggressive approach in the future through file extensions, mime types, or OS-level APIs to indicate the status of a file or prevent users from opening it? For example, Dropbox adds badges to files to indicate their sync status. (This is both a technology and a user-research question.)
• How best to communicate that the original file has been moved, even if the processing failed?
• Are there better ways to handle the case where we don't have write-permission on the original file or directory?
• Do we want to expose alternative options for file moving/renaming under an advanced options foldout?

[apyrgio]

Tangent, but I did a quick dig on showing status icons for safe/unsafe files. Here's what I found:

• Windows has the IShellIconOverlay hook.
  • One open source project taking advantage of it is TortoiseGit, in case we want some source of inspiration.
  • Fun fact, the native shortcut icon (arrow pointing up) uses this very method.
• Linux (well, Nautilus) has its own hooks. See how Dropbox utilizes them: https://github.com/dropbox/nautilus-dropbox

[Erioldoesdesign]

The following questions are still open for exploration:

• Do we prefer the language of "un/safe" or "un/sanitized"? (Or is there a secret third option?)
• Could we take a more aggressive approach in the future through file extensions, mime types, or OS-level APIs to indicate the status of a file or prevent users from opening it? For example, Dropbox adds badges to files to indicate their sync status. (This is both a technology and a user-research question.)
• How best to communicate that the original file has been moved, even if the processing failed?
• Are there better ways to handle the case where we don't have write-permission on the original file or directory?
• Do we want to expose alternative options for file moving/renaming under an advanced options foldout?

From a designer/user pov:

Slight preference for Unsanitized/Sanitized language - it's a longer word and not really following 'simple' language UX content rules but it's more clear than 'unsafe/safe' Since DZ isn't actually making the original file safe - it's making a copy that is safe. There's not really one word that fully describes what DZ does but functionally ('scanned' copy) and conceptually (makes docs safer than they may have been) so this is a decent middle ground word.

I love the dropbox icon overlays - I looked them up here and they are super helpful: For testing those I would recommend setting up a test on https://usability-hub-design.netlify.app/ and then sending the link out to user testers to complete. (happy to show y'all how to use this tool - it's free if you don't want to use their user tester recruitment panel)

re. moving the file even if process fails. An overlay pop up i think is best in this situation as two major things have happened: Users original file has moved and also the process failed. Options to retry the process in this dialog would be helpful. I would tell users first that their original, potentially risky file has been moved and then that the process failed. If you tell them the process failed first they will go into problem solving mode and may ignore the 'file has moved' info. Then it's all about trying to offer potential pathways of finding out why the file failed which is likely an FAQ/guide on a webpage.

re. write access does this get indicated to a user when they try to select a file in a view only directory to process? I would try to indicate as early as possible that selecting a file from a read only directory won't allow optional DZ processing to happen and to move to a read + write directory without opening the file. This is a tricky UX flow where the user could accidentally open the potentially harmful file without meaning to. Is there a way DZ could make a read + write directory if the user agrees to a series of UI prompts? feels like a big feature dev but very helpful.

^ re. advanced options moving/renaming files sounds like a good idea but I can't conceptualise what these needs would be functionally - seems like this a UX survey question to users or a short UX research question that could happen when conversations with users happen

Hope this is helpful 😄

[apyrgio]

Slight preference for Unsanitized/Sanitized language - it's a longer word and not really following 'simple' language UX content rules but it's more clear than 'unsafe/safe' Since DZ isn't actually making the original file safe - it's making a copy that is safe. There's not really one word that fully describes what DZ does but functionally ('scanned' copy) and conceptually (makes docs safer than they may have been) so this is a decent middle ground word.

I like your distinction, that "safe" implies an in-place operation, whereas "sanitized" a copy. Let's have a straw poll and find out what others think!

I love the dropbox icon overlays - I looked them up here and they are super helpful:

:slightly_smiling_face:

For testing those I would recommend setting up a test on https://usability-hub-design.netlify.app/ and then sending the link out to user testers to complete. (happy to show y'all how to use this tool - it's free if you don't want to use their user tester recruitment panel)

Cool!

re. moving the file even if process fails. An overlay pop up i think is best in this situation as two major things have happened: Users original file has moved and also the process failed. Options to retry the process in this dialog would be helpful. I would tell users first that their original, potentially risky file has been moved and then that the process failed. If you tell them the process failed first they will go into problem solving mode and may ignore the 'file has moved' info. Then it's all about trying to offer potential pathways of finding out why the file failed which is likely an FAQ/guide on a webpage.

Makes sense to me, we don't want people opening files that failed.

re. write access does this get indicated to a user when they try to select a file in a view only directory to process? I would try to indicate as early as possible that selecting a file from a read only directory won't allow optional DZ processing to happen and to move to a read + write directory without opening the file.

Yeah, we can add an indication after the file has been chosen by the user, that conversion cannot happen since the folder is read-only, and suggest them copying it somewhere else, without opening it. Note though that this check may not work 100% of the time.

This is a tricky UX flow where the user could accidentally open the potentially harmful file without meaning to. Is there a way DZ could make a read + write directory if the user agrees to a series of UI prompts? feels like a big feature dev but very helpful.

Sigh, the thing is there are cases where the user can do nothing about it (think write-protected USBs, for example). In cases where they can, it will be tricky making Dangerzone elevate its privileges in a cross-platform way. So, I'd opt for not going down that route :/

^ re. advanced options moving/renaming files sounds like a good idea but I can't conceptualise what these needs would be functionally - seems like this a UX survey question to users or a short UX research question that could happen when conversations with users happen

Definitely, that's a question we don't need to answer now.