Closed Bug 825015 Opened 12 years ago Closed 12 years ago

Boot animation to be updated with current "unleashed" branding

Categories

(Firefox OS Graveyard :: Gaia, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
x86
macOS
Type:
defect

Tracking

(blocking-b2g:-, blocking-basecamp:-)

Status:
RESOLVED FIXED
Project Flags:
blocking-b2g -
blocking-basecamp -

People

(Reporter: barry, Unassigned)

Details

(Whiteboard: visual design, UX-P?)

Attachments

(2 files)

v5 sketch
549.72 KB, video/quicktime
Details
boot loop - 3x run through
1.33 MB, video/quicktime
Details
We are working with the branding agency to provide a new boot animation. Assets will be ready soon and will need to replace the current boot animation. Please advise on drop dead date for submitted animation to make build for MWC.
Chris or Dietrich, can you comment on the drop dead date? Barry, I assume you guys have cleared the format and file sizes in advance w/ Peter? Just want to make sure we're not dropping in a +10mb monster, per earlier discussions around update sizes, system footprint, etc.
Whiteboard: visual design, UX-P?
Also cc'ing Mwu.
I'm in communication with Pete/Barry and have asked that they provide the full set of details of the updated assets, etc. asap. We haven't committed to making this change just yet, but if it's as simple as an asset swap, then I'm not overly concerned. Mwu, can comment on the level of effort here and what other impact this change may have (if any)?
Josh, Chris or Mwu size is definitely the core limiting element for any creative. we definitely don't want to significant to the payload. can you highlight all the tech details of the current boot animation? is it a png sequence? if not file type? how many? playback framerate? what is the current filesize? for the entire sequence?
hello. can we get answers to all outstanding questions on the boot-up animation answered by eod today (Monday, 7 January). Would very much like to move forward in a way that ensures the animation will be included on the first device released. Josh, Chris or Mwu. please advise asap today (Monday) thanks
pinging this to the top of the queue again. we are starting the process with the animators and need tech specs to be included in the dialog.
Guys - this is not blocking ship for v1. If it's not blocking, then people are not going to actively go after the bug. It also isn't in the UX priority queue either for the work week either. If it's not in one of those two categories, then I don't expect this to get fixed for v1. I'll send it into triage just in case, but I don't think we can making spec changes at this point when we are literally less than a week away from code complete.
blocking-basecamp: --- → ?
Branding is working on an asset swap for the boot up animation and that should be available in the next couple weeks. This is not a blocker, but we should flag this as a follow-up for post-bb. Can the drivers help categorize this appropriately and assign an owner? I've marked this a P1 priority given it has exec visibility.
Priority: -- → P1
blocking-b2g: --- → tef?
blocking-b2g: tef? → tef+
blocking-basecamp: ? → -
A couple weeks is way beyond the window we have for client changes. This will have to wait for v2.
blocking-b2g: tef+ → -
See comment 8 -- is this not the case? We have management visibility on this one, so we'll need to communicate this if this is not doable in the v1 time frame at all. If comment 8 is not true, then I agree this will be hard to make v1.
Attached video v5 sketch —
we are in discussions on layout right now but here is the latest sketch for the loop.
(In reply to barry munsterteiger from comment #4) > Josh, Chris or Mwu > size is definitely the core limiting element for any creative. we > definitely don't want to significant to the payload. > > can you highlight all the tech details of the current boot animation? > is it a png sequence? if not file type? > how many? > playback framerate? > what is the current filesize? for the entire sequence? Just FYI that I've asked Patryk and/or Peter to chime in with this info.
(In reply to barry munsterteiger from comment #4) > Josh, Chris or Mwu > size is definitely the core limiting element for any creative. we > definitely don't want to significant to the payload. > > can you highlight all the tech details of the current boot animation? > is it a png sequence? if not file type? > how many? > playback framerate? > what is the current filesize? for the entire sequence? Hi, We are using Android's Android's bootanimation.zip/desc.txt format, which is described here: http://www.droidforums.net/forum/droid-hacks/33932-bootanimation-zip-file-explained.html In a nutshell, you are basically providing 1 or more sequences of png frames, and for each sequence, you can specify: 1 how many times it loops 2 a pause, if any, after each sequence and you can specify the overal dimensions and framerate of the entire animation. So this allows you to put up several different screens, each with its own animation, if you want. For Firefox OS, there is also an additional transition animation you must provide that happens during the brief crossfade to the lockscreen, and it must seemlessly transition from the end of the looping Android format until it fades to the lockscreen completely. To give you an idea, the original animation you provided was: 40+ frames that looped about 3 times (this took up about 8.2 mb) 18 frame transition animation that did not loop (this took up about 3.6 mb) Total: 11.8mb I'll let Michael Wu comment on whether this is too big and what the 'ideal' maximum size of both animations combined should be, as I think he had to chop the transition a little bit to save space. I will ping him to respond to this bug.
Michael, Can you please provide Barry and the rest of us with an update on size restrictions or any animation restrictions that are new compared to what I wrote in the comment above? I know you had to cut some frames to save space... so a hard cap number on the filesize would be a great start (including the main animation + transition). Thanks!
Flags: needinfo?(mwu)
the sketch above is 44 frames, the goal for the animators was to keep it as close to the text + light ray animation as possible. we are on target to deliver this for Friday.
Peter - your comments sounds about right. If the new animation isn't much bigger than the old one, it should be fine. Also, the transition animation size is affected by the area of the image that changes, so things may compress better if a smaller area is animated. This doesn't affect the primary animation loop though.
Flags: needinfo?(mwu)
martell posted these earlier today and may be where we land with the layout. cl.ly/image/1v1A1S272T0b/o
Thanks Michael. It appears only the fox will be animated. So for the transition, can it be split into a grey/textured background images with only the part where the fox resides being animated on top? I don't think you can split up the Android bootanimation.zip part like this, but there's no reason we can't do it for the transition, since it's Gaia? Let me know what you think.
And of course, the background image would have to include the logo at the bottom.
(In reply to Peter La from comment #19) > It appears only the fox will be animated. So for the transition, can it be > split into a grey/textured background images with only the part where the > fox resides being animated on top? I don't think you can split up the > Android bootanimation.zip part like this, but there's no reason we can't do > it for the transition, since it's Gaia? > I think this is doable within a single apng image without having to change any html/css on the gaia side, though I don't know if the encoder I've been using supports it
since it is pretty hard to see how the loop would work on device as a single instance this is a 3x run through of the GM. we can break this into the PNG sequence and deliver ASAP.
This is implemented now. Closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: