Stockalyzr

From mn/ifi/inf5750
Revision as of 02:16, 6 December 2017 by Mjstang@uio.no (talk | contribs) (Product descriptions requirements: browser support)

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

Team members

  • Mathias Stang (mjstang)
  • Patryk Kucmann (patrykk)
  • Guro Møller Ødegård (guromod)
  • Pavel Shramau (pavelsh)

Product descriptions requirements

We are doing the Stock Level Visualisations assignment.

Our app should let the user enter two different modes:

  • Estimated months of stock left
    • Let user select one or more organisation from any organisation level (multi-select)
    • Let user select which stock to show from a pre-defined list of admin-defined configurations
    • Let user override which indicators/data elements to use for stock levels and monthly usage, and min/max thresholds of what is an acceptable number of months
    • Show graph based on the aforementioned options
    • Let user save current graph to a dashboard widget
  • Time trend for a single organisation unit
    • Let user select one organisation from any organisation level (no multi-select)
    • Let user select which stock to use from a pre-defined list of admin-defined configurations
    • Let user select how many months to show the time trend for
    • Let user override any admin-defined data in the same way as the Estimation feature (min/max thresholds should apply to min/max acceptable stock levels, not months)
    • Show graph based on the aforementioned options
    • Let user save current graph to a dashboard widget

In addition, there should be an admin configuration page that lets admins add, edit and remove configurations. A valid configuration should contain:

  • Name (shown to the user where the users selects a configuration)
  • Set one data element/indicator used for stock levels and one for usage. Assuming that if multiple data elements are combined, this can be done outside the app using indicators
  • Set min/max thresholds for number of months of left (for the Estimation feature) and min/max thresholds for stock levels (for time trend feature)

Responsive design is important for us and influenced the choice of UI library and the general layout. The app works well on Android and iPhone, as well as Chrome, Safari, Firefox and Edge. However, the app doesn't work in Internet Explorer because the D2 library doesn't support it.

Mockup

Mockup.png

Screenshots

Stockalyzr1.png

Stockalyzr-admin.png

Stockalyzr-timetrend.png

Architecture

We chose React as our main framework, as it's a widely used, well documented framework, and one of the team members had some previous experience with it. We also considered Angular.js, but it seemed like having a steeper learning curve and fewer third party components, and Vue.js, which is a less mature framework with fewer third party libraries (which turned out to be important for us). In retrospect, it would have made sense to use Redux or Flux, as there's a lot of data stored in a top-level component being passed down to child component. However, we decided against it as we already had our hands full learning React's state management system, and using Redux/Flux would add another layer of complexity and increase development time.

We decided to use Semantic-UI. It seemed to have all main components we were looking for, and seemed to have all the UI components we needed to build our app. It also has good support for responsive layouts, which was important for us.

We use the D2 library for DHIS2 integration.

For visualising data, we decided to use HighCharts because it is already used in DHIS2's Visualizer chart plug-in, so we assume that DHIS2 has a valid license for it. It also has a much simpler API than a library such as D3.js, and is more powerful than similar open source libraries such as Chart.js.

We also use React-virtualized-select for a "multi-select dropdown" which handles large datasets in a much better way than Semantic-UI's dropdown component. We use React Toastify for displaying transient notifications to the user.

Timeline

  • November, 1st - wiki page, understanding of DHIS2 API needed for the application, frameworks and tools to be used are defined.
  • November, 7th - general look and design of the application, functional and non-functional requirements specified, start of implementation.
  • November, 26th - end of implementation, start of testing and debugging.
  • December, 1st - project done, start of presentation preparation.
  • December, 4th - presentation made.

Group meetings, problems discussions and temporary result evaluations every Tuesday and Friday.

Licensing

In our project we are using React as the only JS-framework to develop the application. React was using BSD+patents licence before, but from version 16 it is licensed under permissive MIT licence. This grants us the permission to use React in any way with only one condition, which is to include the copyright notice. Since we are interested in developing a fully open source application with source code published as it is on GitHub and the only framework we are using is React, Stockalyzr will be released by MIT licence too.

DHIS2 is using BSD licence, but we are using only Open API's from DHIS2, so it does not come under consideration.

Division of labour

Originally, before we started coding we gathered every Tuesday and Friday to discuss the way we were going to work and shape the architecture for our App. We also tried to find out how DHIS2 exactly works with the organisations and elements, so we have better understanding before actual implementation. The group teacher have also answered some of our questions. Everyone showed up at the meetings with a motivation for making this project a success. Some of us had more experience, and thus they helped explaining and sharing their knowledge, showing support. Until the end we cared for our up to make it simple, attractive and functional.

Each team member initially focused on different parts of planning and development, but after a while we were all coding. We use a Kanban-like development process where we have organised everything we need to do into discrete tasks and use Trello to show tasks that need to be done, tasks in progress, tasks which need reviews and tasks that are done. Each team member codes their currently chosen tasks on a separate branch of our GitHub repo, and when it's ready, another team member reviews it and chooses whether to merge it into the master branch.

The initial division of labour was as follows:

  • Mathias: Set up the repo with the main libraries, ESLint config etc. so that the rest of the team has a good starting point. Figure out Highcharts and create estimation chart functionality. Help with explaining react and html. General layout implementation. Small design additions and error checking in estimation trend.
  • Pavel: Figure out which parts of the DHIS2 API we needed, and document everything for the rest of the team. Bug fixes. General layout implementation. BaseUrl for any DHIS2 servers.
  • Guro: Figure out how to build and deploy an application for DHIS2. Bug fixes for Admin. Admin functionaliy.
  • Patryk: Figure out how to build and deploy an application for DHIS2. Figure out Highcharts and create time trend chart functionality. Bug fixes in time trend and estimation. Small design additions and error checking in time trend.

Repository

GitHub repository