Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Rubrics at each criteria

Code Block
{
  "nameObservation": "Availability{
of School Leadership",   "descriptionlevels": "Availability{
 of School Leadership",   "typeL1": "auto",{
  "levels": {     "L1label": {"Below Average"
     "level": "L1" },
      "labelL2": "Level 1",{
        "descriptionlabel": "Average"
      },
      "L2L3": {
        "levellabel": "L2Good",
      "label": "Level 2",}
    }
    "description": ""
    },
    "L3": {
      "level": "L3",
      "label": "Level 3",
      "description": ""
    },
    "L4": {
      "level": "L4",
      "label": "Level 4",
      "description": ""
    }
  }
}

Behaviour:

...

Creator will see the framework hierarchical structure of domain & criteria for the first time, when creation of observation begins.

...

Once the observation is created, the taxonomy structure will be copied to the observation and same will be shown to the user from next loading of editor.

...

}
}

Behaviour:

  • Creator will see the framework hierarchical structure of domain & criteria for the first time, when creation of observation begins.

  • Once the observation is created, the taxonomy structure will be copied to the observation and same will be shown to the user from next loading of editor.

  • Label and some additional information (description, keywords, etc) can be updated by creator for the copied taxonomy structure.

Recommended Approach:

QuestionSet will have the hierarchy as usual. For Observation with rubrics, the editor will auto-create the question-set hierarchy using the framework structure.

The editor (or the question set category - Observation with Rubric) should use a config to specify the list of framework categories that are to be used to create the hierarchy.

Once the hierarchy is created, the editor shall not allow editing the structure of the hierarchy (i.e. the folders).

Regarding the pagination structure, lets add a new attribute “rendering_sequence” to the question_set object. This attribute has the following structure:

Code Block
languagejson
 {
   "name": "name of the view, could be defaulted to the attribute used to group the questions, e.g.: ecm, criteria, score, etc",
   "sequence": [
     { // one entry per section, one section may contain multiple pages
       "value": "attribute value, e.g.: ecm-1, criteria-1, etc",
       "name": "human readable name for the section, same as the attribute value by default",
       "pages": [["list of question ids in page 1"], ["questions in page 2"]],
       "index": 0
     }
   ]
 }
  • No partial updates are allowed for rendering_sequence. The complete sequence will be overridden on update.

  • Platform will not validate the rendering_sequence. I.e, if the rendering_sequence has a question_id that doesn’t exist in the hierarchy, API will still update the value.

  • Old players which do not understand rendering_sequence can fall back to use the default hierarchy.

  • If the rendering_sequence has invalid data, player can choose to skip the question, fail the rendering of the question set or fall back to use the default hierarchy.

Rubrics should be defined on the sections of the original hierarchy using the outcome_declaration attribute (should have the same structure as response_declaration of questions).

Open Item: should Observations with rubric be a new primary category or a new object type? It depends on the PRD:

- if the editor workflow is generalised enough to embed in the question set editor or not

- if the behaviours like rendering_sequence and rubrics are applicable for any question set or not