From mn/ifi/inf5750
Revision as of 13:48, 6 December 2017 by (talk | contribs) (Licensing)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Group Members

  • Andreas Holskil
  • Marthe Øvergård
  • Andreas Kristiansen

Product descriptions requirements



We want to create an app for displaying the HIV cascade analysis with graphs, where the user can specify the data to be displayed. There will be three main ways to display these graphs:

  • As percentages, where the first bar in the cascade is 100%, and the subsequent bars as expressed as percentages of the previous.
  • As raw numbers, but showing both the actual number and the gap (i.e. difference between target and actual).
  • As both raw data and percentages.


  • Search for the data elements you want to represent the chart bars.
  • Set the threshold for the graph, (80-80-80) etc.
  • Select based on sex.
  • Select based on org units (aggregate sub org units)
  • Save your graph and input settings for later use.


The application, with respect to backend, follows a simple client-server micro-architecture. DHIS2 launches the app and the app communicates with it from client side.

Application architecture

The application is based on three main containers with each their own responsibility:

  • The graph container
  • The graph settings control container
  • The data selection/input container

These communicate through redux mutating state.

Data selection

Lets you select what data you want to display. These selection settings are local state. The state reduced from these actions are available for the graph container to subscribe to. This container subscribes to the chart settings state, so that it can save those on the server.

Chart settings control

Lets you control the chart. These settings are shared when updated.

Chart container

Subscribes to state from data selection and chart settings control. Updates the chart on change in either data or settings.

Project file structure

The application was somewhat modeled after a technique called Ducks, where each "module" is placed within its own sub-tree of the file structure. We are just separating the reducers from one module from another, etc. The difference is that we segmented the file structure firstly as


  • chart/
    • actions/
    • reducers/
    • ...
  • dataSelection/
    • actions/
    • reducers/
    • ...

How we implemented it.

  • Actions/
    • chart/
    • chartControl/
    • dataSelection/
  • Containers/
    • chart/
    • ...
    • ...

So we didn't completely comply with this file structure, but we decided to keep it this way because our file stucture worked well and decided that refactoring this could be a future improvement. Shouldn't take long with modern IDE's.

The initial design for the application

These sketches show how we pictured the application to look like at the beginning of the project.

Ama1.png Ama2.png Ama3.png Ama4.png

The final design




Division of labour

Our plan was to divide the app into three main containers, which communicated through state changes. This allowed us to work independently on different problems, as long as we agreed on the state returned from the reducers. We had regular meetings to keep track of each others status and to discuss problems we faced, or to just sit and work together.

  • In the beginning we worked closely together with pair-programming as we were learning react and how to use it with redux.
  • In the middle of the project, when we had consensus on what the main contain we diverged more and focused on each our objectives.
  • At the end of the project, we converged again and worked on design/visuals, testing and debugging together.

Andreas Holskil

Responsible for Chart display and graph container.

Andreas Kristiansen

Responsible for data input/selection container. And backbone/initial structure.

Marthe Øvergård

Responsible for chart controller container, and presenting chart settings to chart as state.


Week 49

Finishing project. Bug fixing and settings saving. Manifest and implementation in DHIS2. Debugging and testing. Wiki updates and work on presentation.

Week 48

More definitive design and style implementation. Updating components with materials-components. Bug fixes and refactoring. Implementing chart controls. Implementing data selection controls.

Week 47

More definitive design and style implementation. Updating components with materials-components. Finishing data selection. Implementing chart controls. Implementing data selection controls.

Week 46

Each working on own containers. Reading DHIS2 documentation while implementing data selection. Implementing use of redux-thunk for asynchronous calls. Data selection and sanitizing of data (fictional data resembling the state presented when fetching from the data selection component) Implementing chart controls. Implementing data selection controls.

Week 45

Reading DHIS documentation while implementing data selection. Pair programming Implementing use of redux into the project. Learning redux.

Week 44

Initial backbone and division of responsibilities for containers. Learning react - set up backbone as simple react-redux containers for each of us to work within.

Week 43

Discussing selected assignment. Planning progress. React tutorials.

Week 42

First meeting. Initialize repository and discuss assignments. Selection of assignment and frameworks to use.

Project repository

Git repo