Data export - metadata?
First - I really am loving JATOS. It's made my life trying to organize and run experiments online so much easier. There are a few "wish list" features I'd love to see that would help considerably. The first is to be able to export the metadata that JATOS has for each experiment stage. JATOS keeps track of things like when each phase began, ended, duration, exit codes, etc. and we can see that in the JATOS interface just fine. But, I can't see any way to export it. If that could be included in the data that comes out when we do an Export Results, we'd have a consistent way of knowing this.
Take, as an example of the problem, a researcher running several tasks in subjects and they run the whole experiment multiple times. Said researcher might have not done an awesome job at exporting date stamps into the results field all the time and is now trying to reconstruct exact timelines. In the big exported text files, subjects come out in reverse chronological order but within a subject, things are in chronological order. If there were issues, there's no consistent way of knowing this in the exported data. None of this is impossible to work with, but if the export results included not only the data you posted but also JATOS_StartTime, JATOS_EndTime, etc. external programs could nicely have access to what is currently tied to the web interface.
(A second wish-list item is for a more convenient way of accessing parameters. Right now, I may pass in variables via URL, studyJson, componentJson, etc. and have to check each possible location manually. This one, though, I'll likely just write myself.)
Craig
Comments
Hi Craig!
Nice to hear you like JATOS. And thank you for your feedback and feature wishes. We really need this type of feedback to learn what people need in JATOS.
Now to your main wish: exporting meta data. JATOS does have the possibility to export meta data already: there is a button for it in every result page: http://www.jatos.org/Manage-Results.html#export-metadata-jatos-version--331. But I have to admit this was added in a hurry and it can be improved. Right now it just exports the meta data in its own file. And the actual result data are exported into another file. The ordering in both files is the same, that means you can map line 1 of the meta data to the result data in line 1 etc. Although this probably fulfills your needs it would be nice to have both meta and result data exported to one file, e.g. in JSON format:
{ 0: { "metaData": ..., "resultData": ...}, 1: ... }This is already on the feature list we want to implement in the future.
Then for your second wish:
A second wish-list item is for a more convenient way of accessing parameters. Right now, I may pass in variables via URL, studyJson, componentJson, etc. and have to check each possible location manually. This one, though, I'll likely just write myself.
Here I'm a bit lost and I don't understand what you'd like to have. Is it some kind of unified way of accessing URL query parameters, studyJsonInput, componentJsonInput, and batchJsonInput? But what if they have the same parameter names? They would overwrite each other. Can you explain more?
Best,
Kristian
Yea - the linking is the key in that you're 100% sure they're tied and such. In addition, the basic metadata export there is at the level of entire experiment rather than at the level of each component. But, it's nonetheless a good thing to have and if I at least make sure to embed the worker-ID (rather than the ID that comes in via the URL in our system), I'll have that to decode.
The second bit is perhaps unique to my setup. I've got various tasks that get run in an experiment and I use a setup.html main page to define the counter-balancing, conditions, etc. for an individual run. Let's take a simple example -- should the participant respond via keyboard or buttons? It'd be a shame to really have two separate programs for this simple difference, so I have a mytask.html that runs the task in either way, checking for some resp variable's value. What can set that? Well, it'll have a default, but it might be nice at the top level of an experiment to define this behavior, or at least the default. So, in the Properties for the experiment I might have "resp": "buttons" or some such thing and then I'd find it in jatos.studyJsonInput. But, of course, we like flexibility and might want to run some tasks with buttons and some with keyboard responses or to even run it both ways in one experiment. So, maybe we have two components of the same study that point to the same mytask.html file and in their Properties, we might have a "resp": "buttons" in there and access it via jatos.componentJsonInput. Then again, based on what someone did in the experiment, we might want to change this, so we'd set something in our nice "share across components" spot of jatos.StudySessionData. Heck, while we're here, I get things passed in from our experiment system as URL variables, so maybe we also check jatos.urlQueryParameters.
Upshot - the flexibility of being able to specify parameters at many levels is great, but it does mean that as I try to future-proof code and set it up to be flexible to let people nicely configure experiments with task-code, I end up doing a lot of checking each one by one like:
var myparam=''; if (typeof jatos.studySessionData['myparam'] !== 'undefined') { myparam=jatos.studySessionData['myparam']; } if (jatos.componentJsonInput && typeof jatos.componentJsonInput['myparam'] !== 'undefined') { myparam=jatos.componentJsonInput['myparam']; } ...It seems like you expect your study to be used by others and you try to anticipate where they would set input parameters. Usually people program a study for themselves or their team and don't try to make it fool-proof - they just try to get it to work :).
But do you have an idea in how to change the many different inputs into a more unified input that you can use to query all at once. I mean I could provide some function that takes a parameter name and then looks one after another in the different inputs and returns the value of the first match. But somehow I suspect people would get confused about where their parameter actually come from (especially if you have parameters with the same name in different inputs). E.g. we have a parameter 'foo' in the studyJsonInput and the componentJsonInput: which one is read out? We could define a priority here: urlQueryParameters would have the highest prio, then componentJsonInput, then studyJsonInput, then batchJsonInput. I would leave out the three sessions (study, batch, group) since they have a slightly different purpose (inter-study or inter-component communication) and are writeable. What do you think?