Hi, and welcome to dev.jamovi.org, the developer hub for jamovi.
Here you will find resources that cover the development of jamovi modules. jamovi modules are a way to develop and distribute additional analyses for jamovi (and R). This tutorial series has everything you need to get up and running.
There are forums available at forum.jamovi.org, so if you have questions about developing modules for jamovi, or feedback on how we can improve the developer hub, we’re keen to hear from you there.
contact <at> jamovi.org
For those interested in the jamovi platform, it is hosted on GitHub here. Don’t forget to ‘star’ us!
Tutorial: Getting Started
Come join us for the jamovi Module Workshop at Macquarie University in Sydney on October 31st. More info
In jamovi 0.9.1+ we have separated data type from measure type, allowing greater flexibility (take a look in the variable editor/setup to see how this works in practice). Variables now have a data type of either ‘Text’, ‘Integer’ or ‘Decimal’. As a consequence of these changes, the Nominal text measure type no longer exists, and the only legal values for the suggested supplier/target properties in the .yaml files are:
nominalordinalcontinuousAdditionally, permitted has been changed and may only contain the following values:
factornumericnumeric permits variables with data type Integer or Decimal. factor permits variables with measure type nominal and ordinal.
Note that you will also need to update the jas version in all .a.yaml files to '1.2' to work with the 0.9.1 series.
Just a heads-up, jamovi 0.9.1+ will no longer have the measurement type ‘Nominal text’. Each variable will have a data type (Integer, Decimal or Text) and a measurement type (Nominal, Ordinal, Continuous). This will only affect modules making use of the permitted and suggested supplier/target fields. The changes haven’t been finalized, but the adjustments to the new system will be quite trivial. This is just a heads-up!
jpower is a new Power analysis module, now available from the jamovi library.
Death Watch is a new Survival analysis module, now available from the jamovi library.
scatr is a new Scatterplot module, by Ravi Selker. Now available in the jamovi library.
MAJOR is a new Meta-analysis module, by Kyle Hamilton. Now available in the jamovi library.
GAMLj is a new linear models module, by Marcello Gallucci. Now available from the jamovi library.
In jamovi 0.7.5.2 we fixed the issue where changes to an analysis UI were not visible until jamovi had been closed down and restarted. Running jmvtools::install() will now refresh the analysis UI as well.
We’ve added a new document to our tutorial series describing how jamovi analyses can use state. State is used with longer running analyses, and allows the analysis to re-use results that were calculated previously. This can lead to much faster analyses, and a much nicer user experience.
Read more about state here.
We’ve just released a beta of jamovi 0.7.3 (available from here), which brings some significant improvements, and minor changes to developing jamovi modules.
In the past, we’re had a number of difficulties with dependency resolution for jamovi modules. Sometimes jmvtools would install more dependencies than were necessary, and other times not enough. This stemmed from contamination of the R library path, from R packages installed on the system. In this release we’ve successfully isolated the system libraries from the jmvtools, and only the required dependencies will now be installed.
Previously, .u.yaml files (the UI definition) were automatically generated from .a.yaml files (the analysis definition). This was sometimes problematic when additional changes were made to the .a.yaml files. It wasn’t always clear which changes should be propagated to the .u.yaml files, and which should not.
In the 0.7.3, the .a.yaml and .u.yaml files work together. The .u.yaml file, by default, contains minimal information (mostly just describing the layout), and the property values, for example labels, are taken directly from the .a.yaml file. For many people, they will only need to edit the .a.yaml file, and jmvtools can take care of the .u.yaml file itself. More documentation for UI Design will be coming soon.
.u.yaml files using this new scheme will have the jus, near the top of the file, specified as 2.0. .u.yaml files using the older jus of 1.0 will be automatically upgraded. Upgraded files will be placed in tame compilerMode (explained next), you may want to change it to aggressive.
compilerMode: aggressive vs tamejmvtools also introduces a new option in .u.yaml files: compilerMode. By default, .u.yaml files are created in aggressive mode. This means that jmvtools will take a heavy handed approach when updating the .u.yaml files. If new options are added to the .a.yaml file, it will aggressively add them into the .u.yaml file, overwriting any manual changes.
In contrast, the compilerMode of tame does not overwrite manual changes in the u.yaml. The trade off is that it often can’t position UI elements as optimally.
We recommend beginning with your .u.yaml files in aggressive compilerMode, and when you begin to refine your UI by adding custom changes to your .u.yaml files swap over to tame compilerMode so that your changes are preserved. Again, for a lot of people, aggressive mode will be all that they will ever need.
For the time being, changes to the .a.yaml and/or the .u.yaml files, will still require you to shut jamovi down and restart it before you’ll see the changes to the UI. We hope to fix this issue in the next few weeks.
On windows, jmvtools is still not able to find the jamovi installation by default. You will still need to pass the home option, or set the jamovi_home option.
jamovi 0.7.2.7 Adds dev mode, providing a stack trace when an analysis errors for whatever reason. The tutorial has been updated to describe this: Debugging an Analysis