Studies settings

[peichins]

The studies model needs a field to store settings for the study. Probably this should be a JSON blob.

This information dictates how the client displays the citizen science page. Currently there are slightly different layouts for different use cases: Citizen science study and Verification study

The current client shows more metadata for the verification studies, including:

• progress through the entire dataset,
• the date or time of the segment (we may want to change this later)
• the site name

We currently don't have a way to indicate which of these two types a study is. As it stands a simple flag for 'verification' or 'citizen science' would suffice, but for future flexibility it would be better allow a freeform json blob. In that case, we could set values for each of those metadata individually (e.g. some citizen science studies may want to show the time of day of an audio clip).

In addition, we also need to be able to specify a "Title" for the study. There is already a "name" field, however this has been overloaded as a kind of textual identifier used in the URL, which is not ideal as we may want a different title than to the string in the URL. This title could also be included in the "settings" json metadata.

[atruskie]

Priority?

We've got a more genral CMS concept waiting which I think we'll tie to a study. That'll allow it to have a blurb, title, image assets and the like.

As for the study type: isn't this information actually related to the type of question that is being asked?
We designed this so that different questions could be displayed differently, with different UX components. So, a verification question should show those extra components, and other questions should show... what they want.

If there's only one question in a study, then nothing changes between subjects (dataset_items).

Thoughts?

[peichins]

Agree that title will be better in a cms system with other things that are currently hacked into landing page static files.

Regarding the presentation settings being encoded in the question JSON:

The structure of the question being asked does affect the presentation of the question. For example, the presence of example events, the number of classes etc. However, these are not necessarily tied to the presentation of the metadata of the audio clip. E.g. a simple yes/no question identical to the koala verification situation might be applied to a future citizen science study where it's not desirable to show site information.

We could probably change things so that the schema of the Question JSON includes extra fields for information on the presentation of the audio metadata, but I don't think this is a good idea for two reasons

• Firstly, although not quite functional in the client yet, in theory we will be able to have multiple questions per audio clip. Moreover, we allow questions to be shared between different studies through a HABTM relationship. It's conceptually wrong to have the audio metadata presentation settings in the question. It's the study
• Secondly, I think it would involve a much bigger change to the client to pass this information around between components. E.g. currently question information is retrieved in a different part of the application at a different time than the study information.

About storing individual presentation settings vs two alternative sets of settings:

We can either allow the curator of curator of the study to
a) label the study as either verification or citizen science, to determine whether all the metadata is displayed or not (e.g. through a boolean on the study model (or maybe enum for future 'types' of study)), or
b) set settings for each of the metadata preferences individually, e,g, though JSON blob in the study model.

• (a) option is less flexible than (b) (e.g. we may want time information shown for some citizen science studies).
• But, (b) kind of mixes presentation information in the database. Although this does not feel quite right, i'm not sure how big a deal it is.
• In a way (b) might be easier for modifying the UI without having to update existing settings (e.g. adding a different UI component that should be applied to all verification studies only).
• (b) would be easier to implement and maintain. It's much closer to the existing hacked solution that we currently have which is to add the word "verification" to the name of verification studies.

[atruskie]

CMS added in #493 which may be useful for this