From mn/ifi/inf5750
Revision as of 18:46, 7 December 2014 by (talk | contribs)

Jump to: navigation, search

List of Group Members

  • Bård Winther (baardew)
  • Henrik Tufte Lien (henriktl)
  • Jonas Sandnes (jonsandn)
  • swati sharma (swatis)

Application Structure

For the remainder of this document "backend" would refer to application controller and other javascript that is not used directly with presentation. Likewise, "fronend" denote everything connected to or is GUI elements.

File layout

Organization of program structure using MVVM:

Actual architecture.png


Javascript, AngularJS, HTML and CSS. JSON for rest communication.

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:

GUI Layout:

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.

BHJS Structure.png

Api index (listing the resources)

resource view (list of objects)

Object view:

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

  1. Display every possible path obtained by click-through of API (in other words, every link should be "followable")
  2. User friendly, which implies: no need for direct keyboard input, all information readily avaiable (no hidden content) and simple to retrace steps
  3. The program should deal with errors and misuse correctly and elegantly (in other words, not crash if someone does something un-expected)

Time Schedule

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

Task Division

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.
  • Improved Javascript and angular experience.
  • Learned the DHIS API.

Suggested Improvements

  • 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


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 ("