Closed Bug 812813 Opened 7 years ago Closed 7 years ago

Downloads panel needs to draw your attention when a download finishes

Categories

(Firefox :: Downloads Panel, defect, P2)

x86
All
defect

Tracking

()

RESOLVED FIXED
Firefox 20

People

(Reporter: wesj, Assigned: Paolo)

References

(Blocks 1 open bug, )

Details

Attachments

(5 files, 4 obsolete files)

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.
The intended behavior will probably be part of bug 801832, we lack the content adapt to show an animation of any sort currently
Blocks: 801832
Flags: needinfo?(shorlander)
Gentle UX-ping, we are still waiting for a design proposal.
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"
Priority: -- → P2
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
Flags: needinfo?(shorlander)
Ok, we are going for option 2 considered the current button.
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.
that's funny though :)
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
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?
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Attachment #696051 - Flags: review?(mak77)
Attachment #696051 - Flags: feedback?(mconley)
Flags: needinfo?(shorlander)
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 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.
Attachment #696051 - Flags: feedback?(mconley) → feedback+
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 on attachment 696051 [details] [diff] [review]
Same notification color on all themes

clearing while waiting for answers.
Attachment #696051 - Flags: review?(mak77)
(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.
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.
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.
Attached patch One element for both animations (obsolete) — Splinter Review
While waiting for the final icons, I updated the CSS rules to use only one XUL
element for both animations.
Attachment #696051 - Attachment is obsolete: true
Attachment #698024 - Flags: review?(mak77)
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 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")
Attachment #698024 - Flags: review?(mak77) → review+
Attached patch Final patch (obsolete) — Splinter Review
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.
Attachment #698024 - Attachment is obsolete: true
Blocks: 826999
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac7fc104c829
Target Milestone: --- → Firefox 20
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
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 :)
https://hg.mozilla.org/mozilla-central/rev/9cb6dcfb0b85
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.