You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For usability and accessibility reasons, animations should be pausable/resumable. The satellite loop is a GIF and cannot currently be paused or resumed.
Questions and Considerations
GIFs cannot be paused with any browser APIs. There are three general approaches to this problem:
When the image should be paused, replace it with a static image. When it should be playing, replace it with the GIF. This is an easy approach, but if the user "pauses" the GIF in the middle of the loop, instead of staying at and resuming from the middle, they'll instead see a flash as the image changes to the static image, and when they "unpause" the GIF, it will start playing from the beginning, not where they stopped it.
Replace the GIF with a series of images and animate them ourselves. This is harder and I'd advocate against it, but it does allow us to preserve the right tracking location within the animation. I think we already have access to the individual image frames via the metadata JSON, so at least we don't have to figure that out. Another argument against this approach is it requires the user's device to download each of the images individually, which could result in a lot more data going across the wire than downloading a single GIF.
Switch to a video. We could talk to NESDIS about whether they could add a WebM (or similarly patent unencumbered encoding) video file in addition to the GIF. Oftentimes video files can be smaller than GIFs, and because they are videos, we can take advantage of browser-native video controls, including pausing and resuming. For example, the GOES16 GIF for MPX right now is about 7.7 MB. Converting it to WebM reduces that to 1.3 MB. (I don't want to make too many assumptions about how NESDIS is creating images, but ffmpeg can convert GIFs to WebM.)
It may also be possible for us to do the GIF -> video conversion on our end. For that, we'd need to understand the update cadence so we could do it periodically automatically. The conversion takes too long to do on-demand.
Acceptance Criteria
Users have a mechanism for pausing and resuming the satellite loop animation
Tag the related milestone to this story
The text was updated successfully, but these errors were encountered:
Description
For usability and accessibility reasons, animations should be pausable/resumable. The satellite loop is a GIF and cannot currently be paused or resumed.
Questions and Considerations
GIFs cannot be paused with any browser APIs. There are three general approaches to this problem:
When the image should be paused, replace it with a static image. When it should be playing, replace it with the GIF. This is an easy approach, but if the user "pauses" the GIF in the middle of the loop, instead of staying at and resuming from the middle, they'll instead see a flash as the image changes to the static image, and when they "unpause" the GIF, it will start playing from the beginning, not where they stopped it.
Replace the GIF with a series of images and animate them ourselves. This is harder and I'd advocate against it, but it does allow us to preserve the right tracking location within the animation. I think we already have access to the individual image frames via the metadata JSON, so at least we don't have to figure that out. Another argument against this approach is it requires the user's device to download each of the images individually, which could result in a lot more data going across the wire than downloading a single GIF.
Switch to a video. We could talk to NESDIS about whether they could add a WebM (or similarly patent unencumbered encoding) video file in addition to the GIF. Oftentimes video files can be smaller than GIFs, and because they are videos, we can take advantage of browser-native video controls, including pausing and resuming. For example, the GOES16 GIF for MPX right now is about 7.7 MB. Converting it to WebM reduces that to 1.3 MB. (I don't want to make too many assumptions about how NESDIS is creating images, but ffmpeg can convert GIFs to WebM.)
It may also be possible for us to do the GIF -> video conversion on our end. For that, we'd need to understand the update cadence so we could do it periodically automatically. The conversion takes too long to do on-demand.
Acceptance Criteria
Tag the related milestone to this story
The text was updated successfully, but these errors were encountered: