812813 - Downloads panel needs to draw your attention when a download finishes

Status: RESOLVED FIXED

(Firefox :: Downloads Panel, defect, P2)

Description

[Wesley Johnston (:wesj)]

Right now, the download button is in the upper right corner of the screen where its easy to ignore most of the time. As a side effect its easy to not notice when a download finishes (or just forget about a download entirely)

I think we should probably play the download started animation in reverse when a download finishes.

Comment 1

[Marco Bonardo [:mak]]

The intended behavior will probably be part of bug 801832, we lack the content adapt to show an animation of any sort currently

Comment 2

[Marco Bonardo [:mak]]

Gentle UX-ping, we are still waiting for a design proposal.

Comment 3

[u428464]

Some info in this etherpad I think : https://firefox-ux.etherpad.mozilla.org/remaining-download-panel-ux

"Downloads panel needs to draw your attention when a download finishes

    https://bugzilla.mozilla.org/show_bug.cgi?id=812813

    Pulse animation on progress bar

    Animate filetype icon dropping

    Show download arrow peeking out"

Comment 4

[Stephen Horlander [:shorlander]]

A quick pulse for each complete download would be enough to draw your attention if you are looking for it but (hopefully) not enough to be annoying.

Examples:

http://people.mozilla.com/~shorlander/files/download-notification/download-notification-01.html

http://people.mozilla.com/~shorlander/files/download-notification/download-notification-02.html

Comment 5

[Marco Bonardo [:mak]]

Ok, we are going for option 2 considered the current button.

Comment 6

[u428464]

Third one one (http://people.mozilla.com/~shorlander/files/download-notification/download-notification-03.html) looks nice too except it's a bit too visible.

Comment 7

[Marco Bonardo [:mak]]

that's funny though :)

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

2 > 3  > 1 - IMO ;d
third option will be first, when box will be without EXE name

I only hope this animation will be seen, even when user (like me e.x.) move Downloads button on the far right

Comment 9

[:Paolo Amadini]

Attachment: Same notification color on all themes

This shows a finished download notification, following the given mockup.

Stephen, we'll probably need the growing arrow to be of the same color of the
glowing arrow, can you provide 128x128px icons for the right colors?

Mike, do you have some spare cycles to test this on platforms other than Linux?

Comment 10

[Marco Bonardo [:mak]]

Comment on attachment 696051 [details] [diff] [review]
Same notification color on all themes

Review of attachment 696051 [details] [diff] [review]:
-----------------------------------------------------------------

I think the patch could be simplified a bit sharing more stuff between the 2 notifications

::: browser/components/downloads/content/indicatorOverlay.xul
@@ +51,5 @@
>                           max="100"/>
>          </vbox>
>          <vbox id="downloads-indicator-icon"/>
> +        <vbox id="downloads-indicator-notification-start"/>
> +        <vbox id="downloads-indicator-notification-finish"/>

Any reason we could not keep the old single downloads-indicator-notification and differentiate the animation and background just on downloads-indicator[notification=type]?
I actually expect we'll unify the notification arrow image to a single one and this would make the style rules simpler.

::: browser/themes/gnomestripe/downloads/downloads.css
@@ +266,5 @@
> +  opacity: 0;
> +  background: url("chrome://browser/skin/downloads/download-notification-finish.png")
> +              center no-repeat;
> +  background-size: 16px;
> +}

If we could use the same arrow image for start and finish this rule could be merged... I guess we need shorlander to evaluate if the colored version of the icon is too much distracting for starting downloads.

In the meanwhile, we could just modify the existing download-notification.png providing active-inactive states into it, and use moz-image-region based on the type attribute.

@@ +270,5 @@
> +}
> +
> +@keyframes downloadsIndicatorNotificationFinish {
> +  from { opacity: 0; transform: scale(1); }
> +  20%  { opacity: .65; animation-timing-function: ease-in; }

is the opacity value guessed from the mock-up? Otherwise, why using a different value from the .85 of the "start" case? Would be better to keep them coherent.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 696051 [details] [diff] [review]
Same notification color on all themes

Review of attachment 696051 [details] [diff] [review]:
-----------------------------------------------------------------

This approach looks OK to me - my only concern is in the case of small downloads on fast networks... what does this look like if the download completes before the notification="start" animation is done? I don't see any queueing, so I guess the "start" animation is abruptly stopped?

This might be polish down the road, but we might want to queue those animations so that we only show the "finish" animation once the "start" animation has completed.

Comment 12

[Marco Bonardo [:mak]]

we should probably not even show a finish notification if the start notification started just before it. The notification should bring attention to the button, but if a download just started we already captured the user's attention with the start notification... Maybe we could just store the start notification timestamp and check if enough time is elapsed?

Comment 13

[Marco Bonardo [:mak]]

Comment on attachment 696051 [details] [diff] [review]
Same notification color on all themes

clearing while waiting for answers.

Comment 14

[:Paolo Amadini]

(In reply to Mike Conley (:mconley) from comment #11)
> what does this look like if the download
> completes before the notification="start" animation is done? I don't see any
> queueing, so I guess the "start" animation is abruptly stopped?

You can easily test this by using "Save Page As" on an "about:" page. It doesn't
look too bad as you might think, and the notification is peripheral in any case.
I wonder if fixing this is worth the (even small) complexity of enqueuing?

(In reply to Marco Bonardo [:mak] (intermittently avail. until 3 Jan) from comment #10)
> Any reason we could not keep the old single downloads-indicator-notification
> and differentiate the animation and background just on
> downloads-indicator[notification=type]?

Could work.

> If we could use the same arrow image for start and finish this rule could be
> merged... I guess we need shorlander to evaluate if the colored version of
> the icon is too much distracting for starting downloads.

The question is more about whether we care about the difference between the two
colors in this notification. Currently we use the colored version of the button
to indicate something close to a "completed" download state, and the grey
progress bar or grey button when a new download starts. It might make sense
to convey the idea that a download "enters" the panel in an in-progress state
and "exits" it in a completed state. On the other hand, only one color might be
visually simpler.

> In the meanwhile, we could just modify the existing
> download-notification.png providing active-inactive states into it, and use
> moz-image-region based on the type attribute.

I'll defer merging until Stephen determines whether we need two different icons.

> is the opacity value guessed from the mock-up? Otherwise, why using a
> different value from the .85 of the "start" case? Would be better to keep
> them coherent.

Yeah, it's copied from the mockup, but I guess it might as well be consistent
with the other notification.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Fwiw - I just tried this on Windows, and it looked _awesome_. I really like it. :)

Also, you're right wrt the animations; they don't look too shabby. It's possible that queuing animations is not worth the effort this iteration.

Comment 16

[Marco Bonardo [:mak]]

Stephen, here we need the graphic arrow for the tier 1 platforms, and to know whether we may use the same arrow for both "begin" and "finish" notifications, or rather separate empty/filled-up arrows.

Comment 17

[:Paolo Amadini]

Attachment: One element for both animations

While waiting for the final icons, I updated the CSS rules to use only one XUL
element for both animations.

Comment 18

[:Paolo Amadini]

Also, tried opacity at .85, but .65 (like the mockup) actually looks better,
with .85 the notification looks too "solid" (the other notification moves,
so it doesn't have the same effect).

Comment 19

[Marco Bonardo [:mak]]

Comment on attachment 698024 [details] [diff] [review]
One element for both animations

Review of attachment 698024 [details] [diff] [review]:
-----------------------------------------------------------------

r=me modulo the images that shorlander will give you, though I don't care reviewing them, just ensure they are the proper size and we are fine.

::: browser/themes/gnomestripe/downloads/downloads.css
@@ +234,2 @@
>  
>  #downloads-indicator-notification {

Actually this rule is shared for both start and finish notifications so the comment is slightly lying... not a big deal though... at a maximum just move the comment below it (whatever thing you do is valid for all themes, including "nothing")

Comment 20

[Stephen Horlander [:shorlander]]

Attachment: Download Finished Notification - OSX

Comment 21

[Stephen Horlander [:shorlander]]

Attachment: Download Finished Notification @2x - OSX

Comment 22

[Stephen Horlander [:shorlander]]

Attachment: Download Finished Notification - Windows

Comment 23

[Stephen Horlander [:shorlander]]

Attachment: Download Finished Notification - Windows

Comment 24

[Stephen Horlander [:shorlander]]

Attachment: Download Finished Notification - Linux

Comment 25

[:Paolo Amadini]

Attachment: Final patch

This includes the new icons, except the 2x version, that I can't test locally
and for which we still don't have the corresponding 2x grey version.

Comment 26

[:Paolo Amadini]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac7fc104c829

Comment 27

[:Paolo Amadini]

I missed that the notification element is not 16x16 in large icons mode.
Pushed the quick fix directly:

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a99d532ccd6

Comment 28

[Marco Bonardo [:mak]]

backed out (both) due to bc test failure

browser_first_download_panel.js | TypeError: DownloadsCommon.getData(...)._notifyNewDownload is not a function

looks like the test should be updated for the new methods... while there please merge the patches and add reviewer :)

Comment 29

[Marco Bonardo [:mak]]

backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/08176bc91aae

Comment 30

[:Paolo Amadini]

Attachment: Fixed

https://hg.mozilla.org/integration/mozilla-inbound/rev/9cb6dcfb0b85

Comment 31

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/9cb6dcfb0b85