This is a conceptual design proposal for how to rapidly implement a self service portal for COKI-branded reports. There are three main steps:
Consolidate the existing reports into one single codebase and template(s) with the selection of report type set as a parameter in the precipy config.json file and other design features left as inclusion or exclusion of specific tables and charts. This is partly complete (institutions and countries, funders to follow) and relatively easy now to progress to a point that will work as a PoC
Generate a web interface that is populated based on a template of config.json and a registration process for the relevant analytics functions. The web interface provides a point and click interface to set report type and parameters (eg IDs, time range, comparison groups), select particular charts and tables for inclusion, and (in the future) set output types and templates. The web interface writes out a complete config.json file ready to run the report(s).
Package the web interface and other necessary code as a flask app or cloud function or whatever makes the most sense.
The core concept here is that by filling out the config.json full control over the report generation is possible. The basic report parameters (aggregation, IDs, time range, focus year, comparison group) are explicitly defined up front and should be implemented as CONSTANTS.
By implementing some sort of registration of the functions that generate charts and tables it is possible to populate both a list of charts and tables to select for inclusion, and by inspecting their call signatures, to define any specific required parameters. All of this can then be added in the ANALYTICS section.
There is currently some differences between templates for word and pdf output reports but this can also be easily handled, in the first instance with a fixed selection that defines the appropriate parameters in the TEMPLATES and FILTERS sections of config.json. A preview function could also be developed using a dummy template and simply converting to HTML with links to the dynamic versions of charts hosted on Google Cloud for inspection.
The most complex parts here appear to be registration of relevant functions. I am currently looking into whether this can be neatly achieved by a decorator. The other implementation decision is the choice of web platform as presumably this will have some implications for development in terms of structure and production of the input form.
This is a conceptual design proposal for how to rapidly implement a self service portal for COKI-branded reports. There are three main steps:
config.jsonfile and other design features left as inclusion or exclusion of specific tables and charts. This is partly complete (institutions and countries, funders to follow) and relatively easy now to progress to a point that will work as a PoCconfig.jsonand a registration process for the relevant analytics functions. The web interface provides a point and click interface to set report type and parameters (eg IDs, time range, comparison groups), select particular charts and tables for inclusion, and (in the future) set output types and templates. The web interface writes out a completeconfig.jsonfile ready to run the report(s).The core concept here is that by filling out the config.json full control over the report generation is possible. The basic report parameters (aggregation, IDs, time range, focus year, comparison group) are explicitly defined up front and should be implemented as CONSTANTS.
By implementing some sort of registration of the functions that generate charts and tables it is possible to populate both a list of charts and tables to select for inclusion, and by inspecting their call signatures, to define any specific required parameters. All of this can then be added in the ANALYTICS section.
There is currently some differences between templates for word and pdf output reports but this can also be easily handled, in the first instance with a fixed selection that defines the appropriate parameters in the TEMPLATES and FILTERS sections of config.json. A preview function could also be developed using a dummy template and simply converting to HTML with links to the dynamic versions of charts hosted on Google Cloud for inspection.
The most complex parts here appear to be registration of relevant functions. I am currently looking into whether this can be neatly achieved by a decorator. The other implementation decision is the choice of web platform as presumably this will have some implications for development in terms of structure and production of the input form.