jamovi: multi-file import and templates

tl;dr

In many areas, multiple data sets need to be combined before data can be analysed. An example of this is experimental data in the field of psychology, where a data file is produced for each participant. This blog post (actually a video), introduces multi-file import available in the 0.9.6 series of jamovi.

Additionally, I introduce jamovi templates; a way to save a set of analyses without any data. A template is analagous to a script file; when combined with a new data set, the analyses update and produce results for the new data.

V functions and multiple files

Most people are familiar with jamovi V or variable functions, such as VMEAN(). These functions work over a whole variable – so VMEAN() calculates the mean of all the values in a variable. However, when we import multiple files into the one data set, this may not be the appropriate behaviour. We may want to calculate a separate mean for each file we’ve imported. We can achieve this using the group_by argument. Specifying VMEAN(..., group_by=source) (where source is the name of the source column), produces a separate mean for each level of source.

It can also be important when using the Z() function with multiple imported files. It’s common to exclude responses that are, say, more than 3 standard deviations from the mean with a filter with a formula like -3 < Z(score) < 3. However, without a group_by argument, the z-scores will be calculated using the grand mean of all responses, from all participants, rather than just the mean for that participant. Here is the same formula with a group_by argument: -3 < Z(score, group_by=source) < 3.

labjs

This video demonstrates analysing data files from labjs by Felix Henninger. If you haven’t used labjs, it’s a free and open framework for designing surveys and computer presented experiments, and builder interface for desiging these tasks graphically.

One of the challenges of designing graphical software is what I call, the ‘feature cliff’. This is where as a user’s requirements increase, the amount of effort to achieve those goals can increase suddenly and dramatically. For example, you might be designing a simple survey, with a simple survey tool, when you realise you need to provide some more complex stimuli. If this goes beyond the survey tool’s capability, you might need to transition to an entirely different framework, which, although more capable, requires a lot more effort than what you were using before. The beauty of labjs, is that when you run into a hurdle, such as your task no longer being easily ammenable to the graphical builder, you can begin including code just for that part of the task. You don’t have to discard your experiment and start over. You can continue to use the graphical builder for most of the experiment, and only code the parts which need to be coded.

This is especially useful when working with less technically savvy colleagues. They can design the experiment with the graphical builder, and if they require a component to be coded, they can send me their experiment and I can add just the bit that they can’t do themselves. They still understand most of the experiment, and can continue to customise it without me – and I don’t need to take over the development and maintenance of their experiment myself (yay!).

So if you haven’t taken a look at labjs, I encourage you to do so.