Agile Alligators

From mn/ifi/inf5750
Jump to: navigation, search

Link to project description: [1]

Our project will look at the usability of the Tracker Capture app in DHIS2. We will focus on fulfilling the requirements stated by the users, but also look into other possible usability improvements.

Group members

Summary of requirements

  • Visualize the previous data from the database dynamically
  • Further improve usability of the app


We foresee developing the existing web application and therefore using the following web technologies: HTML5, CSS, Javascript,Angular,Hibernate, PostgreSQL, Spring, Maven, JSON. Although this may be subject to change as the project develops.


Milestone 1: 8th November: Finish project planning; Document features and architecture on Wiki

Milestone 2: 22nd (Delayed: 23rd) November: Initial, low-fidelity HTML prototype

Milestone 3: 4th December: Final product

Final delivery: 11th December

Presentation: 17th December



  • Nov. 6th: We decided on a schedule for weekly meetings on tuesdays from 10:15 - 12:00. Communication channels established by exchanging emails and connecting on facebook for IM communication. Initial vision and plan developed.
  • Nov. 10th: Cancelled due to group members being sick.
  • Nov. 17th: Sum up of current progress, and collective work session.
  • Nov. 23rd: Finished the static HTML prototype
  • Nov. 24th: Mapping way forward on Webapp
  • Nov. 25th: CANCELED
  • Dec. 1st:
  • Dec. 3rd:
  • Dec. 4th: Project installation
  • Dec. 8th: Frontend development: JS Exploration
  • Dec. 9th: Frontend development: Implementation and testing
  • Dec. 10th: Frontend development: UX upgrades

Division of Workload

  • Emil: Low-fidelity prototypes, UX dev, displaying previous data values on HTML side of things
  • Mwiza: Responsible for retrieving previous data values on the javascript side of things
  • Nico: Setup postgres-database & hibernate connection, responsible for additional usability changes



Documentation of legacy systems from before any effect's are implemented.


Static HTML




Download Link

Sample version: http://

Changes to The Tracker Capture App

Main Task - Displaying Previous Data Values

The main task in our assignment was to show users of the Tracker Capture App data entry the data values of previous events. In our final solution (as seen above in the screenshots-section), you can see that we have added more columns to the data-entry table to the left of the input field. These corresponds to earlier event's data values. During the development, we had to make a choice about what events we would include as the previous "events", since it was not specified in the assignment. Out options were to either list previous events from within the same program stage (for instance ANC-Visit 2-4+), or include all previous events from the program, also including events outside the current stage. We felt the latter made more sense, and chose to implement it that way.

To avoid including columns for previous events with no relevent data for the current table (could easily happen for a previous event from a different stage that has few data-values in common with the current event), we check all previous events for relevant data to display, and exclude them if they do not possess any.

To map data-values from different events (which might have different attributes/rows in the data-entry table), we rely on the id given to the different data values. Thus, we make the assumptions that the same id to data-values/categories (for instance "Weight" or "CD4 count") across events/stages in the programme is consistent.

In addition to the main task of this assignment, we have made some additional changes to the Tracker Capture App that we believe could enchance the user experience. Note that since none of us are experienced or invested users of the Tracker Catpure App, we have tried to use our best judgement of what we think could be beneficial changes, which does not necessarily have to be the case for the actual users of the Tracker Capture App.

Changing Event-ordering Within a Stage from Right to Left to Left to Right

In the default Tracker Capture App, when creating a new event in a stage, new events are added to the left of the previous one. We found this confusing, as events within stages would come in reverse chronological order when read from left to right. This contrasts with the order stages are found in a program, and also how we have added the previous values of events to the left of the data-fields. By simply changing the order, we feel the layout for a program with it's stages and events is more intuitive.

Changes to the Buttons

In the existing app, input data is validated as soon as it was entered in (for instance, writing a non-number in a number field would give feedback on incorrect input). This left the "Validate"-button without much function, so we decided to remove it to reduce clutter and confusion.

We also changed the color of the "Complete" button to a color we felt was more suited for the action of completing a form, and renamed "Incomplete" to "Revoke".

Learning Outcomes

  • We have learned a lot regarding app development in DHIS2 and the vast resources that its API provides.
  • We successfully learned about AngularJS within a short time, as we were required to use it in our project.

Overall,we have learned that from time to time developers/IT professional will have to learn and use new programming languages or technologies.It is therefore important to leverage different technologies available to provide solutions to some given task or problems.

Suggested improvements to Tracker Capture App

We do not have any suggested improvements regarding the API, however below are some suggested tracker capture app improvements:

  • Data Validation: The data contained within Stage.programStage.DataElements array could be expanded to provide validation rules for the forms. For example allow for minimum values for numbers, therefore eliminating the possibility of registering a weight below 0. This would effortlessly be validated through standard HTML form validation.
  • Standardization of IDs: We noticed that some IDs were not standardized (for example a child's "birth weight" at birth and "weight" thereafter). By standardizing these IDs the system would be more easily indexed and utilized, and the values could also then be recognized as related and therefore shown in among the previous data.


Static HTML Prototype:

Final product: