Currently, when we notify the user of a download and give them the run/save/cancel options, 1 second later we transition in the navbar so that notification moves up the screen. The timing is such that as you go to tap one of the notification buttons, they move and you end up tapping something in the navbar instead. I gather delay was introduced to draw attention to the notification. I would argue its not necessary as the slide-in transition already does that. See http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/downloads.js#493 (dl-request handler) for the code and delay in question.
Just checked the current implementation. I agree the timing feels too long. And with our slide-in transition, pushing the info bar up doesn't feel right. I did a quick animation test using Keynote(see attachment). Personally I prefer #2 approach which is using different speed for two bars, but the transitions start and finish at the same time. So there is a subtle perceived difference on the two bars. The goal here is to indicate that it's the info bar that the users need to pay attention, not the navigation bar.
That is exceedingly subtle, I've replayed it several times and although I understand what you are going for, I'm not sure I perceive a difference. Maybe the easing on #2 is slightly different on the infobar?
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.