...
Field | Data Type | Notes |
|---|---|---|
label | String | Human readable explanation of the field’s value |
identifier | String | The key value to use when storing this metadata in the metadata map |
dataType | Enum (String, Number, Boolean, Object) | The type of the value that can be entered under this key. If the data type is “object”, then the value must be another metadata entry definitions object describing that object (and this can recurse to any depth that is needed to describe the metadata). |
array | Boolean | false if this is a single value, or true if the type is an array of elements of the specified dataType. |
required | boolean | Are assessment authors required to supply this value if the node is typed with the given type? |
Note: the options you can select from when defining a multiple choice form field are technically metadata about that field, and those are complicated structures. They need to be represented here. They are an array of objectsThe most complex node type I can identify on the server is the MultiValueConstraints object. It has a list of SurveyQuestionOption objects which themselves reference an Image object. Obviously, we don’t want design tools to attempt a generic assessment node editor, but rather we want to tailor the authoring experience to known types. For types unknown to editing tools, the typeMetada field could be exposed as JSON. The server can still validate the content is valid.
A study design UI would need to allow for authoring and managing assessment types as well as assessments themselves (perhaps both can also be imported from the shared module library, though I would expect to clone all the default assessment types into each new study when it is created).
...