513691 - Improve redesigned download progress window (and bring back proper buttons)

Status: ASSIGNED

(SeaMonkey :: Download & File Handling, defect)

Description

[Benoît]

The redesigned download progress window that landed after the migration of the download manager back-end to toolkit isn't that good. The problems are as follows:

-Half of the buttons have been replaced by small, iconic buttons that are harder to point at and are pushed far to the right.
-The other half of the buttons has been shoved away behind undiscoverable context menus that are attached to text labels of the source and destination of the download.
-Labels indicating download speed and other data are carelessly stacked on top of each other with no organization, making it less visually pleasing.

Comment 1

[Benoît]

Attachment: brings back half of the buttons

This patch changes the mini buttons Cancel, Pause, Resume and Retry into regular buttons, and places them below the progressmeter as before. It doesn't fix all the issues of this bug, but this is all I can do without needing to change language strings, and it resolves the biggest complaint about the window.

Comment 2

[Robert Kaiser]

I object to this change. I intentionally placed the buttons where they are and the way they look.

Comment 3

[Philip Chee]

It is my subjective opinion that the buttons look better as regular buttons below the progressmeter. In the current implementation the mini buttons look out of place and unconnected to anything else in the UI.

Comment 4

[simon anderson]

Is there not a bug on this already? (bug 497382)

Comment 5

[Benoît]

No. Bug#497382 is about the toolbar buttons on the Download Manager window. This is about the single download progress window design.

Comment 6

[[e-mail]]

Comment on attachment 397634 [details] [diff] [review]
brings back half of the buttons

Sorry, but we can't take this as-is for several reasons:
1. Buttons appear/disappear rather than enabling/disabling
2. No access keys on buttons (and should rename entities)
3. Images on buttons look odd

Comment 7

[Benoît]

Attachment: brings back half of the buttons ver. 2.0

Fixed the issues pointed out by Neil:

-The Pause, Resume and Retry buttons still disappear/reappear, but the Cancel button doesn't (gets disabled instead). This makes the behaviour the same as the old progress dialog.
-Access keys have been defined for the buttons. I should note, though, that the old progress dialog had none.
-Images removed from the buttons.

Comment 8

[[e-mail]]

(In reply to comment #7)
> -Access keys have been defined for the buttons. I should note, though, that the
> old progress dialog had none.
Good point, but thanks for adding them anyway.

> -The Pause, Resume and Retry buttons still disappear/reappear, but the Cancel
> button doesn't (gets disabled instead). This makes the behaviour the same as
> the old progress dialog.
Well, apart from the fact that the old dialog also had Launch and Reveal ;-)

Comment 9

[aditsu]

The "launch file" and "show file location" buttons were VICIOUSLY AMPUTATED from the download window, and I would like to express my STRONGEST disappointment about that.
I also hope mr. Robert Kaiser doesn't have dictator powers over this (see bug 381697 brutally "resolved" as WONTFIX), otherwise I'll have to find another browser or figure out a way to fix this mutilation.
Obviously, I would rate the importance of this as "major" rather than "minor".

Comment 10

[Rufus]

I have to whole-heartedly agree with previous negative commentary about the implementation of dialog buttons in general in the new SM 2.0.  The new (extra) small buttons are not only difficult to target and point to for a laptop user, but also seriously if not totally preclude usage of the dialog functionality for a handicapped or otherwise impaired user.  The callous disregard of user input in regard to the small buttons and  the oversight of provision of access for all users of all equipment types and abilities presented by this seriously flawed and functionally inconsiderate implementation is beyond any level of professional standard for accessibility.  "How it looks" is completely irrelevant if the design is not functional and/or accessible for all users of all equipment and ability.

Comment 11

[Robert Kaiser]

For e.g. blind users, we have better support in there than for sighted users, probably, as screen readers get special hints even for the dropdowns, and we had one of Mozilla's accessibility specialists test this window. Accessibility for that category of people is not an issue, visible design is the only issue we have here. And what we need is good proposals of how to make the design good. We already know it's not ideal, but going back to the even uglier old design is also not an option.

What we need are constructive proposals, people, not "me too" comments for not liking the current design.

Comment 12

[aditsu]

(In reply to comment #11)
The old design is not uglier, it looks standard (unlike the current one) and is 1000 times more functional (well, except that the 2 buttons I mentioned didn't work in Linux). The current design is REALLY NOT ACCEPTABLE, and a *constructive proposal* is to revert to the old design unless/until somebody can find something even better.
I know you're all like "over my dead body", but remember you're not the only person in the universe, and sometimes even emperors can get overthrown.
Anyway, I can try to do some different mockups, but I'm not exactly a designer, so don't expect too much.

And finally, I'd like to just point out to 2 related bugs I found, that cripple the functionality even more: bug 521700 and bug 521366

Comment 13

[aditsu]

Attachment: Download window design

Here are some suggestions along the lines of the current design - with icons instead of text. I used some kde icons.
1 and 2 would show the same icons the whole time, enabling/disabling them as needed, and 3a transforms into 3b when the download finishes.
This is just to give you some ideas, you can modify them in many ways.

Comment 14

[Robert Kaiser]

Adrian, thanks, I like that direction (attaching a single graphic with all in them would be easier to view than a zip though). Could you describe what functions the icons in there should be connected to? The Pause/Stop stuff is pretty clear, the others are less so, esp. the pin.

Comment 15

[aditsu]

The pin is for "Close this window when the download is complete", the gear-play icon is for launching the file, and the folder icon is for opening the location. I guess they're not as intuitive as I thought.

Comment 16

[Benoît]

Robert Kaiser wrote:
>We already know it's not ideal, but going back to the even uglier old
design is also not an option.

Please explain, in detail, why going back to the old design is not an option. "it's ugly" is your own opinion, and a subjective reason that won't do.

Comment 17

[Robert Kaiser]

Adrian, by the way, where did you take the icon graphics from? Are they in some license so they can be used under our MPL/GPL/LGPL tri-license?
I'd like to take a shot at a possible implementation some time, as I still believe it's somewhat my fault that there is some dissatisfaction with the design of the (necessarily) rewritten progress windows, and I want to make sure I have access to suitable icons when working on it.

Comment 18

[Philip Chee]

On Fri, 11 Dec 2009 17:17:11 -0800, Rufus wrote in mozilla.support.seamonkey:

> IMO, the buttons need to be sized so that they appear no smaller than
> 1/2 the width of the former oblong buttons, or of a diameter that is
> equal to the height of the former oblong buttons.
>
> They also need to be placed far enough from the dialog box edge such
> that a user doesn't risk overshooting them while attempting to point
> and/or click with with consideration being given to the variety of user
> available pointing/input devices - including mice, trackballs,
> trackpads, pen tablets, and iso-static devices.
>
> Buttons within ALL dialog boxes and/or other presentations furnished for
> user input/interaction need to be of a size which is both visually and
> tactilely accessible to/for all users of all abilities employing the
> widest variety of equipment.
>
> Thus evaluation of any proposed solution should also be performed at
> varying screen resolutions and on display screens of various sizes, with
> the worst case(s) being the smaller/smallest screens a user may be
> likely to employ.

Comment 19

[aditsu]

Benoît: very good point!
Robert: I mentioned I used some kde icons. They're from the oxygen theme, except the pushpin which is from okular. I'm not sure about the license, but doesn't Mozilla have a set of icons and/or some designers that can create some new ones?

Comment 20

[Robert Kaiser]

The Firefox team sometimes pays people to do some icons - in SeaMonkey, we are fully dependent on volunteers doing work for us or reusing what Firefox or the Mozilla platform have available.
The current small icons come exactly out of that: I needed a solution fast, didn't have the time or resources to do new icons, and those small icons were already available from the Mozilla platforms (and our main download manager window, which needed to have them in the same size as the default fonts in any case).

Comment 21

[Stefan [:stefanh]]

Comment on attachment 403124 [details] [diff] [review]
brings back half of the buttons ver. 2.0

--- a/suite/themes/classic/communicator/downloads/downloadmanager.css
+++ b/suite/themes/classic/communicator/downloads/downloadmanager.css

What ever happens here - suite/themes/classic/mac/communicator/downloads/downloadmanager.css will also need to be taken care of

Comment 22

[Robert Kaiser]

(In reply to comment #19)
> Robert: I mentioned I used some kde icons. They're from the oxygen theme

Oxygen is under CC-by-nc-nd license, which is completely incompatible to us. Even the old default set of KDE, Crystal, is under LGPL, which fails to be compatible with the main one of our three licenses (the MPL).

Yay for licensing hell :(

And Tango icons, which would be PD and therefore easily usable, have a completely different look for those media icons.

I guess we'll have to draw our own icons after all :(

(As a side note, trying to avoid this whole problem is the main reason why in the current window I used the small icons that we already had for download manager.)

Comment 23

[Robert Kaiser]

Attachment: WIP screenshot, proposal 1

OK, I went and drew icons myself in SVG, based on the small icons we already have in the download manager, and added the "open" icon from Composer. I also added a menubutton with the other commands so they're easier to access.

Here's a screenshot of three states of the progress window with my work-in-progress patch. This is a _real_ screenshot, not a mockup, by the way - and I'm open to feedback!

Comment 24

[Benoît]

> Created an attachment (id=423153) [details]
> screenshot of work in progress

Good:
-The buttons are of an acceptable size.

Bad:
-The buttons are still smashed to the right.
-The menubutton is not discoverable enough as it's not tied to anything. It's also not clear what it's used for without opening for the same reason.

Comment 25

[Robert Kaiser]

(In reply to comment #24)
> Bad:
> -The buttons are still smashed to the right.

What other options do you see? I can't see any.

> -The menubutton is not discoverable enough as it's not tied to anything. It's
> also not clear what it's used for without opening for the same reason.

The only other option I see is to completely remove it and leave the other options as undiscoverable as they are right now.

Comment 26

[Benoît]

I would put the buttons on the left, where they always were.

Comment 27

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #25)
> (In reply to comment #24)
> > -The menubutton is not discoverable enough as it's not tied to anything. It's
> > also not clear what it's used for without opening for the same reason.
> 
> The only other option I see is to completely remove it and leave the other
> options as undiscoverable as they are right now.

Be a little more imaginative! ;-) How about putting it to the right of the file name (first row, maybe separated by a spacer)? In your screen shot it looks like it's bound to the icon/button to its left because that's the common notion one has from other interfaces (e.g. back/forward buttons in the browser). Instead it should be bound to the download itself which IMO is best represented by the file name. It might be pushed to the right with long file names but I think we'll have to cope with that.

As for the icons: I think they are nicely done. I cannot see from the screen shot whether they have tooltips (and whatever a11y requires additionally) but I guess they'll have toward the final version. I'm not sure about the Open icon (it doesn't match with the rest color-wise) but it's OK for a WIP. As for the icons position: I'm OK with that (just my 2c).

Comment 28

[Robert Kaiser]

(In reply to comment #27)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > -The menubutton is not discoverable enough as it's not tied to anything. It's
> > > also not clear what it's used for without opening for the same reason.
> > 
> > The only other option I see is to completely remove it and leave the other
> > options as undiscoverable as they are right now.
> 
> Be a little more imaginative! ;-) How about putting it to the right of the file
> name (first row, maybe separated by a spacer)? In your screen shot it looks
> like it's bound to the icon/button to its left because that's the common notion
> one has from other interfaces (e.g. back/forward buttons in the browser).
> Instead it should be bound to the download itself which IMO is best represented
> by the file name. It might be pushed to the right with long file names but I
> think we'll have to cope with that.

But that file name label has already attached the menu anyhow - if so, we'd need to turn both the file name and the domain name into menubuttons with a dropmarker that have their already-attached functions in them.
And if so, people will continue complaining that parts of the actions are in one place, and parts in another.
Also, the proposed open button would need to be removed as it wouldn't fit the place it is in any more.

> As for the icons: I think they are nicely done. I cannot see from the screen
> shot whether they have tooltips (and whatever a11y requires additionally) but I
> guess they'll have toward the final version.

They have tooltips, it's just hard to show them in the screenshot.

> I'm not sure about the Open icon
> (it doesn't match with the rest color-wise) but it's OK for a WIP.

Changing its color is quite hard, as we unfortunately don't have the SVGs for the Composer icons.

Comment 29

[[e-mail]]

Comment on attachment 423153 [details]
WIP screenshot, proposal 1

Well, the icons are a nice size, but I'm not sure about the Launch icon, maybe add it as an option on the dropdown? Also, was there any reason to move them?

Comment 30

[Robert Kaiser]

(In reply to comment #29)
> (From update of attachment 423153 [details])
> Well, the icons are a nice size, but I'm not sure about the Launch icon, maybe
> add it as an option on the dropdown? Also, was there any reason to move them?

The icon you call "Launch" should stay with its name "Open", as I don't launch an Office document or an image, but I open it. ;-)
That said, one of the larger criticisms of the new progress window was that opening the file after successful download was/is so hidden in a (not very accessible) dropdown, and given that after a successful download, all other icons are gone, I figured it would be a good thing to have that one show up, as opening the file is probably the most common action at that time.

The reason to move then is that I felt that at this position there is more space than at the one we have the current small icons in, and that they were placed there in the proposal from Adrian.


Possible scenarios I see for doing things differently:

1) Remove the "More" dropdown arrow button and the "Open" icon, instead make the file and domain names be two menubuttons (looking the same as now but with dropmarkers to the right), so that their actions become more accessible.

2) Only make the domain name such a menubutton, leave the "Open" icon but make it an actual menubutton connected to the dropmarker next to it (i.e. the dropmarker also only appears with that icon) and only attach a menu with "Open" and "Open Containing Folder", as the other actions are on the domain name.

Comment 31

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #30)
> The icon you call "Launch" should stay with its name "Open", as I don't launch
> an Office document or an image, but I open it. ;-)

While I agree with you on that it's only now that I understood that this is what you want the folder icon to do! IMO that's an absolute no-go. The folder icon is commonly associated with Open, yes. But not Open as in "open a file with the corresponding application" (which we are talking about here) but with "open a file in this application". That is a big difference. In this case the latter would imply opening an external file in the download progress window (or SeaMonkey, the host application) which of course makes no sense at all.

I'm pretty sure the above is part of more than one standard and we must not violate this.

Unfortunately I have no better idea for an alternate icon but that is partly because I don't know a single other application that uses an icon for opening a file in an external application. They all use text labels. I think we should do the same, at least for this action (icons for the others are OK). And, again, we should in no event use the folder icon here. If you wanted you could use it for Open Containing Folder but I don't think it deserves an own one.

> Possible scenarios I see for doing things differently:
> 
> 1) Remove the "More" dropdown arrow button and the "Open" icon, instead make
> the file and domain names be two menubuttons (looking the same as now but with
> dropmarkers to the right), so that their actions become more accessible.

1a) Use two menubuttons and replace the Open icon by an Open (text label) button.

> 2) Only make the domain name such a menubutton, leave the "Open" icon but make
> it an actual menubutton connected to the dropmarker next to it (i.e. the
> dropmarker also only appears with that icon) and only attach a menu with "Open"
> and "Open Containing Folder", as the other actions are on the domain name.

That'd be OK with a different icon or text label.

Comment 32

[Robert Kaiser]

(In reply to comment #31)
> 1a) Use two menubuttons and replace the Open icon by an Open (text label)
> button.

I'd rather kill the progress window completely and all the rest of my reputation with it rather than doing that.

Comment 33

[Robert Kaiser]

Attachment: WIP screenshot, proposal 2

Here's a screen shot of what I call "proposal 2", this makes the domain name an actual dropdown menubutton to make it more obvious that it offers stuff to do, and puts the "open" icon into an actual menubutton with the two open options only.

Comment 34

[Robert Kaiser]

Attachment: WIP screenshot, proposal 3

And finally, here's a proposal that doesn't have an "open" button at all but converts both file name and source domain into menubuttons.

I don't like this solution too much, as I think the "open" button is something people very much _want_ on this progress window for finished downloads - I still want to bring it up as a possible thing to do.

If someone can point me to a better icon for "open this file", ideally from our own or some Mozilla icon selection, so that design or at least licensing matches, I'm all for it, but I currently don't have a better idea than to use the "open" button from Composer, which is this folder thing.
If there's just an idea, it already helps. Remember though that it's "open", not "launch".

Comment 35

[Benoît]

I do not appreciate having review requests and my patch removed by someone else than the reviewer, especially if it isn't to immediately replace it with another patch.

As for the two new proposals, they still have their buttons smashed to the right. This won't do.

Comment 36

[Robert Kaiser]

(In reply to comment #35)
> As for the two new proposals, they still have their buttons smashed to the
> right. This won't do.

That's your opinion, and I heard it, but so far you have been the only one with that one. Also, the only useful proposal to make things better, i.e. what Adrian attached, had it right that way. And actually, the right side is IMHO the most easy clickable area of the whole dialog, and an extraordinary good place to put buttons. See what most reasonable desktop systems do nowadays with dialogs...

Comment 37

[[e-mail]]

Comment on attachment 425508 [details]
WIP screenshot, proposal 3

Let's try this version.

Comment 38

[R.N. (Roger) Folsom]

For a newcomer (me) to this conversation about Progress Dialogs, it appears to have become a bit acerbic.
So perhaps a "third party" overview and some suggestions would be useful.

First, let's focus on features, in this case meaning options and their location in the download sequence.

I would like to see a combination of the SeaMonkey 1.1.18 and 2.0.2 Progress Dialogs, plus some suggestions made earlier.

The SeaMonkey 1.1.18 Progress Dialog.
The initial dialog has two options:
Open it with . . .
Save to Disk . . . 
And a checkbox for: Always perform this action when handling files of this type.

After the download destinatiion has been selected, the next dialog has four button options:
Cancel
Pause
Launch file
Show file location
And a checkbox for: "Keep this window open after download is complete."


The SeaMonkey 2.0.2 Progress Dialog.
The initial dialog starts with information:
You have chosen to open: Name of file, which is a xxx type file, from source.
Then after "Would you like to save this file?" there are two button options:
Save File
Cancel

After the download destination has been selected, the next dialog has essentially the same information as the initial dialog, and then has two options:
Pause (a small || icon)
Cancel (a small X icon)
And a checkbox for "Close this window when the download is complete."
If that checkbox is not checked, the Pause and Cancel icons disappear as soon as the download is complete.

----------------

Suggestions:

In the initial 1.1.18 dialog, the "Open it with" strikes me as premature; the file isn't even downloaded yet!  And without "Open it with," the checkbox can be omitted.

Put all of the 2.0.2 information in the initial dialog, so the user has all information (including file size) before deciding whether or not to save the file.
Include two options:
Cancel
Save to Download folder (where "Download" is whatever folder the user selected in Edit, Preferences, Browser, Downloads, "[Default] Save files to").
But that destination should be a field in which the user can temporarily override the Default by typing or browsing to a different location.

[My reasoning here is that where I want to put the file depends on what it is.  If it's a program installation file, e.g. SeaMonkey Setup 2.0.2.exe, I may want to put it in a folder that is a collection of installation files.  If it's a pdf file that I want to look at first before deciding to keep it, then I may want to put it temporarily in the default Download folder.
With that arrangement, Edit, Preferences, Browser, Downloads, wouldn't need a "Always ask me where to save files" because the user always would have that option in the initial Progress Dialog.]

In the next dialog, don't bother putting the same information now in the initial dialog into the next dialog;  save room for the following options:
Cancel
Pause 
Launch file [or Open] (At least in Windows, I don't think an "Open it with" field is necessary, because the file's extension tells Windows how to Launch or open the file.) 
Show file location
Retry

Except for Pause, all of these should remain "live" even after the file is fully downloaded.  For example, after a completed download, Cancel could delete the downloaded file if the user decides (albeit belatedly) that he made some mistake and downloaded the wrong file.

In the past, depending on the file I have been downloading or have downloaded, I have used all of these options.  All of them are useful and needed.


Details:
Personally, I want to minimize clicks, and consequently rather than drop down menus I much prefer labeled buttons.  That way I see all of my choices at once, as soon as tne dialog box opens.  I don't care if the dialog box is large, because during downloads I'm focused on it anyway.

My second choice is icons, with tooltips that stay in place until the cursor is moved.

To me, "ugly" is not a problem.  Efficiency of use is much more important than pretty artistry.

[Incidentally, no matter what the Progress Dialog layout, the box needs to be large enough to display all of its components, even on a 15" UXGA laptop screen, where for readability the operating system --- Win2kSp4 in my case (at Display Properties, Settings, Advanced) --- system default font is set to 144dpi = 150% of the standard 96dpi, or higher.
In SeaMonkey 2.0.2, that wasn't true for Edit, Mail & Newsgroups Account Settings, Server Settings, until userChrome.css mandated all default font sizes to be 9 pt.  On MozillaZine, see the third paragraph in http://forums.mozillazine.org/viewtopic.php?f=40&t=1736315.]

Comment 39

[R.N. (Roger) Folsom]

RNF P.S.
At the end of my summary of the SeaMonkey 2.0.2 Progress Dialog, I wrote:
"And a checkbox for "Close this window when the download is complete."
If that checkbox is not checked, the Pause and Cancel icons disappear as soon
as the download is complete."
The "not" in statement is an error and should be omitted.

Comment 40

[aditsu]

Wow, lots of comments. I've been very busy so had no time to respond, I'll try to do that now.

First, I am baffled by Robert's stubborn insistence that all text buttons should be killed. There is no logical reason for that, and it is the single greatest cause of this bug and of the failure to solve it quickly. In his own words: "That's your opinion, and I heard it, but so far you have been the only one with that one." And, ironically, he has no problem with a super-extremely-long text checkbox.

Anyway, he also had some proposals:
1) The folder icon is not appropriate (as Jens explained), and the drop-down menu is really weird
2) I like the first drop-down menu, not the folder icon, and I think "open containing folder" needs its own button
3) The drop-down menu for open actions is no good, because these actions are really important, so they deserve buttons.

About the "open" icon, I showed what kde has (a play button inside a gear), maybe we can draw one inspired from it or find something on openclipart.org or some other place. But using text instead is perfectly fine.

About button locations (left or right) I am rather neutral, maybe a UI/usability expert should comment on that.

About Roger's comments:
- "In the initial 1.1.18 dialog, the "Open it with" strikes me as premature; the
file isn't even downloaded yet!" - I disagree, and I'd like to have that option. The reasoning is that I can decide what to do with the file when I start downloading (which may take a long time), and if I just want to open/run it, it can be saved in a temporary location.
- "that destination should be a field in which the user can temporarily
override the Default" - good idea
- "At least in Windows, I don't think an "Open it with" field is necessary" - I think it's still useful, but perhaps only in the first dialog, not the download progress. It can have "default application" as the first option (or ideally the default application's name), and then any other associated applications (preferably defined in the desktop environment, not in SM itself). The progress dialog should have "open with default application", and that should be made to work ON ALL PLATFORMS! Use xdg-open in Linux.
- "To me, "ugly" is not a problem.  Efficiency of use is much more important than pretty artistry." - very good point

Finally, about the "close when complete" checkbox, I think it should be in the first dialog that asks what to do; in the progress dialog you may not have time to change it.

Comment 42

[Robert Kaiser]

Attachment: patch to implement proposal 3

So, here's the patch to implement proposal 3.

I think this is a definite step forward, if we have more issues, we should file those in followup bugs.

Comment 43

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #34)
> If someone can point me to a better icon for "open this file", ideally from our
> own or some Mozilla icon selection, so that design or at least licensing
> matches, I'm all for it, but I currently don't have a better idea than to use
> the "open" button from Composer, which is this folder thing.
> If there's just an idea, it already helps. Remember though that it's "open",
> not "launch".

Alternate approach: once the download has finished, display the icon the OS provides for the given file type (e.g. in 32x32 at the far right of the dialog, aligning its top with the file name button's top) and allow to double click it (and make it focusable so that Enter can be used). Just a thought.

Comment 44

[Robert Kaiser]

(In reply to comment #43)
> Alternate approach: once the download has finished, display the icon the OS
> provides for the given file type (e.g. in 32x32 at the far right of the dialog,
> aligning its top with the file name button's top) and allow to double click it
> (and make it focusable so that Enter can be used). Just a thought.

Interesting idea if it's doable. Can we investigate this in a followup?

Comment 45

[aditsu]

Robert, it sounds like you want to close this issue by implementing proposal 3. However, I don't see any agreement on the following 2 points:

1. Proposal 3 is the best choice for this issue
2. Proposal 3 is enough to solve this issue

I personally disagree with both.

Comment 46

[Robert Kaiser]

(In reply to comment #45)
> Robert, it sounds like you want to close this issue by implementing proposal 3.

I do, because that's what our SeaMonkey UI owner, Neil, has agreed with, and I personally do react well to constructive proposals but not to being flamed. I tend to ignore those people who have nothing but flames.

Now, you obviously were constructive, and your original proposal in the attached .zip was the base for my suggestions.

So, for your points:
Is this the best choice? Among the current proposals, it seems the one that does spawn the least bad comments.
Is it enough? I don't think it is enough to fix everything, but it's a clear step forward. And one bug should solve one step. Further improvements should probably be made, but they should be put in followup bugs - one bug per issue.

Comment 47

[aditsu]

In my opinion a better solution is to modify proposal 3 by removing the first drop-down menu and instead have 2 text buttons for "Open" and "Open Containing Folder". The actions are too important not to have buttons.
From what I've seen, the majority of people who commented would like to have text buttons if icons are hard to come up with, and you're the only one who opposed that.
Of course, it doesn't solve *everything*, but I think my suggestion is enough to solve this UI issue. In particular, it doesn't make the "Open" action work, but I already submitted another bug for that.

Comment 48

[Robert Kaiser]

Sorry, I will not go and do an ugly mixture of text and icon buttons. This window is too heavy on text and too light on graphical elements already.

I'm all for an iconic "open", but let's move that to a followup and implement the items that are non-controversial right now.

If the discussion doesn't stop here, you likely will get no improvement of the window at all for 2.1, and I'm sure that's not what you or anyone else wants here.

Comment 49

[aditsu]

Oh well, if you threaten to block the progress and nobody can make you change your mind, then I'm willing to accept proposal 3 for now. At least it's a little bit better than before.
I wonder if anybody else wants to comment before going ahead with this.

Comment 50

[[e-mail]]

Comment on attachment 425640 [details] [diff] [review]
patch to implement proposal 3

>+  <label id="dlStatus" flex="1" value=""/>
Nit: I think this flex was historical from way back when the buttons were aligned with just this label; we don't need it now.

>     <vbox flex="1">
>+    <checkbox id="closeWhenDone"
>+              label="&closeWhenDone.label;"
>+              accesskey="&closeWhenDone.accesskey;"/>
>     </vbox>
This vbox is wrong. Just put the flex on the checkbox. Or did you mean this to be a nested hbox?

>new file mode 100644
Nit: missing Modern version.

>+#cmdBox {
>+  margin-top: .25em;
>+}
Or rather than the dialog and cmdBox margin, you could give the imagebuttons a margin instead.

>+#pauseButton {
>+  /* pause */
These comments were useful in the pre-progressdialog version (and in fact in the earlier tree rules above) to identify what the various treechildren styles actually meant. But it's blindingly obvious what this rule is for.

>+  list-style-image: url("chrome://communicator/skin/downloads/downloadButtons-large.png");
Maybe we could put this image on the class rule instead? (And these specific rules belong after the class rule.)

>+/* label with dropdown, actually done as a button type=menu */
> #fileName, #fileSource {
>+  -moz-appearance: none;
>+  background-color: transparent;
>+  border: none;
>+  padding: 0;
>+  margin: 0;
>+  min-width: 0;
>+  min-height: 0;
>+  /* make text start match normal labels */
>+  -moz-margin-start: 3px;
class="plain" might help to reduce the number of rules here.

> #dlProgressWindow {
>   padding: 14px;
This (Mac) matches dialog.css, so maybe the other versions should too ;-)

>+#dlProgressWindow {
>+  padding: 14px;
>+}
In particular 14px padding is very wrong in Modern.

>+  -moz-appearance: none;
Nit: shouldn't need this in Modern.

>-  -moz-appearance: none;
Bah, how did that get there?

Comment 51

[Benoît]

> I do, because that's what our SeaMonkey UI owner, Neil, has agreed with, and I
personally do react well to constructive proposals but not to being flamed. I
tend to ignore those people who have nothing but flames.

The problem with this is that you define constructive proposals as "proposals that suit my vision of the dialog".

> Sorry, I will not go and do an ugly mixture of text and icon buttons. This
window is too heavy on text and too light on graphical elements already.

Then don't, and let someone else handle it. I already had a patch up.

Comment 52

[Robert Kaiser]

(In reply to comment #51)
> The problem with this is that you define constructive proposals as "proposals
> that suit my vision of the dialog".

Possibly. In any case, I could come up with a proposal that has ui-r+ - your patch didn't get reviews or even a ui-r+ from the user interface module owner of SeaMonkey (Neil).

There are things you can do better, here's something I seem to be able to do. I'm looking forward to seeing your user-agent spoofer add-on (not to be discussed here).

Comment 53

[Robert Kaiser]

(In reply to comment #50)
> >+#cmdBox {
> >+  margin-top: .25em;
> >+}
> Or rather than the dialog and cmdBox margin, you could give the imagebuttons a
> margin instead.

Hmm, that will make the checkbox not middle-aligned with the button icons, is that what you want?

> >+/* label with dropdown, actually done as a button type=menu */
> > #fileName, #fileSource {
> >+  -moz-appearance: none;
> >+  background-color: transparent;
> >+  border: none;
> >+  padding: 0;
> >+  margin: 0;
> >+  min-width: 0;
> >+  min-height: 0;
> >+  /* make text start match normal labels */
> >+  -moz-margin-start: 3px;
> class="plain" might help to reduce the number of rules here.

Yes, but unfortunately it makes us lose the focus ring on those menu buttons, at least in the default theme...

> > #dlProgressWindow {
> >   padding: 14px;
> This (Mac) matches dialog.css, so maybe the other versions should too ;-)

Hmm, that makes us actually increase the padding on the default theme...

Comment 54

[R.N. (Roger) Folsom]

Reply to Adrian Sandor's Comment 40 on my Comment 38:
I am delighted that you find some of my suggestions useful, and I agree with
all of your improvements to my suggestions.

I do not understand Robert Kaiser's fondness for icons instead of text buttons.  In comment 48, he wrote:
"Sorry, I will not go and do an ugly mixture of text and icon buttons. This
window is too heavy on text and too light on graphical elements already."

But other than guessing that he thinks text is ugly while icons are attractive,
I haven't a clue about what determines his "too heavy" and "too light"
opinions.

After reading everything before and after my Comment 38, I still think that
"ugly" is not a problem.  Efficiency of use is much more important than
pretty artistry.

As someone pointed out (probably in Infoworld) many years ago (I think it was roughly when the first Windows version came out), the replacement of Egyptian icons by alphabetical writing was an improvement, not a retrogression, in the IT of that day.

That said, icons CAN be useful space-savers, especially when their meaning is
very easily remembered from very frequent use.  But I don't see space as a
truly binding constraint here.  What's wrong with a SeaMonkey1 size progress
dialog box, or even one a bit larger?

Roger Folsom

Comment 55

[Robert Kaiser]

Attachment: patch v2 for proposal 3 implementation

OK, Neil, I followed all your advice, I even found out what I made wrong wrt to the plain button stuff and could do that, but I did make an exception for the cmdBox top border as I find that it looks best when the checkbox is in the vertical middle of the space below the progress bar, as well as the icons, and so I made the top border of that box match the window's bottom padding everywhere.

The window padding now fits dialog.css everywhere, and I even could get focus border on Modern for all the buttons - taking into account that all our icon button are circle shapes right now.

Comment 56

[Justin Wood (:Callek)]

(In reply to comment #49)
> Oh well, if you threaten to block the progress and nobody can make you change
> your mind, then I'm willing to accept proposal 3 for now. At least it's a
> little bit better than before.
> I wonder if anybody else wants to comment before going ahead with this.

The problem isn't a block of progress; its a matter of "avoiding stop-energy". We have a proposal that HAS gotten the go-ahead from the SeaMonkey UI owner. Robert is willing to improve the dialoge. We will go with what has been approved.

Further improvements to build apon this is great, and appreciated; but they need to be approved by neil; and to avoid extra work that doesn't lead anywhere, its probably best to do it in mockups and get his opinion on it; in another bug.

However I don't see Robert volunteering (yet) to do more work beyond this; so anyone who proposes something in a new bug has to also be willing to spearhead that work.

Robert; THANK YOU; for making the progress dialoges BETTER [maybe not great; but definitely better]

Comment 57

[Philip Chee]

> so
> anyone who proposes something in a new bug has to also be willing to spearhead
> that work.

The problem is that nobody is going to volunteer if anything they do no matter how good, is going to be vetoed by Robert because he doesn't like it.

Comment 58

[Justin Wood (:Callek)]

(In reply to comment #57)
> > so
> > anyone who proposes something in a new bug has to also be willing to spearhead
> > that work.
> 
> The problem is that nobody is going to volunteer if anything they do no matter
> how good, is going to be vetoed by Robert because he doesn't like it.

And I thought me and Robert made ourselves clear that its not up to either of us, but Neil on this.  The project is also not a democracy. and concrete proposals are always a good starting point for discussion.

Comment 59

[[e-mail]]

Comment on attachment 425508 [details]
WIP screenshot, proposal 3

I've only just noticed one glaring problem with both this version (and version 1) in that the height of the dialog depends on whether any of the controls are visible :-( Otherwise I was on the point of marking the patch r+ (subject to Mac-specific review).

Comment 60

[Benoît]

> Further improvements to build apon this is great, and appreciated; but they
need to be approved by neil; and to avoid extra work that doesn't lead
anywhere, its probably best to do it in mockups and get his opinion on it; in
another bug.

I already opened a bug for improvements, and it was this one until KaiRo hijacked it. Since when is it appropriate to take over a bug from someone else that had already posted a patch? Since when is it appropriate to cancel reviews of a patch when it's not the canceller's patch?

Comment 61

[Robert Kaiser]

Attachment: patch v2.1 for proposal 3 implementation

This patch cares for keeping the height intact even when the download is finished and no icon is shown.

Comment 62

[Robert Kaiser]

Attachment: additional patch for adding the SVG used for the icons

This patch also adds the SVG for the new icons to the repository. The nice thing about the SVG format is that, unlike other image formats, we can add the standard license header in the file. :)

Comment 63

[[e-mail]]

Comment on attachment 426050 [details] [diff] [review]
additional patch for adding the SVG used for the icons

>+<svg
>+   xmlns:dc="http://purl.org/dc/elements/1.1/"
>+   xmlns:cc="http://creativecommons.org/ns#"
>+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>+   xmlns:svg="http://www.w3.org/2000/svg"
>+   xmlns="http://www.w3.org/2000/svg"
>+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
>+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
Is there any chance we can get some of these attributes cleaned up?

>+   width="1052.3622"
>+   height="744.09448"
There are lots of random-looking values to N decimal places :-(

>+    <path
>+       transform="matrix(0.83024878,0,0,0.83024878,-72.709979,178.73495)"
>+       d="m 363.67847,475.50076 c 0,67.07846 -54.37784,121.4563 -121.4563,121.4563 -67.07846,0 -121.4563,-54.37784 -121.4563,-121.4563 0,-67.07846 54.37784,-121.4563 121.4563,-121.4563 67.07846,0 121.4563,54.37784 121.4563,121.4563 z"
So, I looked up the w3schools SVG guide, and this is not how you define a circle... I'm not sure what to say about machine-generated gibberish.

>+       style="fill:#fafbfa;fill-opacity:1;fill-rule:evenodd;stroke:#3b3b3b;stroke-width:12.93162440999999951;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
Why is this very dark grey on off white, rather than black and white?

Comment 64

[Robert Kaiser]

(In reply to comment #63)
> (From update of attachment 426050 [details] [diff] [review])
> Is there any chance we can get some of these attributes cleaned up?

...and any of the other comments on the file markup:

I don't think it's a good idea to start messing with the machine-generated markup (other than adding a license statement), and I intentionally left the comment about being generated by Inkscape in for that reason as well.

> >+       style="fill:#fafbfa;fill-opacity:1;fill-rule:evenodd;stroke:#3b3b3b;stroke-width:12.93162440999999951;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
> Why is this very dark grey on off white, rather than black and white?

Because those are the colors that the original small buttons of the download manager are using, and I wanted to reuse exactly those to make the large buttons fit with the small ones as well as possible.

Comment 65

[Andrea Govoni]

Wow… I didn't know there was a "poll" about small Vs. big buttons, otherwise I would have jumped in before, and now I'm really afraid that those stylish little buttons could go away forever because *I liked them very much* since the SM2 final release.
The last Robert's proposal is an improvement where it adds the drop down arrows to the download name and location menus, but IMHO those new big buttons are very ugly compared to the current (small) ones. Cause of their size, they seems even a bit "childish" to me.

I really don't understand how some people can complain that the new buttons are too small to be clicked and/or noticeable!
I'm on Mac and they are of the same size of the three Close, Minimize and Zoom buttons that lie in the upper left corner of almost every regular Mac OS X Aqua window, but I've never heard anyone claiming they are too small. I'm quite sure this would be true even if we compare them with the Windows/Linux standard Close, Minimize and Zoom buttons. And, before you ask, I work on a tiny 12" laptop every day.
I think that the size, style and position of the new buttons are *perfect* and I wouldn't like to see them enlarged and moved to the bottom right corner of the download window cause of a bunch of users that don't like the new modern theme. I really don't see any UI reason to waste the current layout. I can also argue that there could easily be a vast majority of users that really like the new small buttons and aren't aware of the imminent change, thus aren't going to come here to oppose to it.
Robert and Neil, even if it seems that's a bit too late to (not) change again, please change your mind and keep the current small buttons.

Comment 66

[[e-mail]]

(In reply to comment #64)
> I don't think it's a good idea to start messing with the machine-generated
Well I was at least hoping for identical circles.

> > >+       style="fill:#fafbfa;fill-opacity:1;fill-rule:evenodd;stroke:#3b3b3b;stroke-width:12.93162440999999951;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
> > Why is this very dark grey on off white, rather than black and white?
> Because those are the colors that the original small buttons of the download
> manager are using, and I wanted to reuse exactly those to make the large
> buttons fit with the small ones as well as possible.
Ah, I hadn't noticed the #3b3b3b (Mac uses black), but the white should be white, not #fafbfa...

Comment 67

[[e-mail]]

Attachment: Hand-written SVG

Since these controls are so simple, I was able to write this in Notepad.

At least this way I know that all the circles are the same size etc.

Note that this is based on the original downloadButtons.png which has a border around each icon built in to the image that I have taken into account.

Comment 68

[Robert Kaiser]

(In reply to comment #67)
> Created an attachment (id=426617) [details]
> Hand-written SVG

I don't like this image, the background is too white, the borders' colors are too light, and I won't even go into trying to find out if dimensions fit anything. If you want to play markup nazi on images(!), so be it, but I won't change my own patch in here for it. I can't stand any more that any step I'm taking wrt those progress windows is being dissed, my hours of work seemingly not being worth anything at all and almost every comment only a help for wanting to rip out my few remaining hairs.
I have learned my lesson from this, if I ever work on images again, I guess I won't attach SVGs and probably not even make them available under the tri-license. And I'll probably refrain from working on any progress window stuff for a while - for my own sanity.

Comment 69

[[e-mail]]

(In reply to comment #65)
> I'm on Mac and they are of the same size of the three Close, Minimize and Zoom
The Mac has its own set of buttons that are actually 36% larger.

Comment 70

[[e-mail]]

Attachment: 25% larger buttons

I couldn't come up with buttons that were 36% larger and still looked good.

Comment 71

[Andrea Govoni]

(In reply to comment #70)
> Created an attachment (id=426662) [details]
> 25% larger buttons
> 
> I couldn't come up with buttons that were 36% larger and still looked good.

I'm sorry but I'm a bit confused now.
Larger than… what?
The buttons in the screenshot you posted as attachment 426662 [details] are pretty much of the same size of the analogous buttons in the shipping SeaMonkey 2.0.2 (Mac version).
Is it because there will be no change in the size of the buttons?
If this is the case, why bother to create new buttons at all?

Comment 72

[Benoît]

> I can't stand any more that any step I'm taking wrt those progress windows is being dissed, my hours of work seemingly not being worth anything at all and almost every comment only a help for wanting to rip out my few remaining hairs.

This is volunteer work, you know. You could have ignored the entire thing. Please don't act as if you have to work on this.

Comment 73

[aditsu]

(In reply to comment #68)
> I don't like this image

The border color is a bit strange indeed, otherwise looks fine to me.

> I can't stand any more that any step I'm
> taking wrt those progress windows is being dissed

I'm tempted to say "what goes around comes around". I don't know Neil's motives though, he seems to be just very pedantic.

> And I'll probably refrain from working on any progress window
> stuff for a while - for my own sanity.

You could have let Benoît handle it...

Comment 74

[[e-mail]]

(In reply to comment #71)
> The buttons in the screenshot you posted as attachment 426662 [details] are pretty much
> of the same size of the analogous buttons in the shipping SeaMonkey 2.0.2 (Mac
> version).
That's because the Mac version's buttons are already that size for some reason.

Comment 75

[Andrea Govoni]

(In reply to comment #74)
> That's because the Mac version's buttons are already that size for some reason.

Got it, thanks.
It wasn't clear to me that the small buttons were a Windows/Linux only issue, maybe because some users that complained about small button in the previous comments are on Mac.
So, my only remaining concern is about the proposed new buttons position (I can live with slighty different buttons graphics).

Comment 76

[[e-mail]]

As I noticed in bug 515053, moving the icons did in fact result in less than satisfactory behaviour for opening a progress window from the download manager. So we might have to give that a miss too anyway.

Comment 77

[[e-mail]]

Attachment: Uncontroversial parts of KaiRo's patch

Even if we can't come to a decision about the control buttons, we can at least appreciate the menubutton and Modern focus improvements, so I spun them out into a separate patch, although I had to adapt it slightly to deal with the original button placement so I'm requesting a review on what I ended up with.

Comment 78

[R.N. (Roger) Folsom]

This thread has gotten way over my head (I'm nowhere close to even dreaming of ever qualifying as a beginning amateur novice programmer or developer), but my experience is that all icon size judgments need to include a test of what the icon size is when about:config, layout.css.devPixelsPerPx = 1.

The reason is as follows.

On my Win2kSp4 laptop computer, 15" UXGA screen (1600x1200 pixels), Display Properties, Settings, Advanced, I (and other UXGA laptop users) have set the Windows system font size for 144dpi (150% of the "standard" 96dpi).  Otherwise the Windows fonts for the start menu, icon labels, Windows explorer, etc., are much too small to be read comfortably, much less accurately.  And there is an enormous difference between 143dpi and 144dpi, apparently because the latter causes font lines to be drawn using two pixels rather than one pixel.  With the 144dpi setting, the Windows fonts are noticeably heavier and more readable than with 143dpi.

But as a result of that Windows font setting of 144dpi, if SeaMonkey 2.0.2 about:config, layout.css.devPixelsPerPx is NOT set to 1, SeaMonkey fonts look good but are "thick" enough to take up so much room that in key dialog boxes essential information or fields were missing.  For example, in Mail & Newsgroups Account Settings, [Incoming] Server Settings, the Local Directory field is missing (although its "Local Directory" title does show), making it impossible to tell SeaMonkey where the email folder was.  Also, Composer would not work.  (See P.S. #3 below for background for the layout.css.devPixelsPerPx = 1 solution to such problems.)

So what does that have to do with SeaMonkey icons?  Apparently, layout.css.devPixelsPerPx = 1 not only causes font characters to be drawn with lines only one pixel thick (regardless of the Windows font dpi setting), but also causes icons (or perhaps icon outer borders) to use lines only one pixel thick.  Consequently, on a Windows UXGA computer whose system fonts are set to 144dpi, layout.css.devPixelsPerPx = 1 makes icons much smaller than they would be otherwise.

For example, on my computer, in SM 2.0.2, the two icons in the download progress window are no larger than a lower case letter such as "a."

Roger Folsom

-------------------------------------------

P.S.#1 In userChrome.css, I have set the font size to 9 points.  But in my experience, that setting does not affect the issue I have raised here.

P.S.#2  These Windows system font setting for 144dpi issues did not come up in SeaMonkey 1.x, which (based on my wife's computer, which is still running SM 1.1.18), has no layout.css.devPixelsPerPx setting.

P.S.#3  For a summary background, see MozillaZine thread "What is marquee display," message http://forums.mozillazine.org/viewtopic.php?p=8671675#p8671675.  For more detailed background, see MozillaZine thread "SeaMonkey 2.0.2 Composer is MUCH too large," beginning with message http://forums.mozillazine.org/viewtopic.php?p=8653555#p8653555

Comment 79

[[e-mail]]

Comment on attachment 426918 [details] [diff] [review]
Uncontroversial parts of KaiRo's patch

Pushed changeset 713364a05671 to comm-central.

Comment 80

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #44)
> (In reply to comment #43)
> > Alternate approach: once the download has finished, display the icon the OS
> > provides for the given file type (e.g. in 32x32 at the far right of the dialog,
> > aligning its top with the file name button's top) and allow to double click it
> > (and make it focusable so that Enter can be used). Just a thought.
> 
> Interesting idea if it's doable. Can we investigate this in a followup?

Meanwhile I did the investigation, result: it's easily doable, took me only half an hour to code a WIP (basically setting a button's image attribute to "moz-icon://" + file.leafName + "?size=32" and setting command="cmd_open"). I'd like to know from others (esp. Callek, Neil, KaiRo) whether we should work into that direction before opening a followup bug, though.

Comment 81

[Justin Wood (:Callek)]

(In reply to comment #80)
> Meanwhile I did the investigation, result: it's easily doable, took me only
> half an hour to code a WIP (basically setting a button's image attribute to
> "moz-icon://" + file.leafName + "?size=32" and setting command="cmd_open"). I'd
> like to know from others (esp. Callek, Neil, KaiRo) whether we should work into
> that direction before opening a followup bug, though.

I'd support using the OS icon, I'm not certain on the UI feedback or location of using it though; but it sounds like a good idea to me (note: I'm not the one to convince for it to land though)