Groups tasks

This page proposes a range of possible topics for the group work. The idea is that 4-5 people should work together on developing a solution that should be finished enough and have a high enough quality to be included in DHIS.

The projects vary a lot in complexity, the tools mainly used and the work load that must be expected of the group. Generally the android and html5 projects are more explorative and experimental and will demand more work than the more defined task focussing on new functionality in the mobile browser. For those that want to get a better feel for "enterprise" server side java, and how to build more complex solutions, should probably look at the "server side".

For the initial process of assigning students to groups, send me a mail with three projects you would to prefer to work on, in prioritized order. If you it is more important for you to work with someone than exactly what you work on, tell me. I'll do my best to fulfill the wishes, though I can't promise anything.

I'll try to have the groups ready by the next lecture, October 12th, try to send me your wishes before then.

Mobile browser module

The mobile browser solution is a new addition to DHIS. The primary goal is to provide simple to use browser based functionality for the low-end feature phones people have in the context DHIS is used.

In this context smart phones are still just emerging, so a design goal for this functionality is to work well with feature phones running some version of opera mini or a built-in browser.

Functionality for doing aggregate data entry has already been built, and can serve as a good template to get started. The projects should be integrated into this module (dhis light), and should be implemented as separate home screen menu choices.

Part of the work should be defining the right UI and testing it on various devices, taking into account screen real-estate, latency etc. The solution should be workable on non-javascript devices as well as higher end mobile browsers, but pages must be small enough to be usable on low-end.

In addition to this we want to explore two cases around communication between people, on is to enable DHIS' messaging support and the other is to provide address book type behaviour to find phone number for other health workers.

1. Single events

This project is to build a solution for reporting on single events, for example reporting of a birth or a death.

Some sketches of the ui flow is coming.. 

2. Program-based tracking

Program-based tracking is designed for following beneficiaries through a defined health program. The typical case is following pregnancies (Antenatal care) and vaccination of childern. The beneficiaries (the mother/child) is registered in the system and enrolled in a program consisting of stages to go through. The system generates activity plans for the health workers, which are integrated into the solution.

This functionality has already been developed as a Java ME application, and this app can be used as a template for the functionality to support.

Som screen shots coming...

3. Messaging support

4. Address book

The idea here is to provide an interface for browsing and using the information dhis has about the users and how to contact them.

See powerpoint illustration

5. Reporting feedback

DHIS is focussed around the collection of aggregate data, eg. "number of malaria cases this month", and the goal of this project is to build a solution giving useful feedback to the health workers reporting data on a mobile phone. The health workers are very used to the notion of having the fill in and send reports, but they rarely see any results from this reporting, at least not information useful for them.

See the gui proposal.

"Android phones"

While smart phones are not common yet in the context DHIS is mostly used, cheap Android phones have started to emerge in many countries, and we want to explore how best to support these more advanced phones with bigger screens, touch and so on. 

There are three types of approaches that we want to explore. In addition, there is also an interesting project looking at using an android phone as a proxy between mobile phones sending SMSes and the DHIS web instance

6. Enhancing mobile browser data-entry functionality for HTML5-capable clients

Even if the basic level of support in the mobile browser module has to be feature phone browsers, it should be possible to progressively enhance the functionality to support.

7. DHIS dataentry with offline support using a HTML5 framework

One of the big advantages of HTML5 is the possibility local storage support in the browser, making it possible to do data-entry also when the client is not online.

This has already been implemented in the standard dhis data entry, and the goal of this project is to build a similar capability in a solution targetting the android smart phone browser.

8. Android app for DHIS data entry and more

While an HTML5 approach with offline support seems to be the simplest approach to creating a solution for android phones, creating a native app does give access to a lot of functionality and apis not available in the browser. The challenge for the group doing this project is to try to come up with a solution that has significant advantages over HTML5.

9. Implement a DHIS2 Android Server for SMS

Implement something similar to the ushahidi smssync that would have the functionality to receive data as SMS and write dxf files for import into DHIS2. It should also have functionality for posting to a configured DHIS2 instance through the web-api.This will be useful for bootstrapping small mobile-based implementations where there is a lack of robust infrastructure.

Learn more at this Ushahidi blog entry, and see their source code

"Server side"

10. Map generation service

Create a self-contained map representation of DHIS aggregate data.

Input criteria should be :

• a single indicator
• period
• parent organisation unit (with more than one child).
• Hard coded to 5 intervals

The representation should be a standard image format, like SVG or PNG. It must be
must be possible to embed directly in any web page without dependencies on external javascript/client-side frameworks, and it would also be advantageous if the image could be included in generated PDF reports and so on. If it is necessary, the representation could be a self-contained javascript. The map also needs a legend, which should ideally be available as a separate image or combined with the map.

• Get the datavalues given DE, Catcombo, Period, and a specific set of OUs (initially defined as the immediate children of an OU, maybe more generic later)
• Calculate the right color for each OU
• Get the coordinates in GeoJSON format, convert to SVG formatted snippets
• Add everything into a full SVG file with color and coordinates for each polygon
• Parameter to say if the output should be SVG. If not, send to Batik for PNG

http://docs.geotools.org/latest/userguide/tutorial/quickstart/maven.html

11. API supporting existing mobile client solutions

• using JAX-B for serialising the java model of data sets into xforms
• building a web api to offer these to clients
• building an api for receiving filled in xforms, validate and persist the data