Improve clarity of Source Menu options

[rocodes]

Description

The "Source Menu" (3-dot overflow menu when viewing a conversation with a source) has grown and now has a number of different possible actions. This is a UX discussion issue to evaluate and possibly improve the clarity of the labels on each action, and/or decide if there are any actions we don't need to keep. (@tina-ux : please let me know if there's any additional info and/or screenshots that would be helpful! This is not meant to be dumped on your plate specifically, but want to make sure you have a chance to see and/or weigh in if you like.)

Details

Thanks to #1627, we have more functionality available in the source overflow menu (pictured top right). The actions include (current label: my description):

• Download all files: download all file submissions from a source
• Export Conversation Transcript: export a txt file containing a digest/summary of the entire conversation
• Export Conversation: export a text file containing digest/summary of entire conversation, plus all currently-downloaded files
• Print Conversation Transcript: print above-mentioned digest/summary. (Note that printing individual files is done by clicking the 'print' option beside the file when it is downloaded, as seen in the screenshot beside memo.txt. "Print all files" is not supported.)
• Delete All Files and Messages: empty the source account of content, while still allowing the source to reuse their codename and log in
• Delete Source Account: delete content and delete source account, meaning that source can no longer use this codename to log into the Source Interface.

I'm trying to keep this a very narrowly-scoped issue for ease of decision-making, as below:

In scope for this ticket

• Changing the labeling of options
• Removing options from the menu
• Re-ordering options in the menu

Not in scope for this ticket

• Adding options
• Changing the flow of any option (eg modifying print dialog, source deletion confirmation modal, etc)
• Moving options to different parts of the UI
• Extensive future-proofing (we want something that works with roughly the features that we've got right now, including Add action to (re-)generate and export conversation transcript and downloaded files #1627)

Discussion points

• I find the number of menu options that say "Conversation" to be kind of confusing
• I think the most useful option ("Export Conversation") gives the least hints about what it does.
• The ordering of destructive source actions at the bottom of the menu makes sense to me, but I wonder if the Export options should be re-ordered
• Download all is the only option with a keyboard shortcut (for now.)
• How clear are the menu options, from a translation/localization perspective?

I would love to hear what people think--are the menu options clear? How's the ordering? Any thoughts on improvement? Any options that we don't need to offer?

[rocodes]

@philmcmahon / @zekehuntergreen you are welcome to chime in as well :)

[gonzalo-bulnes]

Adding some context on the current copy (as of #1627):

• I've been pushing for calling the menu "Conversation Menu"...
• ...because I've been pushing for identifying that entire panel as the "Conversation"
• with the understanding that a conversation is an ordered list of (mainly) messages and files (making an implicit point that "message" covers both what is currently called Message and Reply, which are implementation details IMO)

In that spirit, I've been talking about the left panel as the "Source List", with the following in mind:

• there is a one-to-one relationship between a source and a conversation (so we can technically replace one word by the other in most occasions)
• the source is the closest concept we've got to the actual person submitting tips, whose safety we're trying to ensure, so it seems fitting to put it at the forefront and center of the UI, rather than a more impersonal "conversation"

---

To be extra clear: all of the above (and below) is up for conversation (no pun intended) — these are the guidelines I've been using myself pending further work on these concepts. Besides, that conversation will remain relevant post-pilot, so it's one very worth starting and having on an ongoing basis! As a matter of approach: I'd encourage us to start iterating on it, and take reasonable advantage of the pilot program, even if the outcome of the first iterations doesn't cover everything we wish for!

---

From the Source List / Conversation split above:

• I'd like to think of the menu as the "Conversation Menu", and remove all actions that have an effect beyond the conversation (currently: "Delete Source Account")
• The "Delete Source Account", for example, should IMHO be triggered from the "Source List", whether from the contextual menu attached to each "source (item)", or otherwise. ("Star" is another actions that applies to the "source (items)" for example, and that's before talking about selection. What I'm saying is that there is material for treating the "source/source account" as a distinct concept.)
• Once the menu is scoped to the conversation, we can drop the work "conversation" from all the actions
• Additionally, because there are less actions in the menu, we can start grouping them (example groups: "print", "export")...
• ...and think about keyboard shortcuts for the most often used actions.

[eloquence]

Thanks for the thoughtful write-up. 💯 agree that this will need some UX attention. The subtly different "targets" of each action present a lot of potential for confusion.

While I think you're right to constrain the scope, I do think it's worth thinking about what belongs in the dialogs vs. the menu, as well. For example, I don't think that the distinction between "I want to export all files and messages" vs. "I want to export only messages" is one that needs to be exposed at the level of the menu item. That would help us keep the menu length manageable.

For the most minimal iteration, here is how I would approach it, FWIW:

Currently:

• Download All Files
• Export Conversation Transcript
• Export Conversation
• Print Conversation Transcript
• Delete All Files and Messages
• Delete Source Account

Alternative:

• Download Files
• Export Messages
• Export Files and Messages
• Print Messages
• Delete Files and Messages
• Delete Source Account

I think the terms "Conversation" and "Conversation Transcript" carry more ambiguity -- files are part of the conversation, but not the transcript? And we're already using "Files and Messages" for the deletion operation.

I agree with Gonzalo's point above that we don't need to maintain a distinction between messages and replies at the level of terminology that is exposed to the user. Similarly, I'm not sure that the distinction between messages and a conversation transcript or digest is one that is sufficiently large to warrant the introduction of different terminology for export vs. deletion actions.

I also agree it's a reasonable approach to target the conversation using this menu (and potentially split out the source account deletion), but I don't think that needs to be stated in the action labels.

[gonzalo-bulnes]

Alternative:

• Download Files
• Export Messages
• Export Files and Messages
• Print Messages
• Delete Files and Messages
• Delete Source Account

This seems like a good first iteration to me, and I agree with @eloquence notes on the "conversation" term. By that I mean: while conversation seems simpler to me overall in absolute terms, it doesn't currently in a context where there is already a series of competing terms.

For future reference: Eventually, I think that "messages" for example really shouldn't need to be named: they're a tiny unit that we should be able to copy in place, without having to refer to it from afar. (E.g. there is no such action as "Copy Message" in Signal, despite the fact that messages are central to the application. Instead, you simply "Copy" a message in a narrow, unambiguous context.)

[rocodes]

Noting another suggestion from another Github ticket:

a 'download and export all' option would be helpful I think as that's what we'll want to do most of the time, but perhaps for a future bit of work

[zenmonkeykstop]

Looking at the options as currently implemented, I have some concerns about both current and proposed menu items. I think there's the potential for a bad UX experience resulting in unrecoverable data loss.

Hypothetical scenario:
As a journalist, I need to archive and wipe comms with a source. I'm not familiar with the client since I use it rarely, but I see there is a "Export Conversation" (or "Export Files and Messages") option, so I choose that, and then go through the export flow. I get a tarball on a disk that I can't immediately read without going to my Tails machine, and I'm late, so I choose "Delete Source Account", thinking that I have the files on disk anyway. However! Only the files that were already downloaded on the client are present in the tarball! Disaster! I've just wiped a bunch of submissions (and on the server too) that I thought were backed up.

I'd propose the following instead (sublists are submenus):

• Files and Messages
  • Download All > Messages are downloaded anyway so this is technically correct, the best kind, action already exists
  • Export All > download all files first, include the transcript by default, action needs modifying
• Message Transcript:
  • Export > action exists
  • Print > action exists
• Deletion
  • Delete All Files and Messages these 2 basically mirror the JI options
  • Delete Source Account

I'm not married to submenus for the implementation but that does seem like a logical split to me. If we can't have the option to download all as part of export all, at the very least we need to flag it to the end user if all files have not already been downloaded and give them the option to do so (apologies if that's already in and I missed it).

[gonzalo-bulnes]

Downloading all the files before exporting is not difficult to do. It is something that I considered doing (see this PR description).

The trade-off is that making the download of all files mandatory before exporting the conversation has the potential of significantly increase the time required to export a conversation.

Putting that trade-off against the scenario proposed by @zenmonkeykstop, I'd favor data safety over time savings.

---

There are, of course, other ways the problem could be solved, but I'm replying in the context mentioned in the PR description, and opting for a minimal change set for delivery speed over more comprehensive product design that would involve user research. The goal here is to elicit concrete feedback on the option to export an entire conversation, as part of the pilot program, not pretending to offer the best implementation at this point.

---

With the above context in mind, and with @zenmonkeykstop's proposal in mind:

• If the risk is data loss, I'd avoid adding critical information to a dialog that you probably don't read if you've used it many times before. Playing with the menu options seems reasonable to me.
• I would try to avoid sub-menus:
  • because the conversation menu is less accessible than a standard menu already
  • sub-menus would require journalists to have a good grasp of the "export, vs print, vs delete" mental model, and it would be a shame to miss feedback on an option because it wasn't visible enough (remember feedback is the goal here)
  • the conversation menu is a custom menu, the sub-menu pattern doesn't exist yet, and I'm not convinced designing that pattern now would be time well spent if we can avoid it
• If "Export All" will download all the conversation files, then "Download All" becomes less useful by itself, and I would remove it. (For historical context: that was the initial plan. The menu action was only added as a side-effect of PR sequencing and internal policies.)
• there is previous unreleased work that contained menu dividers
• standard menus favor grouping by action subject over grouping by action verb (because we often know what we are working with before diving into what we want to do with it)

That could leave us with:

• (optional divider that says "Messages")
• Export Messages
• Print Messages
• (optional visual separation)
• (optional divider that says "Files and Messages")
• Export All Files and Messages
• Delete All Files and Messages
• (optional visual separation)
• (optional divider that says "Souce Account")
• Delete Souce Account

[zenmonkeykstop]

That works for me @gonzalo-bulnes - I get your point about grouping by subject. The only reason I put both deletion options together was because they're both destructive and wanted to reduce the risk of soneone choosing delete when they meant export. But confirmation dialogs should cover that. I think there's still value to an explicit Download All option tho, as folks may just want to make sure they have a full conversation available locally.

[rocodes]

I am glad we're having this conversation, and Kev's points (about grouping destructive actions together, and about avoiding data loss) seem very salient to me.

I think we're getting warmer, but I don't think there's a clear enough distinction between "Export Messages" and "Export Files and Messages" for them to all be accessible at the same level in the menu without creating confusion.

[gonzalo-bulnes]

With the caveat that the grouping is made on "verbs" rather than "subjects", and that I'd recommend we avoid that in this case, here is a screenshot I made a while ago to illustrate available options. It shows what the dividers and visual separation would look like.

[zenmonkeykstop]

The dividers LGTM, it'd be interesting to see how it works with more entries.

[gonzalo-bulnes]

I can put a PR together so that we can look at it in context. (And adding/removing "Download All Files", editing the copy would be trivial from there.)

Edit to add:

I don't think there's a clear enough distinction between "Export Messages" and "Export Files and Messages" for them to all be accessible at the same level in the menu without creating confusion.

@rocodes and we can see how much the grouping addresses your concerns ☝️

[rocodes]

The PR above looks great and really showcases the dividers, but I wonder if we can make fewer [edit: or less overlapping] categories than {files, messages, messages and files, source}.

I'd be in favour of the word "Transcript" instead of "Messages", because I think it's more accurate (we don't support actions on specific individual messages).

My suggestion is

Files and Messages
    Download All
    Export All  *this would include the transcript
    Print Transcript
Source Account
    Clear All Messages *(This could arguably be in the previous category too. But there's something to me about separating "actions the source can see" from "actions the source cannot see.")
    Delete Source Account

and if this seems too radical, then I would also offer Export Transcript.

[gonzalo-bulnes]

I wonder if we can make fewer categories than {files, messages, messages and files, source}.

I personally don't mind either way. I went for what seems to me like the clearest, least room for ambiguity nomenclature. (But agree it's not very elegant.)

Clear All Messages *(This could arguably be in the previous category too. But there's something to me about separating "actions the source can see" from "actions the source cannot see.")

I love this line of thinking. I think those are the things we want to think about as we pass the pilot stage.

I really mean it! 😋

From some slides I put together in... Oct. 2021! soon after joining. The deck was called Naming UI Client Widgets.

Now, that being said, if you delete the conversation, that's visible to the source, isn't it? The messages in the Source Interface won't be visible anymore.

Additionally —again, those are personal preferences and I'm not attached to them at this stage— I'd prefer keeping the "Delete Source Account" action separate, because as I said above, I think it simply doesn't belong in that menu. (But I believe the action "Delete All Files and Messages" does belong to the menu, however we end up calling the action.)

[gonzalo-bulnes]

On the "Transcript" word, I like it too. It is short and accurate. Against: it is new. (Not a strong drawback IMO.)

[zenmonkeykstop]

@rocodes maybe Clear History or something instead of Clear all messages? coz it clears files too

[rocodes]

Those slides are cool, @gonzalo-bulnes. I don't think I had seen them before.

Now, that being said, if you delete the conversation, that's visible to the source, isn't it? The messages in the Source Interface won't be visible anymore.

Yes - this is exactly why I am voting that "Clear all messages" and "Delete source account" (whatever we call those actions) should stay grouped together in the same section. (As opposed to grouping the message deletion along with the other message actions like export and print). These two actions are destructive and have source-facing impacts; the other options (download, print, export) are non destructive and do not have source facing impacts.

@zenmonkeykstop - I'm not attached to "Clear all mesages". However, I prefer concrete phrases ("Delete files and messages", or "Delete all content") more than phrases that use a metaphor or turn of phrase (I don't love "History" or "Conversation" -- they're both a little ambiguous, and also, maybe will not be as amenable to translation).

[rocodes]

Files and Messages
    Download All
    Export All
    (optional: Export Transcript)
    Print Transcript
Source Account
    Delete all content [edit: consensus seems to be around "Delete files and messages" instead]
    Delete Source Account

?

[eloquence]

Without derailing an emerging consensus, just identifying a couple of potential areas of ambiguity:

• "Download all" under "Files and messages" may suggest to the user a download operation that results in some kind of archive they can operate on, especially if users have the mental model of "Download" from SecureDrop Server. This is to some extent already true with the menu in its current form, but I think the placement may exacerbate it.

• "Delete all content" may suggest to the user that "Delete all content" is the more destructive operation. This is mitigated by the dialog.

Ultimately I think it's best to validate these choices with users, so I think it's reasonable to run with a first iteration, but wanted to flag some potential areas to watch out for.

[zenmonkeykstop]

"Delete files and messages" is pretty unambiguous, maybe we shouldn't mess with success

[rocodes]

Ok so here's my proposal:

We put our best foot forward in terms of label and divider names into the PR that Gonzalo linked above (#1631), and share the menu screenshot to our pilot folks to ask them their opinions on what the buttons do. (I.e. "we are implementing some new features in the client. Can you tell us what you would expect from these menu options?" kind of question.)

(We should also put screenshots on GH for any dedicated souls who may be following our issue tracker but not part of the pilot, and make sure we include links to the support portal onion address and/or other private feedback channels to let them weigh in).

Since the features in question have been highly anticipated, and since @gonzalo-bulnes has been working on them for a while, I would like to expedite this as much as possible, while leaving room for people to comment. (e.g.: post screenshots this week, leave a week ish for comments).

What do others think? Also, thank you so much to everyone weighing in, really helpful to get feedback.

[eloquence]

I defer to @tina-ux, but I would also be fine issuing a release with our "best effort" and then asking folks for holistic feedback on the new features -- the menu, the conversation transcript format, the dialogs, anything at all. The papercuts may not be in the places where we expect them to be. As a goal (which I know is sometimes impeded by lengthy release/QA processes), I think we'll want to aim for being able to iterate quickly in response to user feedback.

[gonzalo-bulnes]

Yes - this is exactly why I am voting that "Clear all messages" and "Delete source account" (whatever we call those actions) should stay grouped together in the same section. (As opposed to grouping the message deletion along with the other message actions like export and print). These two actions are destructive and have source-facing impacts; the other options (download, print, export) are non destructive and do not have source facing impacts.

Of course 🙈 I don't know what I was thinking!

[gonzalo-bulnes]

"Download all" under "Files and messages" may suggest to the user a download operation that results in some kind of archive they can operate on, especially if users have the mental model of "Download" from SecureDrop Server. This is to some extent already true with the menu in its current form, but I think the placement may exacerbate it.

I second this thought. I don't think this is something we should address now, but I do believe that it will pay off to invest some user research time (and some thinking) to adjust the concepts we expose to journalists and the words we choose for them. We all use words in different contexts, e.g. "Download" as @eloquence points out.

At some point before the end of the pilot program, finding out if our choice of words is helpful or counter-intuitive to the folks using the application is a must do IMHO. That's something I know is in @tina-ux plans, and I think we're working towards establishing the conditions in which that work an happen, so I'm not worried but wanted to second @eloquence point.

[gonzalo-bulnes]

@rocodes's proposal sounds like a plan to me. Recapitulating with @zenmonkeykstop's suggestion, I'll put the following in #1631 and we can go from there:

Files and Messages
    Download All
    Export All
    Export Transcript (I'll include it, we can remove it from the PR in a blink)
    Print Transcript
Source Account
    Delete All Files and Messages
    Delete Source Account

• edit: I added All to Delete All Files and Messages for dramatic effect. That too is something we can revert easily in the PR. 🙂

[tina-ux]

Hey all, thank you for all your work and discussion on the topic.
I really appreciate the following choices that were made:

• Grouping destructive actions together (a+)
• Opting to use action verbs to describe menu actions
• Adding "All" to Delete Files and Messages

I'm late to the party, but I also agree that moving forward with the plan you have come up with above is the best way to go. It's a solid plan. We can refine along the way and devise quick user testing for feedback.

The menu looks great. What remains on my radar as very near future items are:

• Emphasizing the destructive nature of "Delete Source"
  (For example, Slack highlights higher risk menu actions in red: "Leave channel", which is not irreversible but leaves a trace and is high impact for the user)
  
• Reviewing the sequence of modals and messages following "Delete Source" and "Delete All Files And Messages"

Important items that are on my radar but need to simmer more:

• Like @gonzalo-bulnes mentioned: clarifying, unifying and standardizing SD nomenclature, and doing so from a user-centric perspective. We want to make sure the terms we choose to define SecureDrop pieces (UI, user actions and user-facing architecture) correspond to the world our users already relate to and the needs they are trying to meet. We also want to make sure we leverage the mental models on which our users are already relying, whenever possible.

The product-level work we are currently doing and the broader user interviews can help shed light on how to tackle this. It's a longer term effort.

[gonzalo-bulnes]

As a informational note: I was about to add very similar highlighting to destructive actions yesterday, and stopped short because in typical "Qt Style Sheets are not actually CSS" I ran into a selector precedence issue that I didn't find the solution to. 😞

On the way, I noticed yesterday that:

• only the "Delete Source Account" dialog is currently given the "destructive" treatment (red buttons, flipped around)

I take note today to:

• make the text red in the default action state (wasn't in my attempt yesterday, isn't difficult to do)

I'm not currently planning on investigating further the QSS selector precedence issue, because I made the call yesterdau that the highlight was a "nice to have" rather than a "must have" in the current context of the Client. Now that you've brought it up independently @tina-ux, we can change that assessment if you think we should! 👍

---

Edit to add: making the action text red in the default state may actually not depend on solving the selector precedence mentioned above, and may be a good first iteration even if the "selected" highlight remains blue. I'll look into it today.

Edit 2: would remain to decide what consistency we want:

• all "Delete..." actions look red in the menu
• or all actions that look red in the menu are given the "destructive" dialog treatment (currently only the "Delete Source Account" action)
• or both, which means changing the criteria to assign the "destructive" dislog treatment. (Currently, that only applies to the action that prevents sources from using their codename again.)

[gonzalo-bulnes]

Update: Nope, none of the above is trivial. The QAction instances don't support setStylesheet, and I find no way to add custom information to the built-in QMenu::item:selected selector. Arbitrarily de-scoping special treatment of actions for the time being. 🟥

[rocodes]

(Just want to say to @tina-ux's comment that it's very helpful/reassuring to get feedback about which underlying principles are most salient, and I think if while we're doing the product vision work we can accrue a list of these principles somewhere, esp the ones that guide our specific products, then I and others will be able to develop with them in mind. I'm thinking of the "group destructive actions together," or "highlight destructive/higher-risk actions", or the hint about verbs, etc.)

[rocodes]

Update: Some users experience regular file download failures on files we would not have traditionally considered 'large'. Blocking Export All on successful file downloads of all files may pose problems for their workflows.

So there's a tension here between our goals--OTOH, avoiding the potential for accidental data loss ("I exported 'all', so I'm fine to delete, right?"), on the other hand, not wanting to block users who want to export a bunch of stuff at once, but one file is failing.

Originally, I was thinking we should go ahead with the feature, but since the download issue affects files of a much lower size than we realized (therefore is a much more regular pain point), I think we should consider:

• reverting the change, so that export all does only export what's already downloaded, and instead popping up a confirmation modal ("You have not downloaded all file submissions for this user. Export anyway?"), and
• asking for more info in our user research study about frequency of file download failures and file size in a larger user population, with an aim to a better longterm solution.

What do others think? This might not be the most beautiful solution, but I'm trying to thread the needle here. Open to ideas.

[Edit to add: I will be doing some more testing with varying file size submissions later today]

[gonzalo-bulnes]

I'm in favor of adding the conditional confirmation dialog, edit to add: without necessarily conducting the study at this time. (I initially understood the suggestion as one or the other, my bad!)

Why?

I won't advocate for not doing user research, but I want to call out that performing an ad-hoc survey at this time is in no way a substitute for the product discovery, design and development process that some of us have been advocating for.

This work was performed within the context of the pilot program, under the agreement that we were aiming at getting concrete feedback quickly, and explicitly favoring iteration speed over production-readiness considerations. In my opinion, preventing data loss is one thing. The fact that we're trying to address foreseeable usability issues at this time, while laudable, highlights to me the need for a more robust design process and conflicts with the above stated goals. I understand the tension, and I'm only intending to make it explicit here, not to shut down your suggestion @rocodes.

To recap, in the current context, I'd ask: will this implementation allow to receive feedback about the desirability of the action item, and how fit the export format is to different purposes? Assuming that download failures don't entirely prevent pilot participants to answer those questions (which I don't think is what @rocodes is suggesting), I would move forward with the quick option (the confirmation dialog) and address all the feedback in a future iteration that's grounded in a holistic product process and includes the feedback gathered from this experimental implementation.

[rocodes]

Thanks for the info, @gonzalo-bulnes :) I have edited my comment to indicate that I see the options as "and", not or, to reduce confusion- and I'm also open to other options that others can think of - but your explanation makes sense.

[zenmonkeykstop]

Thanks all for working thru this, the confirmation dialog seems like the best option at this point, so a 👍 from me on that.

[gonzalo-bulnes]

Adding the following confirmation dialog if any of the files hasn't been downloaded yet:

[rocodes]

Hey, this looks very promising, thanks for preparing.

What do you(s) think about

Pithy option

Some files haven't been downloaded

Only files that have already been downloaded will be exported.
[CANCEL] [* CONTINUE *]

Wordy option

Some files haven't been downloaded

Only files that have already been downloaded will be exported.
To export current selection, select 'Continue.' To download additional files or review message history, select 'Cancel.'
[CANCEL] [* CONTINUE *]

(I don't love either of them, I'm torn between "explain the options" and not. I'm also torn about whether we need to explain how you can visually tell if a file has been downloaded, which I don't do in any of these options.)

[gonzalo-bulnes]

I prefer the second one. Within the bounds of keeping the dialog simple, I think that using the space available to make the situation as clear as possible is very worth it. (Situation: where am I, where can I go next?)

I particularly like how you've phrased:

To download additional files or review message history [...]

One minor nit, if that sounds correct:

- To export current selection,
+ To export the current selection,

[gonzalo-bulnes]

Thinking...

Some files haven't been downloaded

Is one step removed from the ongoing action. It matters because only downloaded files will be exported.

I think it could make sense making the header more immediately relevant, what do you think?

Some files won't be exported

[rocodes]

Some files will not be exported

Some files for this source have not yet been downloaded, and will not be exported.
To export the current selection, click "Continue."
[CANCEL] [* CONTINUE * ]

what do you think? (I didn't explain "Cancel"-- I think it actually makes the dialog less clear, when explaining "Cancel" with any other words than "To cancel this action, click here". I also expanded the contraction so it says "will not" instead of "won't".)

[gonzalo-bulnes]

(I didn't explain "Cancel"-- I think it actually makes the dialog less clear, when explaining "Cancel" with any other words than "To cancel this action, click here".

Sounds good 👍
I really liked how "To download additional files or review message history [...]" gave clues about why you'd want to cancel. But, none of that would happen by the mere fact you've pressed the "CANCEL" button, so it is arguably slightly ambiguous, and I think you're right to stick to the facts. Pressing the "CANCEL" button cancels the current action, and there is no need to expand much on that.

I'll apply those changes and post a picture. 🖼️

[philmcmahon]

Just caught up with this thread - thank you for all the thought and work that's gone into this everyone. Very excited to get this feature in front of a pilot user at my organisation.

[gonzalo-bulnes]

One more round. As I was typing it, something about the self-referential aspect of referring to the button in the dialog (To export [...], click "continue".) felt slightly wrong.

Asking myself, why we're adding that last line, I think it's because we want to express that it is okay to proceed as long as you know it's what you want to do.

Here's my attempt to solve that problem without naming the button itself (or assuming that your preferred input method is click, Enter, or whatever else). What do you think? Does it seem like the right problem to solve in the first place?

    Some files will not be exported

    Some files for this source have not yet been downloaded, and will not be exported.
-   To export the current selection, click "Continue."
+   You can continue exporting the current selection if you don't need those files.
    [CANCEL] [* CONTINUE * ]

Edit to add, "from this source" sounds better to me than "for this source", I'll give a try to that. Calling it out in case you disagree @rocodes (or anyone else! comments are welcome!)

[rocodes]

I'm sorry to nitpick, but I don't think I like the wording of "if you don't need those files", and I think the whole sentence is less clear and more ambiguous. If you don't want to refer to the button (I don't have strong feelings about that), I would say

"Export current selection? [Continue] [Cancel]"

[gonzalo-bulnes]

This is exactly the time to nitpick I think! 💯

[rocodes]

I like the second one, maybe with another line break between the two sentences [edit/ and/or whitespace adjustment if possible]. But I know that's what I said before and you didn't like the "click continue" (I agree it's very Windows 2002, I dunno.) What do you think?

[gonzalo-bulnes]

No strong feelings! Let's go with the second one (that's why I included it).

I'll add the line extra spacing. I think the dialog styling is not really fit for small amounts of text, but I wouldn't change that now. Here we go:

---

Edit: No worries if you'd rather not have that extra line after all! I find it looks odd both ways, and it's super easy to change. 😛

[zenmonkeykstop]

There isn't really a "selection" concept yet, as users can't explicitly select files to export. Would 'To export downloaded files only, click "Continue"' work?

[zenmonkeykstop]

Also liking @rocodes 's "To export currently-downloaded files,..."

[gonzalo-bulnes]

🍩 I updated #1631 and placed the dialog screenshot in the PR description 🙂