1269954 - Pop out download starting notification when a new download request is triggered.

Status: NEW

(Firefox :: Downloads Panel, defect, P3)

Description

[Sean Lee [:seanlee][:weilonge]]

In the new UX design, there will be a notification dialog when a new download request is triggered at awesome bar.

Comment 1

[Wesly Huang (EPM)]

As offline discussed, we use https://bugzilla.mozilla.org/show_bug.cgi?id=1269956 instead, to track download panel specific works.

Comment 2

[yifan [:yifan][:yliao]]

Attachment: Downloads notification UX spec

Hi Mike, according to the UX spec there'll be a notification which looks similar to the downloads panel, except for no summary and only 1 download is shown. How would you suggest to implement the notification? Should we add one XUL element for it or modify downloads panel to be able to show one entry only?

Comment 3

[:Paolo Amadini]

(In reply to yifan [:yifan][:yliao] from comment #2)
> Hi Mike, according to the UX spec there'll be a notification which looks
> similar to the downloads panel, except for no summary and only 1 download is
> shown.

Implementing this will be quite a bit of work, as most probably we cannot just reuse the Downloads Panel for it, given the special treatment such notification would have compared to the standard panel, especially with regard to the summary item and the sliding view that is currently being implemented.

On the other hand, the current notification system uses a different approach based on unobtrusive highlighting of the icon. As far as I can tell, this approach is effective and it has the advantage that it doesn't interrupt the user, as they may be performing a different task at the time the download fails or succeeds. While I think this reasoning still holds, maybe you have new research that shows issues with this approach?

One improvement that has been waiting for a long time was a clearer notification of failed downloads in the Indicator on the toolbar. Now that bug 1139472 is implemented, we can easily extend it to cover error cases as well, which will improve the visibility of failed downloads with little effort.

Comment 4

[yifan [:yifan][:yliao]]

Thank you Paolo! Morpheus could you share some idea about this?

Comment 5

[Bryant Mao [:bryantmao]]

(In reply to :Paolo Amadini from comment #3)
> (In reply to yifan [:yifan][:yliao] from comment #2)
> > Hi Mike, according to the UX spec there'll be a notification which looks
> > similar to the downloads panel, except for no summary and only 1 download is
> > shown.
> 
> Implementing this will be quite a bit of work, as most probably we cannot
> just reuse the Downloads Panel for it, given the special treatment such
> notification would have compared to the standard panel, especially with
> regard to the summary item and the sliding view that is currently being
> implemented.
> 
> On the other hand, the current notification system uses a different approach
> based on unobtrusive highlighting of the icon. As far as I can tell, this
> approach is effective and it has the advantage that it doesn't interrupt the
> user, as they may be performing a different task at the time the download
> fails or succeeds. While I think this reasoning still holds, maybe you have
> new research that shows issues with this approach?

It does take efforts on the implementation, but we believe it has it's value to exist. 

Through out the download process, there are two moments which are critical to user: a file that starting to download, an error happened on the downloading item. Of course the indicator will provides unobtrusive info in those situations, but what "unobtrusive" means user might probably ignore it. 

By introducing the notification, we could provide meaningful information for user to confirm and take action in real time. (We might all have the frustrate experience of downloading a big file and at the end find out that it has failed at the very beginning. Case gets worse when there are multiple failures.) Meanwhile, if user is performing a different task, they can just leave it and it will disappear in 5 seconds.

Back to the implementation, maybe we can find other existing modules in Firefox to reuse or modify it to provide the notification?

> One improvement that has been waiting for a long time was a clearer
> notification of failed downloads in the Indicator on the toolbar. Now that
> bug 1139472 is implemented, we can easily extend it to cover error cases as
> well, which will improve the visibility of failed downloads with little
> effort.

We've already extended the indicator to cover all the error cases (fail/malware/unwanted/uncommon download) by using dot badge on indicator with accessible color which both normal and color-blindness people can see.

You may take a look on the spec here:https://mozilla.invisionapp.com/d/main/#/console/7081133/156737291/preview

Comment 6

[:Paolo Amadini]

(In reply to Bryant Mao [:bryantmao] from comment #5)
> Back to the implementation, maybe we can find other existing modules in
> Firefox to reuse or modify it to provide the notification?

I don't think we have anything like that. We have platform notifications, that are however not anchored to a specific item in the toolbar so it's not what we need here.

> We've already extended the indicator to cover all the error cases
> (fail/malware/unwanted/uncommon download) by using dot badge on indicator
> with accessible color which both normal and color-blindness people can see.

I cannot access the link in the previous comment, but if this is the design you're referring to (again, what you see may change as this link is live, not referring to a specific version of the document):

https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/156737291

I find that the yellow dot has very little contrast with the background, I don't see how this could be more accessible than the current design. Regardless, did you review this with the Firefox UX team? We're possibly using a red dot to indicate a camera or microphone permission being used, so there might be some conflict in the iconography if a red dot is also used to indicate failure.

Comment 7

[Wesly Huang (EPM)]

(In reply to :Paolo Amadini from comment #6)
> I find that the yellow dot has very little contrast with the background, I
> don't see how this could be more accessible than the current design.
> Regardless, did you review this with the Firefox UX team? We're possibly
> using a red dot to indicate a camera or microphone permission being used, so
> there might be some conflict in the iconography if a red dot is also used to
> indicate failure.

Bryant, I thought you've reviewd the design with Firefox UX team before, would you help confirm? Especially the usage of icon color that Paolo reminded. Thanks.

Comment 8

[Bryant Mao [:bryantmao]]

(In reply to :Paolo Amadini from comment #6)
> (In reply to Bryant Mao [:bryantmao] from comment #5)
> > Back to the implementation, maybe we can find other existing modules in
> > Firefox to reuse or modify it to provide the notification?
> 
> I don't think we have anything like that. We have platform notifications,
> that are however not anchored to a specific item in the toolbar so it's not
> what we need here.
> 
> > We've already extended the indicator to cover all the error cases
> > (fail/malware/unwanted/uncommon download) by using dot badge on indicator
> > with accessible color which both normal and color-blindness people can see.
> 
> I cannot access the link in the previous comment, but if this is the design
> you're referring to (again, what you see may change as this link is live,
> not referring to a specific version of the document):
> 
> https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/156737291
> 
Yes, that's exactly the link of our spec I referred to.

> I find that the yellow dot has very little contrast with the background, I
> don't see how this could be more accessible than the current design.
> Regardless, did you review this with the Firefox UX team? We're possibly
> using a red dot to indicate a camera or microphone permission being used, so
> there might be some conflict in the iconography if a red dot is also used to
> indicate failure.

I'll let our visual master to answer the question :)

Comment 9

[Carol Huang [:Carol]]

(In reply to :Paolo Amadini from comment #6)

> I find that the yellow dot has very little contrast with the background, I
> don't see how this could be more accessible than the current design.
> Regardless, did you review this with the Firefox UX team? We're possibly
> using a red dot to indicate a camera or microphone permission being used, so
> there might be some conflict in the iconography if a red dot is also used to
> indicate failure.

For the dot, I've adjust the yellow color and size, also tweak the shadow to bring up the contrast with the background. And yes, we've went through visuals in the UX critique session. Aislinn shared with me the proposal that the red dot is being used on microphone permission. In terms of iconography, the red dot on the microphone is part of the icon to show the permission status. But the dot on the toolbar is a notification/hint sitting next to download button to remind user something is happening, they should take look. Plus the placement is different so it won't be conflict. Besides, I saw more and more concept in the UX crits session using a dot as a notification badge. I think it could develop into a common design language on Firefox. thanks!

Comment 10

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: Bug 1269954 - When a download is added, popup the detail of the download item as a notification.

Review commit: https://reviewboard.mozilla.org/r/89298/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/89298/

Comment 11

[KM Lee [:rexboy] (inactivate after Sep. 22)]

I have a very rough version of patch now. This patch added a view object called NewDownloadNotifyPanel which holds a simple panel that would be opened when a new download is added with the latest added download item.

Things can be improved may be:
- Initialization progress of NewDownloadNotifyPanel.
- The popup should be shown after animateNotifications is over and I just put it off by setTimeout for now. Sending a notify somehow after animate notification has end may be better.

If the download ended very quick, the popup is still shown displaying its finished state. This seems ok to me but maybe double-check with UX team is needed.

And since I'll be away for the whole next week, I'll continue the work from the week after next.

Comment 12

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Comment on attachment 8805531 [details]
Bug 1269954 - When a download is added, popup the detail of the download item as a notification.

Paolo may you take a look on on this rough version of patch?
This patch contains more javascript changes, I hope I'm going on the right way.

Comment 13

[:Paolo Amadini]

Comment on attachment 8805531 [details]
Bug 1269954 - When a download is added, popup the detail of the download item as a notification.

I'm not sure if we have a precedent for this type of notification panels that disappear after a short time, so a working prototype like this can definitely be a good thing before we productize the code.

As I said, there is generally a non-trivial amount of work to get this right, even if we reuse the styling of the current download items.

The main question is whether the panel is designed to be interacted with. If so, we should likely have code in place that prevents the panel from going away on hover, and we should decide if we want to hide the panel or not if the user presses a button on the item.

Download items in this panel would certainly need to behave differently, for example we don't have a subview for malware, and download items may evolve to any state while they are displayed, for example they may be completed shortly after they are displayed.

If the panel is not interactive, we can simply dismiss the panel when there is a click inside it. We also have to determine if we want the panel to go away if the user clicks anywhere else on the current web page.

Do we still want to show a similar notification on failure? Is it possible that a failure notification replaces another notification that is currently visible? In that case, if the notification is interactive, we may have a race condition if the user is about to click an action button for the download, and it suddenly changes to a different download.

Also, this notification should never appear at the same time as the Downloads Panel, so it should disappear if the user clicks the panel icon.

So, it's a bit too early to say what the final code will look like. It's also probable that we'll need to break down this bug into smaller pieces to implement the various parts, and we should have regression tests for all the cases described above.

For the next couple of weeks I won't have a lot of time for reviews as we're completing the permissions notification project that I'm working on. Maybe Jared can help, otherwise you may have to wait a bit, as feedback from me will be slower than usual.

Comment 14

[KM Lee [:rexboy] (inactivate after Sep. 22)]

(In reply to :Paolo Amadini from comment #13)
Thanks for the advice!
I made some discussion with UX; some issues has an answer and some may
still need to be digged further. Let me make a reply on these issues.
Besides I'll try to play with the prototype and see if we have any other
cases that need to be discussed.

> Comment on attachment 8805531 [details]
> Bug 1269954 - When a download is added, popup the detail of the download
> item as a notification.
> 
> I'm not sure if we have a precedent for this type of notification panels
> that disappear after a short time, so a working prototype like this can
> definitely be a good thing before we productize the code.
> 
> As I said, there is generally a non-trivial amount of work to get this
> right, even if we reuse the styling of the current download items.
> 
> The main question is whether the panel is designed to be interacted with. If
> so, we should likely have code in place that prevents the panel from going
> away on hover, and we should decide if we want to hide the panel or not if
> the user presses a button on the item.
> 
current answer for this is yes, we need to reset the timer once clicking
and hovering. However if the action of the button is something that causes
focus lost (e.g. open the file), the notification should be closed directly.

> Download items in this panel would certainly need to behave differently, for
> example we don't have a subview for malware, and download items may evolve
> to any state while they are displayed, for example they may be completed
> shortly after they are displayed.
From UX's comment, the best case is to "translate" the notification to real
download panel, which means the notification expands to the real download panel
and show/behave the same with download panel in this case.
However this seems to be difficult if we still think implement the notification
as a different instance is better.
If implementing the notification and download panel as the same instance is
not possible, alternate ways we came up are
- when clicking, just quickly hide the notification, show download panel and
  slide to subview. (maybe with some change on prompt text, like "click to
  open the download panel for detail")
- use the same warning dialog as all downloads panel. see p.24 of
  https://bug1269956.bmoattachments.org/attachment.cgi?id=8791134
> 
> If the panel is not interactive, we can simply dismiss the panel when there
> is a click inside it. We also have to determine if we want the panel to go
> away if the user clicks anywhere else on the current web page.
The answer I got is it won't go away until 5 seconds or specified interaction
on the item.
The counting would become 
> 
> Do we still want to show a similar notification on failure? Is it possible
> that a failure notification replaces another notification that is currently
> visible? In that case, if the notification is interactive, we may have a
> race condition if the user is about to click an action button for the
> download, and it suddenly changes to a different download.
Here we have some possible ways:
- Get notifications queued, and show the next after the first disappear.
- Append the incoming downloads at the bottom of the list.
- If multiple alerts exist, group them. This is shown in p.12 of the spec above
  but I'm not sure what to do if both successful and unsuccessful
  notifications exists yet. Due to this is somewhat corner case and complex we
  think it's in lower priority.

I will look on codes to gain some insight for these open issues. And please give
me some thoughts if any.

Comment 15

[KM Lee [:rexboy] (inactivate after Sep. 22)]

From our latest discussion: For the malware case, we think we are going to popup the all downloads panel and show the warning box inside. But I'm not sure if it's a good idea yet since I can't find a good way to instruct the all downloads panel popup out the warning after it's opened. Paolo do you have any comments on this?

I found hovering detection is implemented in popup window itself but in private. Not sure if there's a good way to make use of it.

Comment 16

[KM Lee [:rexboy] (inactivate after Sep. 22)]

If we want to split out some working item, I'm not quite sure...maybe we can split out some of:
- the hover-and-reset timer implementation?(and we can simply let it go in 5 seconds in this bug?)
- queueing newer items? (and in this bug maybe the newer item just overwrite the older without any queueing or listing?)

Comment 17

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Sorry I got some update and let me summarize before setting ni? again. Sorry for bothering.

Comment 18

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: Screenshot_comparison

To decide the behavior on malware items, we made some inspection on the behavior of current download panel;
To the left is the UX spec[1] specifying that clicking on "unblock" should slide to the subview, just like clicking on the action button on item. while in Nightly clicking on "allow download" still opens an alert on the active browser window (to the right in the image).

Are we working on or planning to finish the specification on the left side?
- If yes, then clicking on the malware item in notification may need to be like
"close notification, open the download panel and slide to the subview", so their behaviors are somehow consist. and this is the way UX more preferred.
- If no, then clicking on it may just popup an alert just like clicking on the right-click menu.
Paolo do you have any suggestions on this?


[1]( https://people-mozilla.org/~sfranks/Malware/ )

Comment 19

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: action for malware open

Tried on making the action of malware and took the screenshot.
Haven't show to UX yet but the scenario is what I mentioned on previous comment.

Comment 20

[:Paolo Amadini]

This feature should be one of the items we'll examine in more detail next week. The various scenarios we discussed and the prototypes will be useful as the starting point.

It's clear that there are various separate cases to keep into account, so we should carefully evaluate the benefits and the costs of this feature. Keep in mind that if we go ahead, we'll need to write detailed regression tests for each case we handle.

Comment 21

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Alright. 
Anyway I have a patch that addressed all the points discussed (I guess) above now. I'll post it here after cleaning up the code.

Comment 22

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Comment on attachment 8805531 [details]
Bug 1269954 - When a download is added, popup the detail of the download item as a notification.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/89298/diff/1-2/

Comment 23

[KM Lee [:rexboy] (inactivate after Sep. 22)]

This should be descoped from MVP by discussion from our discussion at Tue. NI? Wesley for confirmation.

Comment 24

[Wesly Huang (EPM)]

confirmed our of MVP, move to backlog instead.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.