Extending School survey entry - defining the survey contents.

Issue #107 closed
Brian Lewis repo owner created an issue

To cater for different survey structures, the school survey entry in the web needs to retrieve some 'metadata' that defines the content of the particular survey needed for a school type / year.

Comments (7)

  1. Brian Lewis reporter

    This issue has been addressed in the desktop Pineapples in recent years - introducing a 'dynamic survey' type that is defined by an xml file (below) . this is used in the AFrica sites but has not been retro-fitted to any Pacific site. The desktop program uses this information to construct a tabbed dialog that standard components to be loaded ( on request) , with the component configured according to the parameters it is passed in the xml.

    I believe the web version could do exactly the same thing, and if we use the same format for the file, we can leverage a lot of work already done. As well, if we build these layout definitions, they could be adopted in the desktop version as well.

    <SurveyFormLayout title="Somaliland PS Survey 2013">
      <Page id="1" component="cmptProfilePLEMIS" title="Profile">
        <Params />
      </Page>
      <Page id="2" component="PageCollection" title="Pupils">
        <Params>
          <Page id="2a.1" component="Enrolment" title="Enrolment 5-18">
            <Params tableDef="ENROL1" />
          </Page>
          <Page id="2a.2" component="Enrolment" title="Enrolment 19-30">
            <Params tableDef="ENROL2" />
          </Page>
          <Page id="2b" component="GridByGender" title="Boarders">
            <Params tableDef="BRD" />
          </Page>
          <Page id="2c.1" component="GridByGender" title="Repeaters">
            <Params tableDef="REP" />
          </Page>
          <Page id="2f" component="GridByGender" title="Transport">
            <Params tableDef="DISTTRANS" />
          </Page>
          <Page id="2g" component="GridByGender" title="Disabilities">
            <Params tableDef="DISABILITY" />
          </Page>
        </Params>
      </Page>
      <Page id="3" component="PageCollection" title="Teachers">
        <Params>
          <Page id="3a" component="TeacherList" title="Teachers">
            <Params />
          </Page>
          <Page id="3b" component="fsubClassListSomali" title="Classes">
            <Params />
          </Page>
        </Params>
      </Page>
      <Page id="4" component="PageCollection" title="Rooms">
        <Params>
          <Page id="4b" component="cmptSitePLEMIS" title="Site">
            <Params showHost="false" showFarm="false" showFarmU="false" />
          </Page>
          <Page id="4h.2" component="fsubRoomsAdmin" title="Recreation">
            <Params group="REC" columnSet="GROUNDS" />
          </Page>
          <Page id="4b" component="RoomList" title="School Building">
            <Params columnSet="SIMPLE" group="2013" />
          </Page>
          <Page id="4d" component="Classrooms" title="Classrooms">
            <Params sector="PRI" promptLevel="Y" levelItem="LEVEL" />
          </Page>
          <Page id="4g" component="Dormitories" title="Dorms">
            <Params />
          </Page>
        </Params>
      </Page>
      <Page id="4h" component="PageCollection" title="Facilities">
        <Params>
          <Page id="4h.1" component="fsubSchoolEquipment" title="Water">
            <Params category="Water Supply" />
          </Page>
          <Page id="4f.1" component="fsubToiletsSO" title="Toilets">
            <Params group="TOILETS" ynCaption="Water?" />
          </Page>
          <Page id="4f.2" component="fsubToiletsSO" title="Sanitation">
            <Params group="SANITATION" ynCaption="Used?" />
          </Page>
          <Page id="4h.2" component="fsubSchoolEquipmentFunctioning" title="Power">
            <Params category="Power Supply" />
          </Page>
          <Page id="4h.3" component="fsubSchoolEquipment" title="Disabled Facilities">
            <Params category="Disabled Facilities" />
          </Page>
          <Page id="4h.4" component="fsubRubbishCollection" title="Garbage Disposal">
            <Params />
          </Page>
          <Page id="4h.5" component="fsubRepairAndMaintenance" title="Repairs">
            <Params />
          </Page>
        </Params>
      </Page>
      <Page id="4i" component="PageCollection" title="Other Resources">
        <Params>
          <Page id="4i.1" component="fsubSchoolEquipmentFunctioning" title="Communications">
            <Params category="Communications" />
          </Page>
          <Page id="4i.2" component="fsubSchoolEquipmentFunctioning" title="Equipment">
            <Params category="Equipment" />
          </Page>
          <Page id="4i.3" component="ResourceList" title="Library Resources">
            <Params category="Library Resources" />
          </Page>
          <Page id="4i.6" component="GridByGender" title="Feeding">
            <Params tableDef="FEEDPROG" />
          </Page>
          <Page id="4i.7" component="ResourceList" title="Special Needs">
            <Params category="Special Needs Teaching" />
          </Page>
        </Params>
      </Page>
      <Page id="4j" component="PageCollection" title="Classroom Resources">
        <Params>
          <Page id="4j.1" component="fsubResourceSetThin" title="Text Books Lang">
            <Params item="Text Books" subjectList="LANG2013" />
          </Page>
          <Page id="4j.1" component="fsubResourceSet" title="Text Books Other">
            <Params item="Text Books" subjectList="CORE2013" />
          </Page>
          <Page id="4j.2" component="fsubResourceSet" title="Teacher Guides Lang">
            <Params item="Teacher Guides" subjectList="LANG2013" />
          </Page>
          <Page id="4j.2" component="fsubResourceSet" title="Teacher Guides Other">
            <Params item="Teacher Guides" subjectList="CORE2013" />
          </Page>
          <Page id="4j.3" component="fsubResourceSet" title="Readers Lang">
            <Params item="Readers" subjectList="LANG2013" />
          </Page>
          <Page id="4j.3" component="fsubResourceSet" title="Readers Other">
            <Params item="Readers" subjectList="CORE2013" />
          </Page>
          <Page id="4j.3" component="cmptSingleSSValue" title="Curriculum">
            <Params label="Curriculum used in your school" field="ssCurriculum" />
          </Page>
          <Page id="4k" component="fsubResourceSet" title="Other Lrn Resources">
            <Params item="Learning Resources" subjectList="LRNRES2013" adequate="Y" />
          </Page>
        </Params>
      </Page>
      <Page id="5a" component="PageCollection" title="Fees">
        <Params>
          <Page id="5a.1" component="Grid" title="Fees">
            <Params tableDef="FEES" />
          </Page>
          <Page id="5a.4" component="cmptManagementPLEMIS" title="CEC">
            <Params />
          </Page>
        </Params>
      </Page>
      <Page id="COMMENTS" component="cmptComments" title="Comments">
        <Params />
      </Page>
    </SurveyFormLayout>
    
  2. Brian Lewis reporter

    Suggested starting point:

    Note that the components Enrolment and GridbyGender are already implemented for the web and are in fact one and the same.

    Implement a means of returning this layout to the client, given the schno and year. This will need to find the school type for the school (in the year!) and lookup SurveyYearSchoolTypes and metaFormLayouts to get the layout data.

    Probably best to convert the Xml to Json to return to the client.

    2) On receipt of this data, the client page needs to construct a hierarchical UI somehow. Angular should happily nest ng-repeat iterating through the nodes of this layout.

    3) On selecting a terminal node - which points to a component, action somehow the loading of that component with its appropriate parameters. Note this may require some sophisticated Angular code to dynamically create a component reference, then $compile that code.

    We can begin with Enrolment and GridByGender which can can already invoke.

  3. Ghislain Hachey

    Would it not be possible to have a simple form to submit surveys? How much do surveys vary in "structure" (not just more or less fields)? Would something like angular-dynamic-forms ever become useful? An import tool would simply upload the eSurvey and populate the form which does the rest (validation, edits, etc.). As long as there remains a "master common ground" of fields in the surveys (if that makes sense) I think we could greatly simplify many things.

  4. Brian Lewis reporter

    @ghachey:

    a simple form to submit surveys?

    Depends what you mean by simple!

    The RMI 5 page census is adapted (and significantly cut down) from the Kiribati census for Primary. Kiribati has 3 census, Solomon Islands has 4. While there is plenty of structural congruences ( ie all these forms have a table of enrolment by age / gender / class level ), there is also lots of local variations. For the data in survey sections to be accessible in any useful way, sections are usually stored normalised into related tables. Even the 5 page RMI form will write to SchoolSurvey, Enrolment, PupilTables, Resources, Toilets, DistanceTransport.... and note that the categories of resources resources in each category, and types of toilets etc all vary from country to country. As of course do the names of class levels, official starting ages, number of years in each education level and so on. Trying to flatten this to one table would make any aggregation to all intents and purposes impossible.

    So the points at which we can get reuse are lower than the level of the survey - at the level of a configurable survey component, such as we have now with the GridByGender. This component uses metadata to determine the dimensions of the grid, and the code and display values for both rows and columns.

    However - the good news is that, if we can get this infrastructure in place in SI, and the SI form data entry largely built, that will get you a long way down the track for your next mission to RMI.

    Similarly with the eSurvey - Kiribati eSurvey is already in place, and if we can advance the Solomons eSurveys, you will be in a strong position to readily adapt these for RMI on your next RMI input.

    The RMI 9 week report is a different issue - it won't be stored as a survey, it certainly lends itself to a simpler interface and data model. I imagine we'll use a new table - and potentially hang this from the Inspections subsystem. This allows periodic data collections of various types.

  5. Ghislain Hachey

    While there remains a fair amount of polishing work to do with PDF eSurveys and the corresponding online UI I think the general direction is pretty clear and future issues should probably be broken down into smaller manageable pieces of work in their own respective issues.

  6. Log in to comment