The negative effects of animated GIFs in MuseScore's Handbook
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)
Comments
edit: removed irrelevant points related to (market) positioning and content presentation.
Apparently I missed the new announcement https://musescore.org/en/node/371579, hb is moving to gitbook. Public pages editing rights here are since removed.
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 It appears the following… 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
\ [ inline:...gif ]
\< img src="https://musescore.org/sites/...gif" \>
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.
In reply to It seems discussion of how… 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?
In reply to @msfp wrote > > Method 1… by scorster
> centered play button
Honestly, I've no idea. Let's try it out. Result below loop count = 1 using https://ezgif.com/loop-count
In reply to > centered play button… by msfp
Yes, play button reappears when I place mouse cursor inside.
Interesting. I have no problem with the GIF's. Have others said that they do?