388517 - revised download manager UI for Firefox 3

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect, P2)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

New design posted to wiki:
http://wiki.mozilla.org/User:Dmose:Fx-Docs:DownloadManager/User_Interface#Feedback_and_takeaways

Make it so, I'm here for questions as we go, and will be watching dev.apps.firefox for any feedback/concerns.

Comment 1

[Steffen Wilberg]

What's the difference between this bug and bug 377792 (revised downloads manager)?

Comment 2

[Jim Mathies [:jimm]]

In implementing this, can we also include the basic UI elements required for supporting blocked downloads due to parental controls? I put together a small patch that picks this up in the existing manager. (bug 355554) We'll need strings and a download state to support it. 

Also, I've been asked to work up a patch that handles virus scanning of downloads before the user can act on the file (bug 103487). Curious if folks feel I should implement that in the existing manager, or wait for this work to be completed first? 

Comment 3

[Shawn Wilsher :sdwilsh]

Attachment: v0.1

This is a work in progress.  There are some things that this doesn't do:
1) Advanced search.  This requires backend changes as well, so we are going to do this in a followup bug.
2) Pretty search box.  This will also be done in a followup bug (not yet filed).
3) Information popup panel doesn't have clickable links.
4) For completed downloads, we don't say "{size} in {time}".  Followup bug?
5) There is no bar after the category separators.
6) This might not do all the behaviors the spec lists out as well (I haven't tested those well, nor have I done any work so the behaviors should be the same as before).

Comment 4

[Shawn Wilsher :sdwilsh]

Attachment: v1.0

OK, at this point I think any feature that I'm missing from the UI spec should be done in follow-up bugs.  This is getting to big to review, but it gets most of the work done.  Mano, have at it :)

Comment 5

[Shawn Wilsher :sdwilsh]

Attachment: v1.1

OK, this includes a few fixes
1) No more using the skin path of images in the XUL/XML files - set in the the CSS.
2) Removed a bindings file in the skin what wasn't used.
3) Includes a jar.mn change that I forgot to make before the last patch with some removed files.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Not a blocker, since it's not a P1, but [wanted-firefox3] for sure.

Comment 7

[Shawn Wilsher :sdwilsh]

Attachment: v1.2

Addresses some comments online.  I am unable to test if the windows css changes work because I haven't been able to get my windows VM to work all day :(

Comment 8

[Shawn Wilsher :sdwilsh]

Attachment: buttons image for v1.2

Comment 9

[Asaf Romano (gone)]

Attachment: v1.3

* Fixed: the info button was not working for downloads added by the progress listener (missing startTime argument, plus wrong arguments order).
* Fixed: less buggy keypress-handling in the search field (fixed by using type="timed" textbox).
* regression fix: select the first item within the list when opening the DM.
* More efficient style rules.
* use <button type="image"> inside the popup.
* code-style fixes.

Comment 10

[Asaf Romano (gone)]

Attachment: v1.4

* regression fix: update commands when the state of a download is changed, this was used to be done in downloadCompleted.
 * don't call removeChild before moving an item (using insertBefore).

r=mano otherwise :)

Comment 11

[Shawn Wilsher :sdwilsh]

Thanks Mano!

Checking in toolkit/locales/jar.mn;
new revision: 1.38; previous revision: 1.37
Removing toolkit/locales/en-US/chrome/mozapps/downloads/downloadProperties.dtd;
new revision: delete; previous revision: 1.3
Checking in toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd;
new revision: 1.7; previous revision: 1.6
Checking in toolkit/mozapps/jar.mn;
new revision: 1.36; previous revision: 1.35
Checking in toolkit/mozapps/downloads/content/DownloadProgressListener.js;
new revision: 1.17; previous revision: 1.16
Removing toolkit/mozapps/downloads/content/Makefile.in;
new revision: delete; previous revision: 1.3
Checking in toolkit/mozapps/downloads/content/download.xml;
new revision: 1.29; previous revision: 1.28
Removing toolkit/mozapps/downloads/content/downloadProperties.js;
new revision: delete; previous revision: 1.6
Removing toolkit/mozapps/downloads/content/downloadProperties.xul;
new revision: delete; previous revision: 1.6
Checking in toolkit/mozapps/downloads/content/downloads.css;
new revision: 1.9; previous revision: 1.8
Checking in toolkit/mozapps/downloads/content/downloads.js;
new revision: 1.69; previous revision: 1.68
Checking in toolkit/mozapps/downloads/content/downloads.xul;
new revision: 1.24; previous revision: 1.23
Checking in toolkit/themes/pinstripe/mozapps/jar.mn;
new revision: 1.22; previous revision: 1.21
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css;
new revision: 1.14; previous revision: 1.13
Removing toolkit/themes/pinstripe/mozapps/downloads/downloads.xml;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/background-gradient.gif;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/background-stripe.gif;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/download-inprogress.png;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/progress-bar-paused.gif;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/progress-bar.gif;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/pinstripe/mozapps/downloads/progress-remainder.gif;
new revision: delete; previous revision: 1.2
Checking in toolkit/themes/pinstripe/mozapps/downloads/buttons.png;
initial revision: 1.1
Checking in toolkit/themes/winstripe/mozapps/jar.mn;
new revision: 1.19; previous revision: 1.18
Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css;
new revision: 1.15; previous revision: 1.14
Removing toolkit/themes/winstripe/mozapps/downloads/downloads.xml;
new revision: delete; previous revision: 1.3
Checking in toolkit/themes/winstripe/mozapps/downloads/buttons.png;
initial revision: 1.1
Removing toolkit/themes/winstripe/mozapps/downloads/downloadCleanup.png;
new revision: delete; previous revision: 1.4
Removing toolkit/themes/winstripe/mozapps/downloads/downloadCleanupDisabled.png;
new revision: delete; previous revision: 1.3
Removing toolkit/themes/winstripe/mozapps/downloads/downloadOptions.png;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/winstripe/mozapps/downloads/downloadSelected.png;
new revision: delete; previous revision: 1.2
Removing toolkit/themes/winstripe/mozapps/downloads/downloadsBG.png;
new revision: delete; previous revision: 1.3
Removing toolkit/themes/winstripe/mozapps/downloads/viewFader.png;
new revision: delete; previous revision: 1.2

Comment 13

[Alfred Kayser]

Looks good, but I am not so sure about the 'Active' and 'Completed' headers though. 
The other download managers don't seem to have these 'subgroups' in the list of items. Better would be do something like the error console tabs/mode buttons: 'All' 'Active' 'Complete' 'Failed?'). 

Comment 14

[pd]

With respect to those who worked **** this, the implementation is so poor I'm surprised it's been approved.

Am I jumping the gun? Is this the final version?

Issues include:

1) Complete lack of labelling and/or buttons for the search facility means accessibility is ridiculous. 

2) The continued absence of a delete from hard drive option

3) After filtering/searching/grepping/find as you typing (whatever that little box is supposed to do, which isn't clear) the system icons revent to default on my test box - Windows XP SP2 with all updates.

4) The complete/search results headers are done in completely different UI to any other Firefox element. When will everyone learn to create consistent UI? The very same day I notice the Page Info finally has inherited Ben Goodger's Mac-lover icons as tabs approach, and a Plugins UI can be successfully built to match this approach, this new download manager ignores it!

Why not UI that matches the rest of the program, like this:

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Downloads                                                           |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|       **       **       **                      ______________      |
|    Programs  Photos  Documents          Search |______________| |*| |
|                                                                     |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      File | Size | Progress                    | Options            |
|~~~~~~~~~~~|~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~|
| **        |      |                             |                    |
| **        |      |                             |                    |
|___________|______|_____________________________|____________________|
|           |      |                             |                    |
| **        |      |                             |                    |
| **        |      |                             |                    |
|           |      |                             |                    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Where asterix indicate icons.

This design continues the icons as tabs approach and applies the same consistent placement and meaning to the search function as the main browser window.

Further it allows one of the most under-rated useful UI elements, good old sortable columns. Combine sortable column results with searching and finally the download manager becomes a real archive of downloads where users can easily find that application/photo/document they downloaded a week ago but cant be bothered scouring the hard drive to find.

Comment 15

[Shawn Wilsher :sdwilsh]

This bug isn't the place for discussing the UI.  There have been discussions in the newsgroups (mozilla.dev.apps.firefox) for over a month now.  Please take your concerns there.

Comment 16

[mcdavis941 (sporadically reading bugmail)]

Just finished checking out the new DM from the 2007081305 nightly.  Well done -- this has really come a long way.  I have a question about the use of disabled="true" on the mini-buttons.  As far as I can tell, you're setting disabled on these buttons in the following cases.

- active item's pause and cancel buttons when item not selected
- paused item's resume and cancel buttons when item not selected
- done item's open button when item not selected (but not its info button)

Maybe this was discussed in some other DM bug, but is that really what you want?  The buttons aren't actually disabled (you can click them, and they work).  

Also, if you don't put disabled on them, then you no longer trigger this rule

http://mxr.mozilla.org/mozilla/source/toolkit/themes/winstripe/global/button.css#125

 125 button[disabled="true"] > .button-box {
 126   padding-top: 1px !important;
 127   padding-bottom: 2px !important;
 128   -moz-padding-start: 3px !important;
 129   -moz-padding-end: 4px !important;
 130 }

which means (I think) you no longer need to use !important on this mini-button rule

http://mxr.mozilla.org/mozilla/source/toolkit/themes/winstripe/mozapps/downloads/downloads.css#50

  49 .mini-button > .button-box {
  50   padding: 0 !important;
  51 }
  52 

which is a win IMHO.

Again, sorry if I missed discussion elsewhere.

Comment 17

[Alfred Kayser]

Please take all UI discussions, feature requests, etc so bug 372972.
And if you think that a specific issue needs fixing make a bug for it and link it to bug 372972.
For example the 'disabled state of mini-buttons' is registred as bug 392293.

Comment 18

[mcdavis941 (sporadically reading bugmail)]

(In reply to comment #17)
> Please take all UI discussions, feature requests, etc so bug 372972.

Thanks Alfred.

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

I have a good start on the Litmus testcases, and have been flagging changes that need new/modified testcases, so I feel I've got this covered.

in-litmus+ (work is ongoing).

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

Also, bug 397655 is tracking the more-recent iteration; verified.