This page draws together in one place the technical information you should be aware of before starting to run your study on Gorilla. It covers supported file types, guidance on maximum file sizes, and ways to ensure your participants are able to complete the experiment, whatever device or browser they are using. This information should help you to avoid many known issues when running your experiment.
By far the best way to avoid these issues is to preview and thoroughly test your experiment before recruiting participants. Preview the experiment across different devices and browsers; preview all conditions of your experiment, and download and check the data from each preview to make sure everything is recording as you intended. Recruit a few friends to do the experiment as 'real' participants to spot any issues that might only appear once the experiment goes live.
We do the best we can to make sure all important information is accessible on our support pages, but there is no substitute for thorough testing of your specific study!
When uploading your spreadsheet(s) and stimuli, using the file types listed below will help to ensure your experiment runs smoothly.
For spreadsheets, Gorilla supports the following file types:
.csv, .xlsx, .ods
For stimuli, we strongly recommend using the file types that are most widely supported by all browsers. These are:
Images: .png, .jpg,, .jpeg, .gif
Please Note: we do not recommend the use of non-repeating GIFs.
Audio: .mp3, .ogg
Please Note: Safari browser only offers partial support for .ogg files (and some older versions of Safari don't support ogg at all).
Video: .mp4
Please Note: older .mp4 files with out-of-date encoding can cause issues. Handbrake is an open-source tool that can be used to convert older video files to a modern, widely supported format.
If your audio and video files are currently in a different format (e.g., .wav or .mov), we strongly recommend you convert them to one of the recommended formats listed above before uploading them to Gorilla. For audio, Audacity is an open-source tool that you can use to convert files to .mp3. For video, Handbrake or VLC Player are open-source tools that you can use to convert files to .mp4.
We recommend that the size of spreadsheet and stimuli files be kept as small as possible to ensure smooth running of experiments and minimise pre-loading delays. Specific guidelines will vary depending on how many stimuli you have in your task, but in general, we advise the following:
If you have very few stimuli in your task, it may be less of a problem to have one or two files that are larger than these constraints. Conversely, if you have very many stimuli in your task, you may need to reduce the size of each individual file further.
To reduce the size of image files, you can use Squoosh or your preferred image editing software. For audio, Audacity is an open-source tool that includes the option to compress files. For video, Handbrake or VLC Player also offer this option.
Handbrake can be a tricky bit of software to get your head around. We've put together a tutorial that we've found covers the most useful features (with a bit of trial and error) when you're trying to compress video files without compromising on quality.
Once you've downloaded and installed Handbrake, open the software and select 'File - Open a single video file' and navigate to the video you want to compress. If you've got a lot of video stimuli to compress, it's useful to play around with the settings for one video first before you go ahead and compress them all. Once the video is in Handbrake, try the steps below. You can leave all other settings as the defaults unless you know what you're doing with them.
Summary tab:
Audio tab:
Subtitles tab:
Chapters tab:
Video tab:
This tab is where a bit of trial and error comes in. On the Quality slider, a lower number means higher quality and a bigger file size. You'll need to get the balance right depending on your own stimuli, how you want it to look, how big the original file is, and the display size. The larger the display size of the video, the more noticeable any imperfections will be.
The 'Encoder Preset' slider is a setting you'll want to change at different points in your compression journey! Essentially, this slider changes how long it will take to process your file and give you a newer, compressed, version once you've finished altering all the settings. If you're just trialling out the quality setting above, you'll probably want to start off with it set to one of the faster settings. Making it faster (moving the slider to the left) means it will be finished processing quicker but it may not be as compressed or high quality as it could be. Make it slower (moving the slider to the right) means that it will take longer but will be better compressed. A faster setting is good whilst you're getting a feel for the results because the file can be processed quickly even on less powerful devices. But when you're happy with the settings and are running it for the final time, you'll want to go for the slowest (to the right) setting. Then, Handbrake will take its time processing your video but ensure better results.
Moment of truth!
This wil start the process of creating a new video based on all your settings. By default it will save in the same folder as your original video, but you can change this and the file name at the very bottom of the screen before you start encoding.
If you're happy with the quality but not the file size, go back to the Video tab and try increasing the RF again (move the slider to the left). Repeat 'Start Encode'.
If you're happy with the file size but not the quality, go back to the Video tab and try decreasing the RF a little (move the slider back to the right). Repeat 'Start Encode'.
Repeat the process until you're happy with the quality and the file size. Make a note of the settings you used just in case! You can then repeat the process with all of your video files, but remember to change the 'Encoder preset' setting to be slower.
If you want to play sound or video to your participants there are some extra steps you may have to consider. Autoplay was disabled by default in all major browsers as of 2018, and this is still the case at the time of writing in 2023. There are ways around it, but it's difficult to guarantee a solution.
If your participants play each audio or video file by clicking on something, such as the in-built 'Play' button, or by using Click Response with a Trigger - Active component, then you should be fine.
If your participants play each audio or video file by interacting with the keyboard, such as pressing SPACE or ENTER to move to a new trial and having the media autoplay, or by combining a Keyboard Response component with Trigger - Active to start the media, or by not interacting at all, for example if you move your trials along with a Time Limit, then you need to take extra steps (see 'Solutions' below).
As of 2023 - and has been the case since 2018 - all the major browsers prevent autoplaying of audio files and video files with an audio track (hereafter referred to as audio-visual media) by default. Videos without an audio track, or with their audio track muted, will be allowed to autoplay. If a muted video is unmuted (and was autoplayed initially) it will immediately stop.
In all major browsers, your participants will need to provide a 'direct interaction' to trigger audio-visual media to play. The most reliable way to force this direct interaction in a Gorilla task is through a mouse-click to start the audio-visual media (such as the Play button), as a keyboard interaction doesn't have the same effect unfortunately.
The mouse-click may then enable autoplay for future audio-visual media for that participant on Gorilla without the need for another direct interaction from the participant. For example if you wanted to use autoplay to control sound, or video with sound, throughout your task and therefore having frequent mouse clicks would disrupt the timing, you could try having an example video at the beginning in your instructions which requires the participant to click 'Play' with their mouse. Again, this is not guaranteed to unlock autoplay, but it can signal to the browser that the participant has chosen to interact with Gorilla before and therefore would be happy to hear audio from the site in future.
If the participant refreshes the page, or you have a longitudinal design which means they leave the experiment and come back later, the autoplay will be revoked again. It's therefore worth having a mouse click at the beginning of every task to unlock the ability to autoplay audio-visual media again for later sessions in multi-part studies.
1) At Gorilla we've made autoplay of audio much more reliable because we've hidden a silent audio track in our systems so that any time a participant uses a left mouse button click, it secretly triggers the silent audio to play! This doesn't affect the participant or your task at all, and the browser doesn't know it's silent, it just knows that it's an audio file. This reduces the burden on you as a researcher to try and engineer a situation where a participant plays audio with a mouse click at some point just to unlock autoplay. All you need to do is make sure there's a mouse click somewhere at the beginning of your task, such as a Continue button, as this will trigger our secret silent audio track and hopefully unlock autoplay. Importantly, this trick we use only works for audio and unfortunately doesn't work for video stimuli with an audio track.
2) In Task Builder 2 we've introduced subsystems for setting up sound (and audio/video recording). If you have audio or video with an audio track in your task, your participant will automatically be prompted to press 'Play' on our own audio track (a voice saying "1, 2, 3") before your task starts so that they can test their volume, which may then unlock autoplay for the rest of your task.
3) The safest way to have your participants hear audio and see videos with audio tracks is simply to have them press the 'Play' button with a mouse click on each trial. We understand though that it may not always be possible to work that into your protocol, for example if you want to control timing or if participants should be poised on the keyboard and therefore not switching between mouse and keyboard constantly! In that case, trying solution number 4) or 5) are your next best bets.
4) Create a situation in the instructions of your task where your participant has to press 'Play' with a mouse click on one piece of audio or video with an audio track. For example, to show them the type of stimuli they'll be seeing. This may unlock autoplay on Gorilla for that participant.
5) To unlock autoplay for video either use videos without an audio track or with the audio track muted, or include at least one manually played video prior to any autoplayed videos.
NB: Remember that in most cases if your participant refreshes the page, or if you're doing a multi-part/longitudinal study, any autoplay permissions will then be revoked until it's triggered by another mouse click.
Why did you make this change?
We didn't, the browser vendors did (e.g. Google, Apple, Microsoft, Opera...and more) and we were powerless to prevent it. Why did they make this change? To improve the overall user experience by preventing media/ad platforms from playing audio-visual media, without prompting, requiring the user to scour the site for where the blasted audio is coming from. Hurrah for user experience, RIP behavioural research.
Why do you keep using the word MAY?
If the participant has requested that their browser never allow audio-visual media to autoplayed then, regardless of what we or anyone else does, autoplaying will not be allowed, period! The default browser behaviour is to allow it after an interaction (as described above) but we are powerless in the case where a participant has changed the default settings on their device.
Can you detect if audio-visual media failed to play because of autoplay restrictions?
In theory, yes. In practice, not reliably. The documentation from the various browser vendors would suggest that it should be possible. Practical experimentation suggests that this documentation and the "rules" it describes aren't actually followed reliably. It's an area we are continuing to investigate/work on - we hope to be able to implement a cross-browser solution eventually.
Why do websites that I frequently visit have autoplaying audio-visual media?
Because you frequently visit them. The browser vendors build up a profile of your behaviour and, if you interact with audio-visual media enough times, it will assume that you're okay with audio-visual media being played and will allow autoplaying.
By default, participants will be able to access your experiment from any internet-enabled device (including desktops, laptops, tablets and mobile phones).
We recommend you thoroughly preview and test your experiment on any device you are planning to let participants use. In Task Builder 2, within the Screen Preview panel, you can preview what this screen will look like on a large monitor, small monitor, laptop, tablet and mobile devices. You can also use the Toggle button to switch between portrait and landscape preview. There is some further information about this in our How To guide. To improve the Layout of your tasks across different devices, you may consider using our Customisation Layout settings.
In Questionnaire Builder 2, within the Page Preview, you can preview what your questionnaire page will look like on a desktop/laptop and mobile devices.
If you know your experiment does not work well on a particular device type, you can prevent participants from accessing the experiment on this type of device by setting Requirements on the Recruitment tab of your experiment.
Note that device type checks are not infallible - in particular, modern Apple devices such as iPhones and iPads are able to identify themselves as computers. As such, if you need to exclude participants who are using a particular device type, we highly recommend that you also directly ask participants within the experiment what device they are using, and use a Branch Node to reject participants or send them on to your task on the basis of their answer.
If a participant using a mobile clicks your experiment link from within a mobile app (such as Facebook or Twitter), the experiment may open within the app, rather than in a full browser such as Safari or Chrome. This may prevent them from completing the experiment. If you are recruiting participants who will be using mobiles, we strongly recommend that you instruct them to copy and paste the link into their browser, rather than clicking it.
If your task requires a keyboard response, then we recommend restricting the device types for your experiment to stop participants from using mobile devices. This is because the phone keyboard would need to pop up and down on each screen and obscures the screen and may affect reaction times.
Watch the video below to learn how the Developer Tools in Chrome can be used to help view how your experiment may appear on different devices:
We also have built-in mobile device preview options in Questionnaire Builder 2 and Task Builder 2.
By default, participants will be able to access your experiment from any browser.
For most simple experiments, the browser will not make a significant difference to participants' experience. However, if your experiment is more complex or you are using cutting-edge features, you may want to preview and test your experiment across multiple browsers. If you find that your experiment does not work well on a particular browser, you can prevent participants from accessing the experiment in this browser by setting Requirements on the Recruitment tab of your experiment.
If a participant using a mobile clicks your experiment link from within a mobile app (such as Facebook or Twitter), the experiment may open within the app, rather than in a full browser such as Safari or Chrome. This may prevent them from completing the experiment. If you are recruiting participants who will be using mobiles, we strongly recommend that you instruct them to copy and paste the link into their browser, rather than clicking it.
Participants in your experiment may have varying connection speeds. Gorilla's lookahead system, which downloads all stimuli for a trial before the trial starts, is designed to account for this: a participant's connection speed will not affect the accuracy of their measured reaction time.
However, if a participant's connection speed is slow and the experiment includes a lot of stimuli, very large stimuli files, or a combination of both, they may experience pauses between trials while these stimuli are loaded. The best way to solve this problem is to reduce the size of stimuli files to make them as small as possible - see the File Sizes section for more information.
You also have the option of preventing participants whose connection speed is below a certain level from accessing your experiment. You can do this by setting Requirements on the Recruitment tab of your experiment.
If a participant using a mobile clicks your experiment link from within a mobile app (such as Facebook or Twitter), the experiment may open within the app, rather than in a full browser such as Safari or Chrome. This may prevent them from completing the experiment. If you are recruiting participants who will be using mobiles, we strongly recommend that you instruct them to copy and paste the link into their browser, rather than clicking it.
Participants should be able to take part in studies hosted on Gorilla from anywhere in the world, as long as they have an internet connection and a browser. However, there are a couple of factors that might affect a participant's experience depending on which country they are located in:
The effect of both of these factors will be more pronounced for experiments that include many large stimuli files such as videos.
