| Page Properties | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- In the Synapse web client, Alice navigates to her download list (either via her profile page or via the notifications in the header)
- Alice uses the available columns to sort the items in her list, and can "uncheck" items that she wants to omit from her package, or delete items from the list entirely.
- Alice then proceeds to create and download her package.
Use Case 5: Exporting the Download List for Programmatic Usage
Alice realizes that she doesn't want to download through the web after all, but would rather wait until she gets back to her office to download using one of the programmatic clients (let's pretend that in between the background and use case #5 Alice has learned how to do this).
Workflow
- From Alice's download list, she choses the "Export List" option from the menu.
- Alice downloads a file-manifest-type-thing instead of the individual files and uses this list to download files another way.
Use Case 6: Download History
Alice accidentally wiped her local storage and wants to re-download the data from Use Case B.
...
- In the Synapse web client, Alice navigates to her download list and clicks on "Download History".
- Alice remembers that it was the most recent package that she needs and sorts the history back package date.
- Alice clicks on "Download Package" to get the same .zip package again.
Limitations and Errors
In order to deliver a maximally functional initial feature, we need to set some limits to ensure the feature will be performant and users will understand the expected behavior.
- Total Limit of total number of files in a single download package: up to 100
- Total Limit of total package size: TBD
- Access Restrictions - how to handle?
- Too many files in the list - how to handle?
- Successful download - clear the list and/or retain the list elsewhere?
Priorities
P0: For initial release, it is critical that we support #1a, #2a, #2b, #3, and #4 above. It is acceptable to phase in these features as the team deems best, over a relatively short period of time.
P1: I expect that users will ask for #5 in short order and it's a way to bridge the gap between web users and programmatic users, as well as set us up for #6, so it's a medium priority but may save us time downstream if we do it up front.
P2: Use Cases #1b and #5 #6 do not yet have a clear user need, so we will de-prioritize them until we have more data.
...
https://www.figma.com/proto/cjRT94oMAbvuSC8nwwoddDEk/multi-file-download
Open Questions
| Question | Outcome |
|---|---|
| Should we support the case where a user starts their download list in one session and then resumes and completes the download in in another? | No documented user need for this (yet) but we imagine it might become a case. |
| What is a sensible limit on the number of files and/or the total package size? | 100 files for initial release; need to determine sensible max package size. |
| Should we describe failure cases separately or incorporate those into each use case above? | TBD. For example, user attempts to add a folder to the download list but folder contains too many items. What is the expected interaction there? |
Not Doing (Out of Scope)
- Bulk download of fileHandles within Tables, a.k.a. the mobile BRIDGE data use case.
- Bulk download of submissions from evaluation queues, a.k.a. the challenge use case.
...