Timeline for How to consolidate multiple versions of a download page into one?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2019 at 15:10 | vote | accept | Derek Mei | ||
| Jun 7, 2019 at 14:36 | comment | added | Derek Mei | @NicolasHung Great points. The value is being more predictable - for a new user coming to the system, there's currently no indication of which page they will land on when downloading an individual file - either the individual or bulk page. Consolidate the pages to make them look similar is something I've done. The icon is a good idea - we'll try to incorporate that in the list page. Users will want to download one file out of a folder, but there's an individual file view page that tackles some of that functionality, so we don't need to include it here. Thanks! | |
| Jun 7, 2019 at 13:37 | comment | added | Nicolas | What is the value of showing the user which page will load before clicking? IS the value in knowing what download interface will load? Or is the value in knowing whether a listing represents a single file vs multiple? If the the latter, I think introducing a simple icon (e.g. stacked documents) coupled with a description (50 files) would do the trick. Furthermore, I think there are some opportunities to consolidate the download pages so they don't look so different. Lastly, will users want to download 1 file out of a folder with 50 files? | |
| Jun 7, 2019 at 9:56 | answer | added | Ren | timeline score: 2 | |
| Jun 7, 2019 at 1:43 | comment | added | Derek Mei | @NicolasHung - to answer your second question, no. Formats only need to be chosen once and will apply to all files within that folder. In that analogy, the example is that you might want to download a single image in Google Drive in a variety of formats, whereas a folder containing only images might need to be bulk-downloaded (zipped) in several formats. There's a total of perhaps 50 different formats across three different categories. Appreciate the help, by the way! | |
| Jun 7, 2019 at 1:40 | comment | added | Derek Mei | @NicolasHung difference is that some files can be instantly downloaded because they are simple enough and can be asynchronous started by the browser and communicate with the remote server. Other files (folders, according to your analogy), could potentially be hundreds of megabytes large, and need to be zipped because it doesn't make sense for them to be downloaded instantly. Instead, a user can view the progress of those zipped files in a separate section of the app or get an email notification when that download is ready. | |
| Jun 6, 2019 at 22:52 | comment | added | Nicolas | Also, how complex can the files get? Are we talking about a multiple level folder tree structure like Google Drive? If someone wanted to download an entire folder, will they have to determine the formats they want for each of the children files? | |
| Jun 6, 2019 at 22:50 | comment | added | Nicolas | What is the difference between the user (1) selecting checkboxes for JPEG, PNG, PDF and confirming download, vs (2) clicking download JPEG, download PNG, download PDF? Wouldn't the result be the same? (Having each of those files downloaded). | |
| Jun 6, 2019 at 17:58 | comment | added | 習約塔 | "I've abstracted out this use case a bit..." – Your approach is either unnecessarily complicated or the use cases are far outside of most people's experiences. Consider uploading real screenshots of your app with sensitive information hidden. | |
| Jun 6, 2019 at 17:51 | comment | added | Derek Mei | @xiota The example I outlined above is oversimplified. What would happen if a single "file" also had many subfiles associated with it? How would you indicate to the user which page they're going to land on just from the table/list screen? | |
| Jun 6, 2019 at 17:50 | comment | added | Derek Mei | @DarrylGodden you bring up a good point. I've abstracted out this use case a bit due to confidentiality issues, but the use case exists for both. Users need the ability to download files in a variety of ways, due to that being our primary reason why people use our application in the first place. | |
| Jun 6, 2019 at 17:49 | comment | added | Derek Mei | @Bowen it's because there are two possible use cases. A user will want to download images individually in different formats, which can performed immediately. The other use case is that they want it in a variety of formats for several files, which could take a while for the system to zip and then allow a user to download the zip file. If we let an individual download 30 files at one time, it might slow down their browser or be too taxing cognitively. | |
| Jun 6, 2019 at 17:05 | comment | added | Bowen | This seems overly complicated. Why do you need a separate flow for a single file vs many? Save the user a click? They'll have to learn two different pages instead of just 1. | |
| Jun 6, 2019 at 16:17 | answer | added | Prestosaurus | timeline score: 0 | |
| Jun 6, 2019 at 15:21 | comment | added | 習約塔 | I don't understand the point of having multiple selection stages. Why not just use the batch interface? The user can download a single file by selecting only one file. The backend can determine without any user intervention whether anything needs to be "zipped". | |
| Jun 6, 2019 at 14:42 | comment | added | DarrylGodden | I can't reiterate enough, "who will use this, why would they use this and how are they going to use this," if you can state your user case then the functionality should flow from it. The above doesn't logically sit in any user case that I can derive from it, the 'statement' appearance of the top screen appears at odds with the PNG and raster formats being offered below. | |
| Jun 6, 2019 at 13:59 | history | asked | Derek Mei | CC BY-SA 4.0 |