School Report Card - implemention

Issue #106 closed
Brian Lewis repo owner created an issue

There is a lot of discussion about a School Report Card - a collection of indicators on the status of a school. The Pineapples School Profile Reports provide one type of view.

The Dashboard page recently enhanced in the School Item view will become the Report Card, possibly renaming the tab.

We identify a collection of typical items that may appear on the dashboard:

e.g. enrolment by level and gender - latest survey

enrolment growth - last 5 years vs national vs province

exam result pyramid vs national - specific exam and year

etc.

Each of these is implemented as an angular 1.5 component.

Then, for each system (KEMIS, SIEMIS, RMI, ....) and school type, there is a ReportCard component, that is a collection of these granular components (laid out in some responsive grid arrangement).

The virtual call to e.g. reportcard/pri

will be handled by MVC routing to return the correct component for the current system and school type. Utlimately it will return a cshtml page, in ReportCard folder, named e.g. SIEMIS_PRI.cshtml

By sticking to this convention it will be easy to tweak the report card without changing code.

Comments (7)

  1. Brian Lewis reporter

    Ideally, for performance, the ReportCard should be responsible for collecting and distributing the data required by each of its components. This is so that:

    • we have only one round trip to get all the data for the report card
    • some components may provide different visual representations of the same data, it would be good not to read the data twice.

    Need consideration of how best to achieve this, but one option would be for ReportCard to pass, a reference to an array to each of it child components. The child adds a token to the array indicating the data it wants, ReportCard gets all the unique values in one call (similar to how Lookups can retrieve an array of lookup tables) then each component gets the member of the returned aggregate data object that is needs.

    Because there is already various related data in the School object itself ( filling the survey, exam... etc lists), the ReportCard should receive the school object (vm.model) and each child should get this as well. A child that can construct itself using only this data need not return any extra data request to the ReportCard.

  2. Ghislain Hachey

    I agree with most of this but I think we have a great deal of work which should be done before this (sorry for repeating myself). It would be nice if the angular component would be materialised so a future effort to completely materialise the UI will be greatly reduced (now we are in a mix of an angular bootstrap theme, messy CSS, custom theme directives, angular-materialise components, etc.). But definitely, I like the sound of everything here.

  3. Brian Lewis reporter

    @ghachey

    This proposal relates more to the needs of the established sites - SI and Kiribati - than to RMI for the moment. For the existing sites, there is already plenty of data - the issue is making it accessible. There has been a lot of broader discussion around performance indicators aka School Report Card - so this would be a popular enhancement I think.

  4. Ghislain Hachey

    Closing this discussion. School Report Card in progress in another ticket. The web version of it will be done as part of another newer ticket based on dashboard architecture.

  5. Log in to comment