The negative effects of animated GIFs in MuseScore's Handbook

• Nov 19, 2024 - 21:37

The presence of animated GIFs in MuseScore's documentation has increased dramatically in recent months. Indeed some of the GIFS are quite useful, but on certain pages the abundance of autoplay, forever looping animated GIFs has reached the point of distraction.

Pros of animated GIFs:

     • A picture is worth 1000 words

     • GIFs have a lighter storage footprint than videos

Cons of animated GIFs

     • thee or four GIFs playing per page = annoying distraction

     • even just one or two hyperactive GIFs = serious distraction

     • GIFs loop endlessly by default — I think most (all?) GIFs have an autoplay property. If so, distraction could be greatly reduced with autoplay = OFF. Alternately perhaps there’s loop Once parameter that stops the GIF after one iteration and displays a Play button.

     • currently in the MuseScore 4 Handbook we can’t pause or rewind most GIFs, so there’s no easy way to halt playback at particular point to examine a notational example, a menu, palette, dialog ... it all just wizzes by. Deeper scrutiny is inherently disallowed.

     • it's difficult to know if you're at the beginning, middle or end of the animation because there's no progress bar. Sometimes it's hard to know if a looping GIF is continuing with a depiction of a new and similar topic … or if it’s started over.

Recommendations

     • have GIFs appear like most videos do. Paused at the start with a visible internal play button, as shown in the attached GIF.

     • have GIFs play once and stop … with the option to restart

     • if the previous suggestions are not possible, then require that those submitting GIFs signify end of “recording” with a fade to black … or add one or two seconds of black screen at the end. Anything to prevent users from watching the loop three or four times before they realize. Editing GIFs is not necessarily simple, but I'd hope appending "fade to black" would be rather straight forward.

     • No option for sound or voice over

I’ll go out on a limb here with a couple of probably points:

1) Whether correct or not, let's make the assumptions that musicians are generally sensitive people, and that sensitive people are easily distracted.

2) Animated GIFs are distracting—otherwise advertisers wouldn't rely on them so heavily. And I think everyone knows this is true. The more MuseScore documentation includes autoplay animated GIFs the more difficult it will be to remain focused when reading the documentation.

3) Think of loop Once as an accessibility issue. There are certainly some of us who can't concentrate when sufficient animation plays continuously in the Handbook.

4) as an experiment:
      • open a second browser page of this post
      • start the animated GIF (attached below)
      • position the looping GIF as close to the first browser page as possible
      • try rereading this article (in the first browser page)

Hyperactive animated GIF.gif


Comments

Interestingly, this page on fingerings has animations that with autoplay OFF! Which is precisely what I've recommended. To my thinking the perfect parameters would be

     autoplay: OFF
     loop: OFF

At first, I thought, perhaps the animations were videos, but then I could see that indeed they are animated GIFs.

It appears the following steps can change a “Forever” looping GIF to a GIF that loops just “Once”:

     • Open the Animated GIF in Photoshop.
     • Go to the Window tab and select timeline (if the timeline is not already open).
     • At the bottom of the timeline panel, there’s a loop option set to “Forever
     • Change that to “Once

Sorry, I can’t test the described workflow. Since the advent of Adobe's subscription model I no longer have Photoshop installed.

If the loop parameter can invoke play-once GIFs, it would be wise to test to see if they play correctly from HTML in all major browsers. If they do, perhaps MuseScore’s head of documentation could green light conversions.

This could be a simple community project. Volunteers would need access to Photoshop (or something equally capable) and have the ability to replace the exisiting Handbook's Forever GIFs.

In reply to by scorster

It seems discussion of how clips are handled on musescore.org may not improve handbook anymore as handbook editing here is locked, and page contents will be edited and copied to a new gitbook. Should anyone find his way to regain editing rights on musescore.org hb, followings are some of my observations. Plugin and dev hb page editors on musescore.org may also find these points useful,

There were 3 ways to add clip/GIF onto a musescore.org page as of Nov2024

  1. Add gif with \ [ inline:...gif ]
  2. Add gif with \< img src="https://musescore.org/sites/...gif" \>
  3. Embed youtube video some kind of html code ...

Method 1 leads to a known frontend UI bug when there're multiple gifs - the hiding and showing of the play button and grey filter overlay often targets a wrong gif. Try interacting with gif below

Frontend UI hasn't been fixed. To avoid the bug, editors resort to method 2, which inevitably leads to unannounced playing and looping.

If every GIFs is to be updated from loop-playing into playing once only, it'd be useful if a piece of text is shown at the last frame (once finished playing) to remind readers it is not a static picture.

Method 3 embbeding has the best UX, it essentially includes youtube's proven player onto a page, along with the play/pause buttons and progress bar etc. It however requires web admin to restricting that page's editing rights (to vetted editors) bc of security concerns and thus used sparingly.

As for gifs/webm/embedding clips on the future gitbook. It uses iframely to embed content https://musescore.org/en/node/371579. AFAIK, Imgur among supported sites attaches play/pause buttons and progress bar to GIF automatically.

Hyperactive animated GIF.gif

In reply to by msfp

@msfp Thanks for your input here!

@msfp wrote >

> Method 1 leads to a known frontend UI bug when there're multiple gifs - the hiding and showing of the play button and grey filter overlay often targets a wrong gif.

I just noticed the "wrong target" issue just today while in the Handbook on finding a non-autoplay GIF.

> If every GIFs is to be updated from loop-playing into playing once only, it'd be useful if a piece of text is shown at the last frame (once finished playing) to remind readers it is not a static picture.

Doesn't a non-playing/paused GIF get a centered play button, just like most videos when paused?

While it's true that one can create single-play animated GIFs, or specify how many times a GIF should "loop" before stopping, such an approach doesn't seem practical in documentation. What about images that play once, and that can then can be replayed with a click or a tap?

AFAIK, SVG animation (see https://en.wikipedia.org/wiki/SVG_animation / https://www.w3schools.com/graphics/svg_animation.asp), which is part of HTML5, seems like a good candidate, as JavaScript still isn't universally trusted. SVG animations can be triggered to play, pause, and restart with a mouse click, or a tap on a mobile UI.

There are online tools (e.g. SVGator at https://www.svgator.com / Bannerboo at https://bannerboo.com) that let you create SVG animations without coding. They can also be used in PDF documents.

In this post, in Bradley's standard well spoken manner, he provides a description of development goals thru MuseScore Studio 5 … and beyond. And that is MUCH appreciated!!

Regarding animated GIFs

When Bradley speaks of copy-paste, he mentions the following improvement:

“… when copying a list selection of dynamics and pasting them somewhere else, the relative metrical positions of the dynamics will be retained.”

Then we see these two animated GIFs:

     https://musescore.org/sites/musescore.org/files/2024-12/before_copypast…

     https://musescore.org/sites/musescore.org/files/2024-12/after_copypaste…

I had to watch several times to conclude that the only differences are objects that appear under the lower staff after paste:

• the x position of the inner four objects (all but the p marks) most notably is the x pos, of the mf

• the y postion the initial p and hairpin, and also the mf

Matters would have been more apparent:

• if the video played the animation once and then stopped with last frame displayed and offering the option to watch again.

     — or —

• if the video played the animation, paused at the last frame, and then perhaps faded to black before repeating

Then it's relatively simple to understand the length of the video ... and the conclusion, as shown in the attached image.

Pasted dynamics positioning Sm.png

Do you still have an unanswered question? Please log in first to post your question.