Nordur

From mn/ifi/inf5750
Revision as of 12:01, 7 December 2017 by Celinaum@uio.no (talk | contribs)

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

Master Facility List for DHIS2

Group project in INF5750 - Open Source Development.

Github: https://github.uio.no/inf5750-nordur/nordur

The project readme contains information about usage, installation, detailed package/framework/library use etc.

Group members

  • Tor Jan Derek Berstad
  • Odd-Tørres Lunde
  • Celina Moldestad
  • Åsmund J. Rosendahl

Project description

Planned features

User

  • FU1: When searching the user shall be able to see a list of all the facilities, they can choose one of them or type in the specific facilities. The application has the autocomplete-ability, so it is easy for the user to use the search functionality.
  • FU2: When the user finds a specific facility they shall be able to click on that and get more information about that facility, and GIS coordinates on the map, when available.
  • FU3: On the map, the user can move around and click on groups of facilities, or click on a specific facility and get the information about that facility.
  • FU4: The user is able to do an advanced search with specific queries (using filtering) to get information about the facilities. Like searching within a chosen country or city. The advanced search functionality enables the user to do searching based on the facilities in one city, or searching/browsing based on organization unit groups.
  • FU5: When the user is on the information page to a specific facility they shall be able to propose changes to the information being displayed. They click on the edit-symbol to go to the edit view. The changes shall then be approved by an administrator in order to be changed. The changes could, for example, be either improvement or filling in the blanks (patch/put and post requests).

Administrator

  • FA1: Admin is a user with appropriate user authorities, and therefore should be able to perform more operations than a regular user.
  • FA2: The admins should, therefore, be able to approve or ignore the proposed changes request from the users on the configuration page. On the page, the admin sees a list of all the proposed changes (if created/available).
  • FA3: The list on the configuration-page should be filtered to show only proposals relevant for the particular administrator (i.e. an administrator for District A should only see proposals for related to organization units in District A, not those in District B). The admin can approve the changes or just choose to ignore that request.
  • FA4: The administrator shall also be able to configure the app to show data element and/or indicator values for the particular organization unit for the current/last year, such as population estimates, staff count etc. On the "configuration" page the administrator can also configure the app, by selecting what data to display.

filt design.

Design

The application is also split into two views, the user view, and the admin view. (You must have the admin-authorities to use the admin-page.)
The design of the application is split into four window-parts: The search box, the filter box, the information box and the map.

  • The search box is where the user can search for different facilities and in combination with the filter box they can specify their search.
  • The filter box: The user can choose between different filters, such as country, city and organization unit groups.
  • The information box: The information about the facility
  • Map: Shows where the particular facility is localized.


app design. app structure.

Architecture

After a discussion in the group. We decided to go for React as the framework for this group project. We considered several different architecture/frameworks. Django was considered, but we don't currently require a backend. So Django felt like "overkill" for this assignment.

The application is split into four main parts, and it is a microarchitecture:

  • APP.js - The main node
  • Search.js - This function calls upon the API-interface which gets the information from the info.js and the map.js components, and render the information on the screen.
  • API.js - An interface that gets the search queries and collect the correct information from info.js and map.js.
  • Leaf - components: Info.js, map.js and text.js.

This hieratic makes the components somehow independent, which makes the microarchitecture.
When a user searches, by selecting filters and writing queries the Search function gets a get-request like this "https://inf5750.dhis2.org/demo/api/organisationUnits/<id>". The query that the user types in gets converted to its id so that we can get the information. We use Material UI's autocomplete, so we have all the facilities.

Endpoints from DHIS2 API documentation:
1.7. Metadata object filter
1.8. Metadata field filter
1.56. Data sets - /api/26/dataSets

Tools

  • Github Enterprise - Collaboration tool for projects and development platform for host and review code, manage our project and version control.
  • Slack - Communication tool.

Frameworks

  • React - We choose to use react.js because it was javascript-based, easy to use, and it does the page more dynamic. We used the Goldilocks rule from the nine Guiding Principles in Platform Markets, when choosing this framework, Node.js was to easy, React.js was perfect and Django was to hard.
  • react-google-maps - Collaborates with React.
  • Material UI - We chose to adopt some of Material UI's components because it is a nice way to design the web page.

Licensing

This application is provided under an MIT license, we choose to make this project as an open-source project. All other relevant licensing information can be found in the project readme.

Division of labour

We used Github's projects as an collaboration tool for projects. It works like Trello, you can make problems and sub-problems, and label them as ToDo, doing and done.

Tor Jan: Developer - Map (FU2, FU3), Readme, design (UI)
Odd-Tørres: Developer - Organisation filter (FU4) and search, app architecture
Celina: Developer - Organisation information page (FU1, FU2), wiki-page, design (UI)
Åsmund: Developer - Organisation search, api, communication between the app and the DHIS2 API

Repository

Nordur's repository
Project: Master Facility List

Timeline

Timeline3.png

Week 43 and 44 - The setup-stage

  • Project planning (description plan)
  • Write wiki-page
    • Discussed framework, design, and architecture
    • Create features
  • Get to know react.js
  • Get to know DHIS api’s documentation.

Week 45

  • List data (Master Facilities)
  • Search-function (Attribute search)
  • Simple use of map-structure

Week 46

  • Advanced search-function with filtration
  • List specific data
  • Show map and use of “advanced” map.

Week 47

  • Bug-fix and handling issues
  • Propose changes
  • The admin configuration-page
  • Combo search-function with different filters.

Week 48

  • The admin configuration-page
  • Propose changes
  • Show more data

Progress

The site in its current configuration

The primary information source for progress on this project is the project readme. So far the following features are completed and working in the master branch.

User

  • FU1: When searching the user shall be able to see a list of all the facilities, they can choose one of them or type in the specific facilities. The application has the autocomplete-ability, so it is easy for the user to use the search functionality.
  • FU2: When the user finds a specific facility they shall be able to click on that and get more information about that facility, and GIS coordinates on the map, when available.
  • FU3: On the map, the user can move around and click on groups of facilities, or click on a specific facility and get the information about that facility.
  • FU4: The user is able to do an advanced search with specific queries (using filtering) to get information about the facilities. Like searching within a chosen country or city. The advanced search functionality enables the user to do searching based on the facilities in one city, or searching/browsing based on organization unit groups.

Administrator

  • FA4: The administrator shall also be able to configure the app to show data element and/or indicator values for the particular organization unit for the current/last year, such as population estimates, staff count etc. On the "configuration" page the administrator can also configure the app, by selecting what data to display.