Difference between revisions of "Agile Alligators"

From mn/ifi/inf5750
Jump to: navigation, search
m (Suggested improvements to Tracker Capture App: Grammar)
 
(24 intermediate revisions by 3 users not shown)
Line 14: Line 14:
  
 
=== Technologies ===
 
=== Technologies ===
We foresee developing the existing web application and therefore using the following web technologies: HTML5, CSS, Javascript, Hibernate, PostgreSQL, Spring, Maven, JSON. Although this may be subject to change as the project develops.
+
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.
  
 
== Milestones ==
 
== Milestones ==
Line 48: Line 48:
  
 
== Prototypes ==
 
== Prototypes ==
=== Screenshots ===
+
===Legacy ===
==== Legacy ====
 
 
Documentation of legacy systems from before any effect's are implemented.
 
Documentation of legacy systems from before any effect's are implemented.
  
 +
==== Screenshots ====
 
<gallery>
 
<gallery>
File:TrackerCaptureApp_firstVisit.png|This screenshot details the input fields that the legacy system offers upon the first entry of a patient. There is a clear lack of visualization of the data. This would help any viewer gain a better understanding of the data and their implications
+
File:TrackerCaptureApp_firstVisit.png|This screenshot details the input fields that the legacy system offers upon the first entry of a patient. There is a clear lack of any historical data. This would help any viewer gain a better understanding of the data and their implications
 
File:TrackerCaptureApp_secondVisit.png|This screenshot is of the data entry of the second visit. This form still do not offer any visualizations, but also not indicators of progression or history from previous visit(s)
 
File:TrackerCaptureApp_secondVisit.png|This screenshot is of the data entry of the second visit. This form still do not offer any visualizations, but also not indicators of progression or history from previous visit(s)
 
File:Confirmation buttons.png|The buttons that are provided for interacting with the forms are not dynamic and do not offer any indication towards the intended use by the user
 
File:Confirmation buttons.png|The buttons that are provided for interacting with the forms are not dynamic and do not offer any indication towards the intended use by the user
 
</gallery>
 
</gallery>
  
==== Static HTML ====
+
=== Static HTML ===
 +
==== Screenshots ====
 
<gallery>
 
<gallery>
 +
File:Static_dataEntry.png|DHIS2 Tracker Capture app, Data Entry component. Static HTML prototype with suggested improvements to the gui. New column showing the data from a previous event
 +
File:Static_btns.png|Static HTML implementation of changes to the button layout and look for the DHIS2 Tracker Capture app
 +
</gallery>
  
</gallery>
+
=== High-Fidelity ===
==== High-Fidelity ====
+
==== Screenshots ====
 
<gallery>
 
<gallery>
File:DataEntry_newLayout_wOldValues.png
+
File:DataEntry_newLayout_wOldValues.png|DHIS2 Tracker Capture App, now capable of viewing old values
File:DataEntry_skipNon-Relevant.png
+
File:DataEntry_skipNon-Relevant.png|DHIS2 Tracker Capture App, now with properly ordered events, and the old data that is displayed will skip events without any relevant data
File:Btns_Complete_Delete.png
+
File:Btns_Complete_Delete.png|New suggestions for buttons for data entry in the tracker capture app
File:Btns_Revoke_delete.png
+
File:Btns_Revoke_delete.png|New suggestions for buttons for data entry in the tracker capture app
 
</gallery>
 
</gallery>
 
+
==== Download Link ====
=== Sketches ===
+
Sample version: http://
  
 
== Changes to The Tracker Capture App ==
 
== Changes to The Tracker Capture App ==
  
 
==== Main Task - Displaying Previous Data Values ====
 
==== 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.     
+
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.     
  
<nowiki> </nowiki>In addition to the main task of this assignment, which was implementing the ability to view data entries for previous events when entering data,  we have made some additional changes to the Tracker Capture App that we believe could enchance the user experience.  
+
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 ====
 
==== Changing Event-ordering Within a Stage from Right to Left to Left to Right ====
Line 85: Line 93:
 
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.  
 
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.  
+
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 ==
 
== 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 ==
 
== Suggested improvements to Tracker Capture App ==
*Data validation:using html in the section Stage.programStageDataElements it would be better if values validate, weight and CD4 count do not allow negative values for example
+
We do not have any suggested improvements regarding the API, however below are some suggested tracker capture app improvements:
*Centralised Naming convention, eg Infant weight and weight
+
*'''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.
 
 
  
 
== Repo ==
 
== Repo ==
Static HTML Prototype:
+
'''Static HTML Prototype:'''
  
 
git@github.com:ehatle/AlligatorStaticHTML.git
 
git@github.com:ehatle/AlligatorStaticHTML.git
  
Final product:
+
 
 +
'''Final product:'''
  
 
git@github.com:ehatle/AgileAlligators.git
 
git@github.com:ehatle/AgileAlligators.git
 
== Download link to sample web app ==
 

Latest revision as of 17:30, 14 December 2015

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

Technologies

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.

Milestones

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

Progress

Meetings

  • 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

Prototypes

Legacy

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

Screenshots

Static HTML

Screenshots

High-Fidelity

Screenshots

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.

Repo

Static HTML Prototype:

git@github.com:ehatle/AlligatorStaticHTML.git


Final product:

git@github.com:ehatle/AgileAlligators.git