animated GIFs are suboptimal for documentation, including README

[TallTed]

For example, this gif in the README.md.

The longer the display period, the less optimal a GIF is.

Yes, they can be quick and easy for the producer to make, but there are often significant prices paid by the consumer.

Most obviously, there's no pause, rewind, nor fast-forward... Which means that one has to watch from the start, no matter what segment they're trying to re-view. It's also impossible to know where you are in the animation, so it's not possible to simply restart, nor even to "watch for the restart" — unless the creator of the GIF inserts several key frames at start and/or end, which the viewer can watch for once (if) they notice they exist.

I suggest converting any such animated GIFs to MPEG-4/MP4 using H.264 (optimally, as it appears to be universally supported by current browsers and OS) or HTML5/WebM (suboptimally, as it appears to be not-quite-universally supported, though this is continuing to change for the better), for both of which there are a number of online and local converters, many of which are free of charge.

Adding some voice-over that describes what's being shown would also be a good thing for accessibility (a11y), as the current silent animations cannot be consumed well if at all by anyone with visual impairments.

[melvincarvalho]

Thank you for the suggestion to enhance the project's README.md with MPEG-4/MP4 or HTML5/WebM formats. The focus on improving accessibility, particularly with the addition of voice-overs for visually impaired users, is an important aspect to consider.

One aspect to consider, however, is the potential impact on file sizes and loading times. Video files, especially those with audio, are typically larger than GIFs. This could result in longer loading times for the README.md, and might be challenging for users with slower internet connections or limited bandwidth. This is also a concern for mobile users and those on metered data plans, where larger files could be problematic.

Additionally, incorporating larger video files could significantly increase the overall size of the git repository. This might affect cloning and fetching efficiency, particularly for those with limited storage or slower internet speeds.

An alternative could be to continue using GIFs due to their lower data requirements and simplicity, but perhaps enhance their accessibility with detailed text descriptions. This approach could balance accessibility needs with practical considerations for a wide range of users.

Open to further discussion on this, and additional ideas or suggestions are always welcome. Striving to make the project inclusive and user-friendly is a commendable goal, and contributions like yours are important in shaping its direction.