This morning, my students told me: “We expected problems in our eye-tracking research, but not ones that made our study impossible.” There’s nothing like the frustration that comes when a tool doesn’t work in the way you hoped.

Those students are in the first semester of a two-year research master program that develops their research skills in educational sciences, and I’m working with them to develop and pilot an eye-tracking experiment. A key goal is for them to encounter and solve problems—if they’ve learned that eye-tracking research isn’t easy, that means I’ve done my job. I warn them upfront: problems are part of the process and that is what you learn from. I have, more than once, been in situations where students found out they hadn’t collected the right type of data or that their idea wasn’t possible with the tools that they had selected.

Researchers new to the field of eye tracking might not understand what is needed from a tool and can struggle to find tools that match their needs. Thinking through your needs for a tool, and figuring out the affordances of tools is central in eye-tracking research.

Diederick Niehorster and colleagues provide a very good starting point for that in their paper: The fundamentals of eye tracking part 4: Tools for conducting an eye-tracking study. In particular, I appreciate this paper’s overview of problem domains; it should save the readers a headache or two. For example, one student recently suggested using well-known questionnaire software for doing an eye-tracking study. She didn’t realize that a plugin or control library is necessary to start and stop data acquisition, to record the data, and to link the data to the stimulus and that these aren’t available in the software she had in mind. Another student used MATLAB for data collection but forgot to include annotations for the start and end of each trial so she couldn’t use the first eight datasets that she had collected as gaze could not be mapped to the right stimulus.

If you use software suites, you may not have to bother with these steps and may not run into the same errors. These programs are user-friendly, and, with some good instincts, you can start data collection within half an hour of being introduced to a software program. A very central problem of (commercial) software suites is that, because they aim to make designing experiments and analyzing data easy, they are often limited in their abilities. As researchers, we explore uncharted territory, we’re doing things that haven’t been done before. You can get pretty far with software suites, but it is not uncommon that you need options beyond the capabilities of the software: More complex randomization, options to interact with stimuli, visualizations that are slightly different from the options of the software, or more complex measures.

I experienced this first-hand when working on research in which I investigated whether gaze displays could be shown to learners as feedback. I used the gaze visualization options of the SMI program BeGaze in this study but needed the gaze feedback to be tailored to my study in the next project.

While companies try to keep up with the needs of researchers, it’s in our nature as researchers to want more, and we thus need specialized tools. Because of the benefits that come with specialized tools, the paper offers a good argument for developing programming skills. Being an applied researcher, I have limited programming experience, but I taught myself a thing or two about programming in a few languages, and I noticed that it has important benefits. Often, what you want to do is slightly different from the application that the developers designed the tool for: We’re researchers, so we do new things. In that case, it is very helpful to understand the code well enough to be able to tweak it. Programming skills can also increase one’s understanding of which settings and formats to choose and how to debug errors. Example data, open source code, and user documentation often still require that you have some programming skills: It is not always easy to get tools to work, and programming skills might help you understand what happens under the bonnet, and how you need to use it. If your needs go beyond what you can do with your programming skills, collaborating with researchers who have those skills is a good option, but even then it helps if you have some programming skills, as it will also help you explain your ideas in clear language.

Selecting the right tools for your research project is always going to be a task that requires time and effort, but the paper The fundamentals of eye tracking part 4: Tools for conducting an eye tracking study makes it a bit easier to do this. I recommend that you start your project by writing a clear description of what you need the tools to do. I derived a list of questions from the overview of problem domains, which could serve as a starting point for writing down all needs. You can then write down the software and hardware tools you have available and the skills in your arsenal, and use that for selecting potentially useful tools. The list of indicators of good tools will be the next useful resource for selecting tools to try out. Good eye-tracking research is not easy, but preparing well and using the right tools can make a big difference.

Here is a list of questions that you can ask yourself to help you decide which tools you need:

Featured Psychonomic Society article

Niehorster, D.C., Nyström, M., Hessels, R.S., Andersson, R., Benjamins, J. S., Witzner Hansen, D., & Hooge, I. T. C. (2025). The fundamentals of eye tracking part 4: Tools for conducting an eye tracking study. Behav Res 57, 46. https://doi.org/10.3758/s13428-024-02529-7