Closed Bug 397655 Opened 18 years ago Closed 17 years ago

Download Manager design revision

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: madhava, Unassigned)

References

Details

(Whiteboard: [SEE COMMENT 1 BEFORE POSTING ANYTHING])

Attachments

(2 files, 2 obsolete files)

Not according to Oxford, reed
105.76 KB, image/png
Details
Revision 3 of the download manager design
120.20 KB, image/png
Details
There were a few issues raised with the last version of the download manager redesign that needed to be addressed, and the UX team has also identified some further areas to clean up. I've attached a revised mockup. The most prominent issues requiring revisions were: - buttons on the right side of each download-row were possibly too small, but also a little cryptic and out of the way for what was being offered as the primary interaction method for the row - clear had been button removed when it's actually useful for some users - the information provided through the "information" pop-up was not as easy to access as it could have been and also not easy enough to act on - the "Active" and "Completed" headers were not necessary given that anything with a progress bar was active, and anything without was not (and therefore either complete or cancelled) - the lack of background banding (on mac) or increased visual grouping (on windows) was making it hard to distinguish between successive rows download rows Additionally, we wanted to add or refine some functionality: - the ability to move quickly to the downloads view of the new Place Organizer (accomplished through the "View History" button) to take advantage of its more sophisticated searching capabilities - the ability to see a specific download in the Places Organzier, again to take advantage of the ability to show more detail there - reinforce double-clicking of a row as the primary interaction method (ie. double-clicking opens a completed download, retries a cancelled one, etc.) - adding the topleveldomain.com of the source for each download to the main view given that it can be useful in correctly identifying a download (if everything is called document1.pdf, for example) As well as doing a bit of visual cleanup to reduce complexity and make important information prominent and secondary information less prominent. The most contentious change, I suspect, will be the removal of the search field -- the rationale here is that we'd show just the current session's downloads in the download manager, and searching within that smaller list is possibly required less. For real searching, then, the user is encouraged to go to the downloads view of the places organizer where search is better supported, we have more room to show more detail, and downloads further back than the current session are listed.
Just as a note, please keep comments in this bug limited to the implementation of the design revision being proposed, and questions of clarification. Requests for new features/functionality should be filed in other bugs (though feel free to reference them here!).
Whiteboard: [wanted-firefox3]
Nice mock-up. I take it the re-added Clear List button now only clears the recent items? It's different from what this button did in the old download manager, but would satisfy my use case, which is to reduce the clutter in the DM after saving multiple pages (e.g. multiple patches to check in). Do the cleared items remain in the full history in the Places organizer? Speaking of saving pages, you're aware that saving pages/images adds an entry to the DM list, right? So people who use Save Page/Image actively will still end up with lots of items in the DM window, even if it displays just the items from the current session only.
Whiteboard: [wanted-firefox3] → [SEE COMMENT 1 BEFORE POSTING ANYTHING][wanted-firefox3]
Is there any difference between the "Clear List" button and "Remove All From List" in the context menu? If not, I'd argue to remove the entry from the context menu, or at least to use the same text.
Nickolay: The "Clear List" button would clear out everything currently in the DM, which is only what's been downloaded in the current session. As you say, the intended use case is that of the person who wants an empty download manager. Items cleared here would persist in the full history listing, where they'd remain until the user clears history manually or the max time elapses. As for saving pages/images -- it's true that this list could get quite long, but I think the "this session" vs. "everything older" dividing line is one that makes sense. mmc: Good catch. They do the same thing, so they should have the same label.
Thread on dev.apps.firefox talking about some alternative designs that some people might find interesting: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/d86852c9999fff73/002e23864dcc71ff#002e23864dcc71ff
(In reply to comment #0) > - adding the topleveldomain.com of the source for each download to the main > view given that it can be useful in correctly identifying a download (if > everything is called document1.pdf, for example) This is kinda neat -- I'm assuming ETLD+1 or the whole domain? Also, do we want the time for successfully completed downloads? (see attachment 281484 [details]) (In reply to comment #4) > but I think the "this session" vs. "everything older" dividing line is one that > makes sense. For comparison, currently DM shows the last 7 days of downloads. If downloads are only shown for the current session, would restarting firefox for an update be a time to reset? And of course, this only applies to "Completed" downloads (so paused/resumable ones will still show up). sdwilsh: We could just keep track of the "last time" (e.g., session start time) and query for downloads newer, so this would also work for clearing the list -- we just update the "last time" to "now".
The problem is how to get the session start time? There isn't really an elegant solution that I've come up with yet - everything seems like a hack...
Depends on: 223895
madhava: The mockups only have examples of "Less than a minute". What should other times be like? Bug 394516 will make it display.. seconds: text shown... 0-3.5: "A few seconds left" 3.5-60.1: "X seconds left" where X is an integer 60.1-3600.5: "X minutes left" where X is a decimal with 1 sig fig and so on for "hours" and "days".
Depends on: 394516
Blocks: 392097
"Cancelled" is a spelling error. The correct spelling is "canceled."
(In reply to comment #9) > "Cancelled" is a spelling error. The correct spelling is "canceled." Just to be pedantically clear: either is correct.
(In reply to comment #6) > For comparison, currently DM shows the last 7 days of downloads. If downloads > are only shown for the current session, would restarting firefox for an update > be a time to reset? And of course, this only applies to "Completed" downloads > (so paused/resumable ones will still show up). In my little ideal world, session restore would also restore the list of downloads, so if the only reason to have restarted was an update or crash, you wouldn't lose your download trail.
(In reply to comment #6) > (In reply to comment #0) > > - adding the topleveldomain.com of the source for each download to the main > > view given that it can be useful in correctly identifying a download (if > > everything is called document1.pdf, for example) > This is kinda neat -- I'm assuming ETLD+1 or the whole domain? Also, do we want re: ETLD+1 -- I think that makes sense rather than the (possibly quite long) whole domain. The point is not to see exactly where the file was located so much as which "site" it was from. > the time for successfully completed downloads? (see attachment 281484 [details]) if you mean the time at which the download was completed -- yes. If you mean the duration of the download process, then no. I can't think of a use case for that information. People may look for download based on when they remember getting it (even if it's only as granular as by today vs. yesterday), but I doubt they'd do so based on how long it took to download.
This is a slight revision to the mockup in response to comments regarding: - the title of the window should reflect what's going on (in a bug comment) - drag and drop support (from dev.apps.firefox) - button- and context menu-text for clearing the list should be the same (d.a.f)
I currently have rudimentary drag and drop support in my Download Statusbar extension on Windows and I think it would be a great thing to have in general. However, it doesn't work very well right now because (to my knowledge) core drag and drop stuff doesn't support proper drag and drop of files. (at least on windows, untested on other platforms) The hack I am using is with the "file-promise-url" flavor - similar to the way images can be dragged from a webpage to the filesystem. The problem with this is it has the nasty habit of removing the original file whether or not the drop happened on a valid target. There is a bug open on proper drag and drop support: bug 338478
About Go to/Copy Source Location menu items. I take it the former goes to the referrer URL, while the later copies the URL of the file being downloaded? If so, it might be a little confusing to have both URLs referred to as "Source Location". Also, does this mock-up represent the final decision on the issue in bug 394571?
Can you add options to context menus for simply installing extensions/themes (if extension are xpi or jar)? It will be cool after download extension installing it in two clicks.
Attachment #282413 - Attachment is obsolete: true
(In reply to comment #13) > re: ETLD+1 We'll need bug 368989. (This is of the referrer or the download? And will users get confused if they download Firefox and see some strange mirror site?) > People may look for download based on when they remember > getting it (even if it's only as granular as by today vs. yesterday) Is the display supposed to update as we hit the new day or just when the download manager is opened? Would it be better to have "Yesterday 8pm" or "6 hours ago"? If we go with "Today" "Yesterday" "3:14pm" etc, are there functions available for getting the right strings for localization? sdwilsh: Seems like if dlmgr allows for cherry picking certain downloads to remove, we can't just base a query on time. We'll need to flag downloads as cleared in the DB. Also, "show downloads from current session" is basically "clear downloads on session quit".
Depends on: 368989
Depends on: 398619
How would users actually delete items from the download history? Through places and "clear private data"?
Depends on: 399781
Depends on: 399783
Depends on: 289541
madhava: Does this design revision include what to ask the user when quitting with active downloads? Once bug 399816 lands, firefox will pause downloads instead of canceling them, so the dialog asking about cancel will be wrong. Additionally bug 288281 comment #3 has a suggestion for a revised dialog.
Depends on: 330139
Depends on: 391863
Depends on: 400495
Depends on: 400550
No longer blocks: 392097
Depends on: 400617
Sorta related, sorta not. XUL now has multiple selection in richlist boxes (bug 298371). Can that be implemented here? I can see a use for selecting 3 or 4 things in the DM and just clearing them.
Flags: wanted-firefox3+
Whiteboard: [SEE COMMENT 1 BEFORE POSTING ANYTHING][wanted-firefox3] → [SEE COMMENT 1 BEFORE POSTING ANYTHING]
Depends on: 401215
(In reply to comment #21) > Sorta related, sorta not. XUL now has multiple selection in richlist boxes (bug > 298371). Can that be implemented here? I can see a use for selecting 3 or 4 > things in the DM and just clearing them. I'm inclined to let an add-on do that - maybe look into it for Firefox Next. (I may even be inclined to make said add-on to see how many people are interested in it)
Depends on: 403602
Depends on: 403674
(see attachment: Revision 3 of the download manager design) This revision makes some useful and minor changes (rationale included!): - removes the redundant word "Download" from the entries for Pause, Cancel, and Resume in the top two displayed right-click menus - pulls out the UI that depends on downloads being visible in the Places Organizer, given that that functionality may not land for fx3. This includes (a) removal of the blue "(i)" buttons from completed downloads (these were to have linked to the relevant download's entry in the download history (b) removal of the "View History" button for the same reason - includes functionality that we were previously leaving to the Places Organizer: the "Search Downloads" field (which is in the current build already, incidentally) with some additional visual treatment (label and magnifying glass). The rationale is that users need to be able to do this searching _somewhere_, and they will not be able to do so in the Places Organizer. This search should be extended to also return downloads where the search term matches against a download's listed TLD. - adds a retry icon-button to cancelled downloads, given that it's a useful cue and there's now room for it One design detail that is not visible from the mockup is that, given that the DM is again the only place to view download history, we should list all the download as far back as we have history -- ie., no cut-off at the beginning of the session or 7 days
Attachment #283251 - Attachment is obsolete: true
(In reply to comment #23) > (a) removal of the blue "(i)" buttons from completed downloads (these were to > have linked to the relevant download's entry in the download history I disagree with this. Without the (i) button, there's no way to easily display the source and destination information. If I want to see the source location, I have to right click, select "Copy Source Location", and paste that somewhere else? That's silly. The dlmgr should be able to display that information to me in a visual fashion. The same goes for the destination location.
(In reply to comment #24) The two user-tasks associated with seeing the source information are (a) going there and (b) using some part of that information to tell you what the download is. In the first case, we've supported that by making "Go to Source Location" (and copy for good measure) available in the right-click menu, which is a shorter path than viewing, copying, opening a tab, and pasting. In the latter (b), we made this simpler by listing the TLD inline with each download. As for the destination, the tasks are (a) getting to the download to launch it, and (b) to see where you put it. Double-clicking the row (or, for discoverability, right-clicking) launches the download, so that's (a) covered. As for (b), "Open Containing Folder"/"Show in Finder" is in the right-click menu. In other words, we've supported the user tasks (in fact, made them quicker!) while streamlining the UI. > (In reply to comment #23) > > (a) removal of the blue "(i)" buttons from completed downloads (these were to > > have linked to the relevant download's entry in the download history > > I disagree with this. Without the (i) button, there's no way to easily display > the source and destination information. If I want to see the source location, I > have to right click, select "Copy Source Location", and paste that somewhere > else? That's silly. The dlmgr should be able to display that information to me > in a visual fashion. The same goes for the destination location. >
(In reply to comment #23) > - removes the redundant word "Download" from the entries for Pause, Cancel, and > Resume in the top two displayed right-click menus What about the "Retry Download" context menu entry in canceled state? Shouldn't this reverted to display "Retry" only as mconnor mentionend on bug 403602 comment 12?
(In reply to comment #26) > What about the "Retry Download" context menu entry in canceled state? Shouldn't > this reverted to display "Retry" only as mconnor mentionend on bug 403602 > comment 12? Ah, yes -- good catch. That "Download" should come out too.
(In reply to comment #23) > One design detail that is not visible from the mockup is that, given that the > DM is again the only place to view download history, we should list all the > download as far back as we have history -- ie., no cut-off at the beginning of > the session or 7 days Sounds like we're back to where we've been before: a big list of files that the user likely doesn't care about in the context of the current session. Keeping that list short manually and without a Cleanup button is annoying.
Madhava, what about the other states of the download manager? How the context menu in these cases should look like? There is no mockup available: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/content/downloads.js&rev=1.102&mark=518-541&#518
(In reply to comment #29) > Madhava, what about the other states of the download manager? How the context > menu in these cases should look like? There is no mockup available: It looks like the unaccounted-for ones are: Failed Queued Blocked Scanning The context menu for Failed should be the same as for Cancelled. As for the others -- some questions: Are these all final states (like cancelled or completed) or do they sit around in progress (like something that's downloading)? I ask because it only makes sense to be able to pause or cancel them if they're of the latter case. > > http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/content/downloads.js&rev=1.102&mark=518-541&#518 >
Failed and Blocked are final states. Queued and Scanning are in progress ones. I'm not sure if any actions are actually allowable (other than cancel for queued) on these states however.
>we should list all the download as far back as we have history -- ie., no >cut-off at the beginning of the session or 7 days I don't have real numbers on the types of content that user's download, but let's assume it falls into three categories: 1) Content that the user just needed to look at and then delete (like PDF files, or office documents) it would have been better view this in the content area itself, but it had to be downloaded to view. Installers also fit into this category, run once and delete. 2) Content that the user wants to save on their drive, but they are also embarrassed about (these browsing sessions involve downloading large numbers of images and video), making this category potentially rather large in the download history list. 3) Content that the user download and wants to be able to quickly access again Initially I thought the cleanup button was popular because a lot of users are OCD and simply must have an empty download manager window instead of all the clutter. But thinking about it more, I honestly think most downloads hit category 1 and 2, and I can't think of that many use cases that land in category 3. Also, I personally expect users to go to the location they downloaded the file to open it again, searching the download manager feels counter intuitive because it has traditionally been a transient UI. Do we anticipate that users will open the download manger when they are not downloading anything?
Madhava, will you come up with an updated mockup or should the context menus be implemented as the latest comments state?
(In reply to comment #33) This will be quicker than new mockups -- the remaining menus should be as follows: Failed & Blocked Go to Source Location Copy Source Location ---------- Remove From List Clear List Queued & Scanning Pause (if this is actually possible) Cancel ------- Go to Source Location Copy Source Location > Madhava, will you come up with an updated mockup or should the context menus be > implemented as the latest comments state? >
(In reply to comment #34) > Queued & Scanning > > Pause (if this is actually possible) > Cancel It is not possible, sorry.
Depends on: 405884
Depends on: 405886
Depends on: 405888
Depends on: 405892
Depends on: 405893
Depends on: 406230
Depends on: 392097
Just to clarify, should the menu items dealing with "source" let the user.. 1.1) Copy where the file is being transferred from 1.2) Copy the referrer location 2.1) Go to where the file is being transferred (initiate another download) 2.2) Go to the referrer location If we don't have a referrer, 2.2 falls back to 2.1. What is the user trying to do when they "copy source location"? Do they want to share the download with someone else? If we make it do 1.2 then fall back to 1.1, the user doesn't have a guaranteed way to get to where the file is transfered from. Should it be 1.1 "Copy Location" and 2.2->2.1 "Go to Source Location". Or maybe 1.1 "Copy Location" and 2.2 "Go to Referrer" or "Go to Website" (grayed out if we don't have a referrer)
Alright. This is getting complicated enough that it's feeling like we're trying to do the wrong things. I've gone back to thinking through the user-goals here. Mardak's right -- if people are copying the location, it's probably to get a link directly to the file (unlike when they want to go to the source page, for which there could be other reasons). Here's what I think we should do. The two menu items should be: Go to Download Page Copy Download Link "Go to Download Page" is the equivalent of "Go to Source Location" in that it takes you to the referrer. If we don't have a referrer, we grey out this option. It doesn't change behavior based on what information we have. "Copy Download Link" copies the full URL, including the filename, to the clipboard. The two options can do different things because we're not using the same term "Source Location" (which is kind of uninformative anyway) in both cases. Sorry to have gone back and forth on this -- I think this time it's right.
Depends on: 393190
Just to summarize the things for the context menus.. *Strings* Pause Resume Cancel Open Open Containing Folder | Show in Finder Retry Go to Download Page Copy Download Link Remove From List Clear List *Menu Items* in progress: 1-2 actions followed by a separator, open containing, separator, go to download page, copy download link queued: cancel downloading: pause, cancel paused: resume, cancel scanning: cancel not in progress: 0-2 actions followed by a separator, go to download page, copy download link, separator, remove from list, clear list finished: open, open containing canceled: retry failed: retry blocked: <no action> dirty: <no action>
Update from comments from madhava over IRC.. * default window size should be 485 width by 300 height - show 5.5 downloads by default - golden ratio - wide enough to show long file names - white space to allow scanning of dates * tooltips for date/time - show the full date - probably similar to what was shown in the infobutton popup * tooltips for status - show whatever is shown for in progress downloads - for done (anything showing eTLD+1), tooltip is just the whole hostname
Depends on: 409314
Depends on: 409317
Depends on: 409326
Depends on: 411187
Depends on: 416303
Since this bug discusses the context menu so extensively, I would like to bring forth the following issue (quoted from https://bugzilla.mozilla.org/show_bug.cgi?id=405373#c8) > The current behavior is that the context menu that appears corresponds to the > selected download, even if you right-click on the empty space of the Download > Manager window. This is completely wrong, because clicking on the empty space > should bring up a context menu suitable for the empty space (possibly > containing only generic options such as "Clear List". So, I think we need one more context menu for this case.
Depends on: 419724
Can this be resolved? There are few dependent bugs left, but I think the general redesign has been completed, afaik...?
Is anymore work being done on this before Fx3? As it stands, bits of it are unclear or ambiguous, context menu is sloppy as not all items are context sensitive and it looks highly un-Windows like, it looks like it belongs on a Mac and I'm told it doesn't look too great on that either.
For all intents and purposes, this bug is FIXED. It's lost it's usefulness as a tracking bug regardless.
Status: NEW → RESOLVED
Closed: 17 years ago
No longer depends on: 400495, 405892, 419724
Resolution: --- → FIXED
A little weird to verify a tracking bug, but all dependent bugs are fixed, and Shawn's right that this has lost its usefulness anyway; Verified FIXED.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
Hey, Now that there's a new download manager, I've got a request about design too. As you can see here: http://cl.ly/image/1Z2d32053E3c, the selected item isn't really beautiful. It's a 1px dotted black border (default one). What do you think by changing it in removing border and adding background: linear-gradient like #C8C8BA, #E8E8E8, #C8C8BA ?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: