Allow users to choose whether gifs (or videos in future) should run automatically

Feature Requests
1

Platform(s), such as mobile, website, API, other: Website

URLs (aka web addresses) of any pages, if relevant: Identify module

Description of need:
If I’m identifying and one of the observations on a page is moving it puts me on edge and I have to quickly go to the next page. I started a forum topic about it here:

https://forum.inaturalist.org/t/gif-observations-drive-me-crazy/74065

And found that I am not the only person who finds the movement a negative feature. However, there are others who love it, and want more, particularly wanting video observations. If there were substantially more moving observations, I would find Identifying a nightmare.

I wondered in that topic “it is possible for iNat to stop automatic playing of GIFs on the Identify page?” I don’t know if this is possible, but if it is, perhaps it could be made a personal choice?

Feature request details:
Allow users to choose if GIFS (or videos in future) should run automatically or not.

Add a section to the Settings, Content & Display, along the lines of:

Moving Observation settings

Do you want video or GIF observations to run automatically?

  • Yes, everywhere
  • Not in the Identify module
  • No, not on any pages

If it would be too complex to implement, I would be happy to just have the option to turn off automatic running in the Identify module.

Perhaps if people opted out of automatic movement, a “Play” option could be added to moving images to allow the user to choose to play an individual GIF (or video) if they desired?

2

i don’t think there’s a reliable, consistent way to prevent GIF animation in web code, unless you jump through a lot of hoops. if you want to prevent animation, some browsers allow users to adjust animation settings, or you can use an extension to stop animations. It may also be adjustable at an OS level.

staff have indicated that they have considered converting all GIFs to JPGs at some point. that would make the animation issue moot.

3

if they can identify them to convert them, why can they not identify them to skip over them in identify? not stop motion, skip over and not present.

multi-select for preferred media types…
sound only?
motion?
images?

only present the observations with the media types they prefer to id for.

4

That doesn’t seem like a viable solution if the only image is an animated gif - displaying nothing is obviously not acceptable.

5

i’m saying… don’t even show the observation in identify unless they’ve expressed interest in identifying observations with motion.

6

However it’s interpreted, I don’t think that kind of solution is acceptable. The existing filtering option for sounds is different, because it’s designed for users with identification skills that the majority of people don’t possess. By contrast, many users who identify primarily from photos certainly can and do want to identify observations with gifs - but only if they can control when the animation is played.

This is fundamentally an accessibilty issue. We don’t want to penalise a subset of users by hiding content from them (even if it’s controlled via personal preferences).

7

whether a gif was animated or not would have to be captured in the data model in order to do what you’re suggesting. that’s not a small change, especially if the preference of staff is to not have gif at all.

8

I wasn’t aware that sound had an entirely different flow based on the media type. It’s nice to know it’s possible.

9

The easiest option seems to just be to ask observers to put the GIF second. I really don’t think this is difficult, or a big ask. We are part of a community, and sometimes you have to sacrifice your personal ability to see GIFs whenever you like to enable other people to be more comfortable. This is absolutely an accessibility issue and if you don’t have the issue, then I don’t think you can dismiss it out of hand.

10

I mean, in my personal case, I’m just not going to upload gifs. I’ve only uploaded like two of them. I’m not going to go back and convert those because they’re from years ago. If they get converted or deleted, so be it (they’re a very small percentage of my observations overall). It’s hard to know how many gifs have been submitted by users who aren’t even active anymore. My main point is… there will be a conversion required at some point and that means there must be a way to identify them. updating the model might add some complexity (especially if they can’t use an existing flag like the one for sound if there is one), but either way there will be a conversion.

I think it’s a shame if there isn’t video support for the users who want it and if the only enhancement is a data conversion to remove gifs.

11

It seems unlikely that that will happen, unless there’s a drastic increase in the uploading of animated gifs (and enough users complained about it). Presumably, any enforced conversion would only happen if/when support for videos was implemented. In that scenario, it might even be possible to convert any legacy animated gifs to videos, rather than jpgs (although I’m unsure how feasible that would be).

12

I support this strongly from a web accessibility angle. WCAG guidelines Pause, Stop, Hide (Level A):

For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential

I have an extreme motion sensitivity and would not be able to review content if there are animated GIFs or autoplay videos showing up in my ID feed. Luckily I’ve seen that very rarely; I’ve really only seen it in cellular-level photos.

13

Maybe you could essentially “censor” GIFs (or videos if that ever happens). If people have the setting activated, some overlay that says “Content Hidden: GIF” with a button underneath it “show anyway” or something similar. Maybe it could be even paired with a trigger-warning feature (similarly censor photos of dead animals, human parasites, violence directed towards animals, etc. with the option to show the content anyway). I think I’ve read people express the need/wish for such a feature.

Though, overall, in the GIF-matter I still agree with this:

I think, the good thing about the GIF problem is that in most cases it won’t be casual iNat users who post them because it’s a bit of a work-around already and not possible from the app. So in most cases the person posting the GIF would probably have enough of an understanding of how the site and the community works. So they should in theory be responsive and understanding and adjust how they upload gifs. It’s basically just another point of iNat principles/etiquette that’s just learned after using the site for a while (like proper ID hygiene, when and how to tag people without becoming annoying, or what and how to upload good observations).

14

Animated GIFs are an unusual edge-case. The site doesn’t officially support them, so strictly speaking they’re currently little more than a hackish work-around for the lack of video-support. This implies that autoplaying GIFs isn’t a deliberate design choice: it’s simply whatever happens by default in accordance with the local browser and/or system settings.

If videos were ever supported, it’s likely they would have a simple user-controlled interface similar to what’s currently implemented for sounds. And just as with sounds, the videos wouldn’t start automatically - it would always require some form of voluntary user-interaction to do that (even if it’s just a mouse-over). The default state would always be to show a static frame from the video. This is how most video applications and video-sharing sites work, so it seems reasonable to expect that iNaturalist would work in a similar way.

Autoplaying animated GIFs is an accidentental feature with cosmetic benefits at best, and significant accessibility problems at worst. For people who are adversely affected, this isn’t merely a matter of personal preferrences, so I cannot see any moral justification for “censorship” in this particular case. Or at least, not unless it’s of the self-imposed kind implied by the requirement that animated GIFs should always be preceded by a static image.

Except that there currently aren’t any official guidelines that specifically apply to animated content and its potential accessibilty issues. Perhaps that’s all that’s really needed.

15

@pisum: How feasible do you feel the following approach might be?

  1. Update the data model to record the presence of animated GIFs
  2. Crawl all 360m+ existing observations to detect whether the first photo is an animated GIF.
  3. When an animated GIF is found, create a single-frame preview and set a field on the observation. (The existing image processing logic appears to create large, medium, small and thumbnail versions of each image. This would just be one more image version for a small minority of images.)
  4. Add a user preference to allow/suppress auto-play of animated GIFs.
  5. Update Identify page to show the single-frame preview instead of the animated GIF for users who choose to suppress them.
16

what you’re describing is more or less what i would think is the correct approach technically, but the effort to do that probably greatly outweighs the potential benefit. as i said before, it’s not a small change. i would think that if staff were going to do anything to address gifs, they would just convert them all to jpeg and call it a day.

17

The resources required to implement and maintain all that would be far better spent on providing support for videos and removing the existing support for gifs.

18

I also think the best solution to this would be to just convert all gifs and be done with it. It seems like this has been considered for years, though I get that it wouldn’t be a priority either!