Difference between revisions of "Nordur"

From mn/ifi/inf5750
Jump to: navigation, search
(Frameworks)
(Architecture)
Line 49: Line 49:
  
 
The application is split into four main parts, and it is a microarchitecture:
 
The application is split into four main parts, and it is a microarchitecture:
* APP -  
+
* APP - The main node
 
* Search - This function calls upon the API-interface which gets the information from the ''info'' and the ''map'' components, and render the information on the screen.
 
* Search - This function calls upon the API-interface which gets the information from the ''info'' and the ''map'' components, and render the information on the screen.
 
* API - An interface that gets the search queries and collect the correct information from ''info'' and ''map''.
 
* API - An interface that gets the search queries and collect the correct information from ''info'' and ''map''.

Revision as of 18:37, 6 December 2017

Master Facility List for DHIS 2

Group project in INF5750 - Open Source Development.

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

Group members

  • Tor Jan Derek Berstad (tjbersta@mail.uio.no)
  • Odd-Tørres Lunde (oddtorrl@mail.uio.no)
  • Celina U. Moldestad (celinaum@mail.uio.no)
  • Åsmund J. Rosendahl (aasmunjr@mail.uio.no)

Project description

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 have 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 are able to do 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 organisation 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-wive. 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 organisation 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 organisation 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 select what data to display.

Design

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

  • The search box: Are 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 structure. Print of the web application

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 - The main node
  • Search - This function calls upon the API-interface which gets the information from the info and the map components, and render the information on the screen.
  • API - An interface that gets the search queries and collect the correct information from info and map.
  • Leaf - components: Info and map.

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 uses 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
1.76. Data store - /api/26/dataStore
1.76.3. Store and create values - Example: POST with request (...)/api/26/dataStore/nordur/<namespace>/<key>

Tools

  • Github's projects (Trello) - Collaboration tool for projects.
  • Slack - Communication tool.
  • Github - Development platform for host and review code, manage our project and version control.

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 choose to adapt some of Material UI's features, because it is a nice way to design the web page.

Licensing

React.js is licensed under MIT.
Our license is also under MIT, we choose to make this project as an open-source project.

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, UI
Odd-Tørres: Developer - all
Celina: Developer - information page
Åsmund: Developer - all

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