- 1 List of Group Members
- 2 Application Structure
- 3 Summary of Requirements
- 4 Time Schedule
- 5 Task Division
- 6 Screenshots and Screen Flows
- 7 Documented Learning During Project
- 8 Suggested Improvements
- 9 Link to Repository
- 10 Download Link to Sample Web App or Android App
- 11 Questions and Suggestions:
List of Group Members
- Bård Winther (baardew) email@example.com
- Henrik Tufte Lien (henriktl) firstname.lastname@example.org
- Jonas Sandnes (jonsandn) email@example.com
- swati sharma (swatis) firstname.lastname@example.org
Organization of program structure using MVVM:
TDD is a must: QUnit is currently used, but if it proves to be insufficient then Protactor may be an option to add as well. During development, we found no need for additional testing, as angular was best inspected manually.
Attempt to solve the problem with a generic implementation that parses any json object and displays it on screen.
CSS specific for every view, check out: http://plnkr.co/edit/oWw3QUc9P4leo0gO5EzL?p=preview
The GUI laytout describes the three different methods of viewing the content. Each view is switchable in the same main page. Presented below is the mockup, see next section for actual results.
Api index (listing the resources)
Resource view (list of objects)
This view shows a list of all objects in the selected resource.
This view presents detailed information about a specific chosen object.
It consists of several tables presented as one of the following:
- Table as a list of key and values.
- Table containing columns and rows.
The view itself is structured as 4 components as in the order below:
1) Detailed general information: Date of birth, last updated, email etc.
2) Access rights: 5 boolean variables defined as true or false.
3) Groups: A set of groups that is related to the object.
4) Related objects or additional information.
1) and 4) are presented as lists, whereas 2) and 3) have rows and columns.
In addition, the two first components are always present for every object. The last two, however, are optional and there may be several groups for each object.
Summary of Requirements
List is in prioritized order
- Display every possible path obtained by click-through of API (in other words, every link should be "followable")
- User friendly, which implies: no need for direct keyboard input, all information readily avaiable (no hidden content) and simple to retrace steps
- The program should deal with errors and misuse correctly and elegantly (in other words, not crash if someone does something un-expected)
These milestones are guidelines only, except for 3rd December.
- 1. nov : design layout finished
- 8. nov : static html layout presentable
- 29. nov : main work done
- 3. dec : hard deadline
baardew: backend controller and configuration + additional frontend where required
henriktl: Resource list view
jonsandn: Object view
swatis: Api index view
Screenshots and Screen Flows
Documented Learning During Project
- Learned to configure AngularJS views and linking it with other project resources.
- Learned the DHIS API.
- Display the path of clicks for easier navigation. Not included as most of the time the path taken is quite shallow.
Link to Repository
Download Link to Sample Web App or Android App
< NOT APPLICABLE >
Questions and Suggestions:
While the DHIS API is intuitive and easy to follow, it would be nice to have one place where the content of each module is described. Reffering to the question: "Could not find the API for data model fields (https://www.dhis2.org/doc/snapshot/en/user/html/apes04.html)"