Difference between revisions of "Deliciouscake"

From mn/ifi/inf5750
Jump to: navigation, search
(Screenshots and screen flows)
m (Summary of requirements)
 
(25 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
[http://www.uio.no/studier/emner/matnat/ifi/INF5750/h15/group-projects/lmis-light/index.html Logistics Management Information System (LMIS) Light ]
 
[http://www.uio.no/studier/emner/matnat/ifi/INF5750/h15/group-projects/lmis-light/index.html Logistics Management Information System (LMIS) Light ]
  
The goal for the project is to replace the current paper based system for ordering commodities with a web-based app connected to DHIS2. This will enable users to submit orders to higher managements more efficiently than when using today's system. On one side the app is a simple web-based form where the health workers can fill in orders. On the other side the app is notification system, where the management can be notified of order requests.
+
The goal for the project is to replace the current paper based system for ordering commodities with a web-based app connected to DHIS2. This will enable users to submit orders to higher managements more efficiently than when using today's system. On one side the app is a simple web-based form where the health workers can fill in orders. On the other side the app is a notification system, where the management can be notified of order requests.
  
 
= List of group members =
 
= List of group members =
 
+
{| class="wikitable"
*Simen Røste Odden (simenrod@ifi.uio.no)
+
!Name
*Thomas Schwitalla (thoschwi@ifi.uio.no)
+
!Email
*Jørgen Valen (jorgeval@ifi.uio.no)
+
|-
 +
|Simen Røste Odden
 +
|simenrod@ifi.uio.no
 +
|-
 +
|Thomas Schwitalla
 +
|thoschwi@ifi.uio.no
 +
|-
 +
|Jørgen Valen
 +
|jorgeval@ifi.uio.no
 +
|}
  
 
= Summary of requirements =
 
= Summary of requirements =
  
 
''Functional requirements:''
 
''Functional requirements:''
*The app's main page must contain a form for the submission of commodity orders, and a dropdown menu from which the user may select a receiving user.
+
*A: The app's main page must contain a form for the submission of commodity orders.
**The input fields of the form must accept quantities given by positive integers of the requested commodities.
+
**A1: The input fields of the form must accept quantities given by positive integers of the requested commodities. It must be possible to enter values both by clicking buttons that increment or decrement quantities, and by entering values directly from keyboard/numpad.
**The form must have 3, 5 or 10 input fields for commodities depending on type of user.
+
**A2: The form must provide the entire selection of commodities available from the resource "Life-Saving Commodities".
***Subrequirements are still work in progress.
+
**A3: There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before a message may be generated and sent to the DHIS2 messageConversation resource.
**There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before generating and sending a message through the DHIS2 Messaging System.
+
***A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced.
***The input of each field must be restricted to positive integers no greater than the actual amount that is in store for each given commodity.
+
****A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending.
****Upon the submission of an order, if any fields do not contain a valid entry, an error message must display the available amounts along with instructions for the correct format next to the invalidated field(s). No message will be sent in such a case.
+
*****Upon the submission of an order, if any fields do not contain a valid entry, an error message in the summary must provide instructions for the correct format or valid inputs next to the invalidated field(s). No message can be sent in such a case.
**The dropdown menu must contain only users from the DHIS2 users resource that are authorized and capable of processing commodity orders.
+
*****Entirely empty orders are invalid. In case of such a submission, the summary must display an error message prompting the user to review .
**A confirmation message must be displayed upon submission of order.
+
****Upon the submission of a valid order, a button labeled "Send order" must be displayed under the summary table. On click, this button must generate and send the message to the appropriate recipients.
*The app must store previously submitted orders in the user's outbox in the messaging system.  
+
*****The "appropriate recipients" are defined as those roles that are related to the higher management of the current user's organisation unit.
*The recipient must get a message describing the submitted order.
+
*B: The Order message, subject "Commodity Order ", must contain in its body the list of each selected commodity and their respective quantities.
**The message must identify the sending user's name.
+
**B1: The message must also display the submission date and the name of the sender.
**The message must display the submission date
+
**B2: Upon successful sending of an order, on-screen feedback must inform that the order has been placed.
**The message must display the commodities and their respective quantities
+
***B2a: Additionally in this case, a confirmation message must be sent to the user's message inbox. This message, subject "Commodity Order Confirmation", must state the exact quantities of each ordered commodity.
 +
****An on-screen feedback message must inform that the confirmation message can now be found in the user's inbox.
 +
**B3: Upon unsuccessful sending, on-screen feedback must inform that the order was now placed, and that the user should try again.
 +
***B3a: The feedback must include any error codes available for debugging purposes.
  
 
''Non-functional requirements''
 
''Non-functional requirements''
* The messages generated from the app's form will be in the format JSON.
+
* Process requirements:
* User experience goals are work in progress.
+
** App will be developed in JavaScript + jQuery, and HTML/CSS.
* Performance requirements are work in progress.
+
** The messages generated and sent by the app will in JSON format.
* Security requirements are work in progress.
+
** Resources fetched through the DHIS2 api will be in JSON format.
 
 
''List of technologies and frameworks we (likely) will use:''
 
 
 
*JavaScript (jQuery)
 
*JSON
 
*CSS3
 
*HTML5
 
*AJAX
 
*DHIS2 web API
 
  
 
= Time schedule =
 
= Time schedule =
Line 55: Line 58:
 
*Finished, if applicable also with the mobile app
 
*Finished, if applicable also with the mobile app
  
 +
'''Milestone 4: 11th December'''
 +
* Final delivery
  
= How you are dividing tasks within the group =
+
= Documented learning during project =
 +
We have:
 +
* Gained a better understanding of DHIS2, and how to use the DHIS2 API.
 +
** Specifically, we have gained insight into the different resources that are provided by the api, such as dataElements, users, and userGroups.
 +
* Learned how to develop apps for DHIS2.
 +
* Learned to use Git as version control system for the development, enabling synchronization and coordination of source code.
 +
* Gained experience in using HTML5, JavaScript, AJAX, JSON, jQuery and CSS3 to make web apps.
 +
 
 +
= How we have divided tasks within the group =
 
''Planning phase''  
 
''Planning phase''  
* Figure out how to implement the app. All questions are addressed by all members of the team.
+
* Figure out how to implement the app, and determine a rough schedule. All members collaborate. The following questions had to be addressed:
 
** How do we implement the submission form?
 
** How do we implement the submission form?
 
*** How do we validate the input fields?
 
*** How do we validate the input fields?
Line 64: Line 77:
 
** How do we generate and send a message based on contents of the form?
 
** How do we generate and send a message based on contents of the form?
 
** How do we implement a storage for commodities, or, what database to pull from?
 
** How do we implement a storage for commodities, or, what database to pull from?
** How do we identify the type of user and change the content on the main page based on this?
 
 
*** What commodities exist and which should be accessible to each type of user?
 
*** What commodities exist and which should be accessible to each type of user?
*** What types of users exist?
+
*** What types of users/roles exist in the DHIS2 "universe"?
** How do we store sent messages in the user's outbox?
+
''Requirements Phase''
 +
* Establish requirements. All members collaborated; Thomas documented them.
 +
 
 +
''Design Phase''
 +
* Determine app architecture, and interface layout. All members collaborated.
 +
 
 +
Implementation phase
 +
* UI layout in HTML and CSS (Jørgen).
 +
* Interface to DHIS2 web api (Simen and Thomas).
 +
* Messaging (Everyone).
 +
* Form validation (Simen).
  
 
= Screenshots and screen flows =
 
= Screenshots and screen flows =
 +
<gallery>
 +
Whiteboarding.jpg
 +
DeliciousCake1.png
 +
DeliciousCake2.png
 +
Lmis4.png
 +
flow_submit_order.png
  
[[File:deliciousCake1.png]]
 
 
''First version of the commodity form''
 
  
[[File:deliciousCake2.png]]
+
</gallery>
  
''Second version of the commodity form''
+
= Suggested improvements to API =
 +
* New messages should automatically be marked as unread.
 +
* There should be a easy way to request the ID's of higher management in a given org. unit.
  
= Link to repository=
+
= Link to repository =
[https://jorgeval@bitbucket.org/deliciouscake2/deliciouscake.git jorgeval@bitbucket.org/deliciouscake2/deliciouscake.git]
+
[https://bitbucket.org/deliciouscake2/deliciouscake.git https://bitbucket.org/deliciouscake2/deliciouscake.git]

Latest revision as of 14:27, 15 December 2015

Project details

Logistics Management Information System (LMIS) Light

The goal for the project is to replace the current paper based system for ordering commodities with a web-based app connected to DHIS2. This will enable users to submit orders to higher managements more efficiently than when using today's system. On one side the app is a simple web-based form where the health workers can fill in orders. On the other side the app is a notification system, where the management can be notified of order requests.

List of group members

Name Email
Simen Røste Odden simenrod@ifi.uio.no
Thomas Schwitalla thoschwi@ifi.uio.no
Jørgen Valen jorgeval@ifi.uio.no

Summary of requirements

Functional requirements:

  • A: The app's main page must contain a form for the submission of commodity orders.
    • A1: The input fields of the form must accept quantities given by positive integers of the requested commodities. It must be possible to enter values both by clicking buttons that increment or decrement quantities, and by entering values directly from keyboard/numpad.
    • A2: The form must provide the entire selection of commodities available from the resource "Life-Saving Commodities".
    • A3: There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before a message may be generated and sent to the DHIS2 messageConversation resource.
      • A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced.
        • A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending.
          • Upon the submission of an order, if any fields do not contain a valid entry, an error message in the summary must provide instructions for the correct format or valid inputs next to the invalidated field(s). No message can be sent in such a case.
          • Entirely empty orders are invalid. In case of such a submission, the summary must display an error message prompting the user to review .
        • Upon the submission of a valid order, a button labeled "Send order" must be displayed under the summary table. On click, this button must generate and send the message to the appropriate recipients.
          • The "appropriate recipients" are defined as those roles that are related to the higher management of the current user's organisation unit.
  • B: The Order message, subject "Commodity Order ", must contain in its body the list of each selected commodity and their respective quantities.
    • B1: The message must also display the submission date and the name of the sender.
    • B2: Upon successful sending of an order, on-screen feedback must inform that the order has been placed.
      • B2a: Additionally in this case, a confirmation message must be sent to the user's message inbox. This message, subject "Commodity Order Confirmation", must state the exact quantities of each ordered commodity.
        • An on-screen feedback message must inform that the confirmation message can now be found in the user's inbox.
    • B3: Upon unsuccessful sending, on-screen feedback must inform that the order was now placed, and that the user should try again.
      • B3a: The feedback must include any error codes available for debugging purposes.

Non-functional requirements

  • Process requirements:
    • App will be developed in JavaScript + jQuery, and HTML/CSS.
    • The messages generated and sent by the app will in JSON format.
    • Resources fetched through the DHIS2 api will be in JSON format.

Time schedule

Milestone 1: November 8th

  • Document features and architecture on Wiki
  • Show understanding of DHIS2 web apps

Milestone 2: November 22th

  • First bare-bone version - static HTML
  • Uploadable as DHIS2 web app

Milestone 3: December 4th

  • Finished, if applicable also with the mobile app

Milestone 4: 11th December

  • Final delivery

Documented learning during project

We have:

  • Gained a better understanding of DHIS2, and how to use the DHIS2 API.
    • Specifically, we have gained insight into the different resources that are provided by the api, such as dataElements, users, and userGroups.
  • Learned how to develop apps for DHIS2.
  • Learned to use Git as version control system for the development, enabling synchronization and coordination of source code.
  • Gained experience in using HTML5, JavaScript, AJAX, JSON, jQuery and CSS3 to make web apps.

How we have divided tasks within the group

Planning phase

  • Figure out how to implement the app, and determine a rough schedule. All members collaborate. The following questions had to be addressed:
    • How do we implement the submission form?
      • How do we validate the input fields?
      • How do we generate a JSON or XML from the form?
    • How do we generate and send a message based on contents of the form?
    • How do we implement a storage for commodities, or, what database to pull from?
      • What commodities exist and which should be accessible to each type of user?
      • What types of users/roles exist in the DHIS2 "universe"?

Requirements Phase

  • Establish requirements. All members collaborated; Thomas documented them.

Design Phase

  • Determine app architecture, and interface layout. All members collaborated.

Implementation phase

  • UI layout in HTML and CSS (Jørgen).
  • Interface to DHIS2 web api (Simen and Thomas).
  • Messaging (Everyone).
  • Form validation (Simen).

Screenshots and screen flows

Suggested improvements to API

  • New messages should automatically be marked as unread.
  • There should be a easy way to request the ID's of higher management in a given org. unit.

Link to repository

https://bitbucket.org/deliciouscake2/deliciouscake.git