Hooli

From mn/ifi/inf5750
Revision as of 16:19, 5 December 2017 by Tinng@uio.no (talk | contribs) (Base architecture)

Jump to: navigation, search

Group members

  • Sharanan Kulam (sharanak@ifi.uio.no)
  • Jagat Deep Singh (jagatds@ifi.uio.no)
  • Tin Anh Nguyen (tinng@ifi.uio.no)
  • Son Thanh Vo (sontv@ifi.uio.no)

Project

Master Facility List

Product descriptions requirements

Design

First wireframe of the project

The app should be split into two main views: a user view; and an administrator view. This can be realized through a form of tabs. The former should be the view where all users may search and browse information on the different organisation units; while the latter should be the view displaying relevant proposals to the user (whom could be an administrator, or not—in which case it's empty)

The user view should again be split into three columns: one for search and filter; one for the list of query results; and one for the organisation profile, which displays information on the user-selected organisation unit. Clicking on a organisation unit from the query results should display its information in the profile column.

Searching should by done using a text field for the organisation unit name. And filtering can be further specified by adding tags corresponding to organisation unit groups and data sets. To add these tags, two combo boxes—with search—could be used. As for filtering on organisation unit hierarchy, this will have to be further studied.

To propose changes for an organisation unit; one solution could be to have a button appear on the organisation profile, which opens up a modal for editing/proposing changes. The modal should have buttons for submitting and/or discarding the proposals, one for each.

The administrator view can be split into two columns: one for the proposal list, which lists all of the relevant proposals; and one for the proposal view, which displays the text of proposed changes.

For resolving and invalidating proposals; two button at the top-right corner of the proposal view should suffice.

The user view for the organisation unit

Users Features

F1: All users should be able to get a list of all organisation units, and be able to search and filter on it. A user should be able to filter based on organisation unit name, organisation unit groups, data sets, and a combination of these.

F2: All users should be able to view an organisation unit's information—all attributes, as well as: GIS coordinates on a map, when available; membership in organisation unit groups; data sets, and indicator values (stats).

F3: All users should be able to submit proposals for changes to the information of any organisation unit. These proposals should be stored for later inspection from an appropriate administrator

The admin view for proposals and configuration

Admin Features

F4: Administrators should be able to view a list of submitted proposals for the organisation units in which they manage. I.e. administrators should only be able to see relevant proposals.

F5: Administrators should be able to view the content of a submitted relevant proposal. I.e. display the proposed changes, and possibly optional comments as to why the changes should be made.

F6: Administrators should be able to mark relevant proposals as resolved/invalid. Marked proposals should, by default, not be displayed to the administrators.

F7: Administrators should be able to choose which data elements and indicators are to be displayed for a given organisation unit, in which they manage. Normal users will, then, only be able to see the chosen data elements, when trying to view the organisation unit's information.

Architecture

The application is split into four main parts:

  • Components handle the app's presentation logic; it renders the different parts of the application based on global and local state, as well as dispatches actions on user-triggered events for modifying and fetching data.
  • Reducers combine to hold the global state of the application, each reducer managing how actions affect its sub-state. We have chosen to separate our state into the following reducers: config; filters; organisationUnits; proposals; and user. In this way, the data is component agnostic and can be easily accessed from any component.
  • Actions are functions which can be called to handle side-effects. They are mainly used by components to trigger changes in the global state, but may also be dispatched through other actions. The majority of our actions are async, as most are meant to either fetch or modify data through the DHIS2 api.
  • API which consists of a set of functions for accessing the DHIS2 API, providing an interface for the actions to use. This separates the data-access logic from the application logic.

This separation is reflected in our folder structure, with each part having its own folder inside the src folder. Components are the only ones, who have sub-hierarchies – with related components grouped together. Each hierarchy consists of components with their accompanying stylesheets and tests placed into folders named "styles" and "___tests___", respectively.

Proposals and configurations are stored in the app's dataStore (the namespace is set to "master-facility-list-hooli"):

   {
       proposals-<organisationUnitId>: [
           {
               id: <organisationUnitId>,
               created: <dateSubmitted>,
               lastUpdated: <lastModifiedDate>,
               status: <"pending"|"resolved"|"invalid">,
               title: "<title">
               description: "<textOfProposedChanges>",
               dataElements: [<dataElementId>, ...],
               indicators: [<indicatorId>, ...]
           }
       ],
       config-<organisationUnitId>: {
           dataElements: [<dataElementId>, ...],
           indicators: [<indicatorId>, ...]
       }
   }

Since

Frameworks

  • React - We chose React mainly due to its popularity, giving it a larger ecosystem. Compared to the other two big frameworks (Vue.js, Angular), we followed Goldolick's rule and chose React as it strikes a balance between simplicity (ease of learning) and scalability.
  • Semantic Css - We needed a CSS framework to reduce the amount of styling, and chose Semantic as it had a library providing a lot of pre-made React components—and was pleasing to the eye.

Division of work

We used Trello to organize the features (listed above) into descriptive tasks and sub-tasks. Initially, we assigned primary tasks to each member. During every weekly meeting we discussed the progress for each assigned tasks (e.g. reviewing the code/pull-request, discussing challenges, etc...), and distributed the tasks from the backlog for the upcoming week.

General overview of labour distribution:

  • Thanh Son: Organisation filter and organisation config (F1, F7)
  • Sharanan: Organisation search and admin proposals (F1, F4, F5, F6)
  • Deep: Organisation profile (F2, F3)
  • Tin: Communication between the app and the DHIS2 API and app architecture (F7)

Licensing

React and Semantic are both licensed under MIT, and so are all of our other dependencies. Therefore, we were free to license our project under any license, and chose MIT to remain open source and not restrict derivative works.

Timeline

Week 43

  • Studied requirements
  • Write wiki-page
    • Discussed framework and architecture
    • Setup time management
  • Setup project
  • Get familiar with react
  • Get familiar with DHIS2

Week 44

  • Implement search: organization unit
  • Implement filter: organization unit
  • implement display: organization unit

Week 45

  • Implement view: user proposing changes
  • implement view: admin reviewing proposals
  • Implement view: admin data display/configurations
  • Implement api for data store usage

Week 46

  • Feature extentions
  • Bug fixing

Week 47

  • Bug fixing

Week 48

  • The week where we actually do stuff