-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable a user or Export to "Download All" files to the Workstation for a given source #1354
Comments
Arrow icon and other details, in Figma file. |
Gherkinny Goodness!Note: Towards the bottom, the scenarios are less and less thought-through; I will be updating these tomorrow when I'm in! Scenario: New files to download Then, the state of each file's buttons will change from "Download" to "Downloading," with the little spinners—so, 7 little spinners will appear with respective downloading texts, as if the user had 1, 2, 3... clicked upon each with their mouse. Then, one by one, as each file’s download has completed, I will see each button's in-progress state change to the dual-buttons "DownloadED" state showing “Export · Print” I will also hear a "ting!" sound upon each file's availability to view/print/export.**
Scenario: New and old files to download Scenario: No files to download Scenario: User in multi-SDW using org Scenario: Connection Fail Scenario: decryption fail Scenario: absent keypair Scenario: hyperactive journalist, +xxmb of data invoked for downloading Scenario: I've downloaded everything already, but just got a fresh Workstation install or machine (@eloquence, has this been resolved yet separate from download all?) |
^^ #1362 should ideally go into the same release, as this. Not necessarily the same PR—let's keep PRs small/manageable—but definitely in the same release. :) |
Currently the kebab menu is already disabled until we hear back from the server that the conversation is scheduled for deletion. I think it makes sense to disable the menu while the operation is ongoing. There is an edge case where a user could export files immediately (within seconds) after the deletion is scheduled on the server and actually export the local files, but that is an extreme edge case and will go away after we implement v2 for the journalist api. I think we should always have a dialog, whether or not it exceeds capacity to a) give a condensed list of files about to be downloaded next to their individual size given that it's easy to lose track of files in the scroll view, and b) give the users a consistent workflow. If not as a final implementation, at least as a first implementation of "Download All."
This makes sense to me, but we have to consider what signal to use to re-enable the menu option. Currently we fire off jobs and wait until their success and failure signals are emitted to communicate back to the GUI. If a duplicate job is submitted to the queue (say from accidentally double click a button that fires off two of the same jobs) it automatically gets dropped. So technically it's easy to handle multiple "export all" actions, and I would argue that this should go in the first iteration. It is useful to communicate to the user when an option does not really do anything by disabling it, but we'll have to signal back to the GUI the completion of the last download. One way is by using a Another way to do this requires more complexity in tracking which files have been enqueued and which have not per conversation. It's messy because sometimes there is an error or jobs are cleared out during a deletion operation. It would be cleaner to not have to keep track of this state. It might make sense to just keep the option enabled for our first implementation, since we already won't add duplicate jobs to the queue. But let's discuss more ideas of how to implement this in an elegant simple way. I do like the idea of relying on a job that singles back the the GUI "I finished successfully and I'm the last job, so re-enabled the menu option if it's disabled, please."
Our priority queue allows us to do this. If the deletion options are enabled after enqueuing all the download jobs (sounds like this is preferred but we may want to consider a way to just "cancel" the downloads instead, or in addition), we can just clear everything not currently being processed in the This is as far as I got when going over these scenarios with @gonzalo-bulnes today. There's a lot to discuss here, and eventually we'll need to figure out how to plan all of this work. But for now, we'll start by going through all of these scenarios. The sprint ends next week, so I'm curious @gonzalo-bulnes how you're feeling about actually getting a minimal implementation of "Download All" done within the next 50 hours? First we'll have to scope this down, and plan out different phases of the work, so it would be useful to check back in on whether or not our original goal is still obtainable (https://github.com/orgs/freedomofpress/projects/1#card-73875766). Seems like there's still a lot of scoping and planning work needed, so i think it makes sense to put "Export All" (https://github.com/orgs/freedomofpress/projects/1#card-74026456) on the back burner and to redefine the "Download All" sprint commitment. Thoughts @gonzalo-bulnes? @eloquence? |
Thanks all. I would propose narrowing the scope for the MVP and subsequent iterations using the MoSCoW method. We can chat more about this tomorrow/Wednesday. |
I didn't want to do a dialog, because of how often I expect users will be doing this @creviera (based on speaking to users in multiple interviews and testing). We've learned from Journalists that Sources often upload multiple files in a sitting—so Journalist users, I expect will be doing Dialog fatigue is a very thing, and we need to be very careful to not over-do it. I think a Download Most, later, where yes, journalists can pick/choose which they want to download, could potentially have value—but it's also been observed (thus far) that Journalist users want to download either everything or nothing. Until big orgs with multiple users are all on the Workstation (so, not for the next 2-3yrs), I don't see that changing via research to date. I thought a lot about what we'd discussed earlier (just before I left for CrossFit, and if a news organization is acting on a Source—they typically want to download & transfer everything. Not just a few things. Especially customers that have external workflows they need to transition all Source materials to, once a Source is deemed legit. Remember: only 1/10 sources is not spam, and those Sources orgs tend to want everything from. |
Ok! Figma does keyboard shortcuts, so on my Mac I did this as If/When you want to "replay," move your mouse outside the gray-desktop Qubes frame, to the sides where it's black... and click to see the Figma UI. In the lower-right there will be a white button to "Restart," just click that. :) |
(...just added a super-sweet bit into the Source Widget that can stop the download should a user desire, while also letting them know things are still processing if they go to other Sources). Features Shown (in above prototype)
Prototype may be a touch buggy still, but y'all get it. This is also probably where erik is chuckling and shaking his head. Minimum Usable Product, and Minimum Valuable Product; not just Minimum Viable Product, gang! |
Thanks for preparing! Per chat with @creviera, Gonzalo, Nina and I will discuss a bit more to narrow down the acceptance criteria for the first iteration. Some initial thoughts:
In terms of other features proposed and implied, my initial proposal would be: Must:
Could:
Won't:
But we'll discuss further and then recap here. |
Summary of the MoSCoW exercise with @eloquence and @ninavizz We are working on "Download All" (conversation for the selected Source) because we identified it as a necessary step to implement "Export All" (messages, replies and files for the selected Source). While we could develop it further as a standalone feature, this first iteration aims at enabling the "Export All" feature. Must
Should
Could
Won't
|
Summary of a quick pairing session with @ninavizz today (:pear: :tada:):
Note: The blue outlines are a development artifact. In production they'd be yellow because the |
Problem
In order to download all messages and files for an entire source per #550, all files will need to first be downloaded from the server that have not yet been downloaded to the Workstation. This could be only some of the files for a Source, or all of the files for a Source. Likewise—sources often send multiple files, and users have reported back to the team that going "click, click, click" on multiple files when checking their Drop, can be tedious.
Solution
It would be swell if there could be a top-level menu option w/ an accompanying keyboard shortcut, to enable a user to just download all the new files for a given Source. This will alleviate the need for Yet Another UI control, while also meeting user needs—and surfacing that capability, in the kebab menu for each Source. Likewise, when a user seeks to export all Source material, they won't be forced to exit their task to "click, click, click," then retry.
TBD: Would it be helpful to offer a confirmation alert to let users know once a batch has completed? What would most "batches" look like, size-wise?
Below screen demonstrates the concept in a future-state. It has neither been discussed nor approved.

User Stories
The text was updated successfully, but these errors were encountered: