inst/template_requirements/template_requirements.md

% Specification of requirements for a map/graph/table page

Introduction

Today, we have a process that deploys several web pages know as 'smittläge' that illustrate the current state of disease or surveillance of a disease based on data that changes daily.

This is achieved by the following procedure:

  1. A scheduled task is run in rapportportalen to write a dataset to a tab separated text file containing the relevant data every day at ~06:00.

  2. A scheduled task is run on a server each day at ~06:15 that reads this data and executes a data cleaning script written in R that results in a json formatted text file (Examples of cleaning scripts). The script also pushes this text file to an azure webserver. The server also hosts a series of html, .js and .css files that display the data as a map, graph or table (template files).

  3. This standalone page is then embedded in an iframe in a page specified in episerver.

In some cases, specific requirements that fall outside the standard template are required and in that case an ad hoc .js is used (Example of ad hoc). In some cases stand alone pages are written to fill these requirements (Example of stand alone).

We have 2 data visualisations that follow a template that we have developed: A point map, and a choropleth map, where we think this would be appropriate for another 2 maps that have not yet been migrated (1 and 2)

Future needs

We would like to develop a means to deploy such data visualisations that do not require the use of iframes as they cause scaling problems when iframe content is responsive in a page that is also responsive.

Figure 1

  1. A legend with multiple parts (text from .json)
  2. Dots with different colours and sizes (colour and size from .json)
  3. Time selection. We chose the crude time slider as opposed to a calendar select because we also supply tabular data for those that want summary by month (Date in .json)
  4. html formatted Popup text (Contained in .json)
  5. Layer titles (text from .json)
  6. Interactive timeseries. The time slider controls the map and graph. The option of having a graph is determined by a variable (variable from .json)

Figure 2

  1. A table that is sortable and the contents comes from the same .json data as the map/graph. The standard is that we always summarise by county.

Figure 3

  1. The ability to view a single year by month.

Workflow considerations

Because SVA has had a primary development role in the publishing of data driven infographics on the web, we would like to have the continued ability to influence the future development. We see this in two parts: 1. A template/document type for an infographic in umbraco and 2. Standalone graphs developed for highly specific needs that arise which do not fit into a standard predefined structure.

Template

Our development at SVA has been focused to frontend web development in html, js and css as well as R which we use to do our data cleaning and testing prior to pushing data to the web. We have not previously worked within a CMS but have experience developing some applications with ASP.NET framework, C# and databases ( SQL server, MySQL and PostgreSQL). We welcome the opportunity to be actively involved in the development of specifically the document type for an infographic. We will need some specifications of the development environment KnowIT uses for Umbraco. This is necessary to together develop the best representations of biological systems since we have close contact with the experts and see benefits of keeping development competence close to the ground.

Stand alone graphs

For this purpose we see our current workflow as entirely adequate but would like input in improving the integration of external content in a CMS managed page, which is currently done in an iframe. The development here could also influence the choices in a template as we may discover features or flexibility in this work that could be incorporated into a template.

How we work

We use git version control for our code repositories and use the GitHub platform to collaborate but are currently in the process of evaluating the AzureDevOps platform which will use in the future for private code repositories.



SVA-SE/svamap documentation built on Sept. 25, 2020, 3:53 p.m.