DHIS Mobile - UI Feedback

Support - Assistance technique
1

Hi,

Have done a complete revamp of the mobile client application. Earlier we used simple MIDP 2.0 components and required programming the form. The form was simple, but required JavaME knowledge. New code can be downloaded from here.

The new approach has few advantages:

1.) Can be generated from DHIS2 by selecting datasets/data elements (No JavaME programming required)

2.) Completely maven-ized. No need for ant

3.) Looks same on all phones (earlier had issues with low-end Nokia phones which truncated textfield labels)

4.) Works on the cheapest currently manufactured java-enabled phone (tested with Nokia 1680)

5.) Can be used to report patient program stage data elements

6.) No separate SMS Listener. Inside DHIS 2 web server. (needs some more work)

Issues:

1.) Requires WTK libraries, which can be installed part of Sun WTK on the DHIS 2 server, but the war file remains unaffected

2.) Requires health workers to download full application on phone, even if only 1 data element is changed in the dataset

Attached are screenshots of the UI on which I need some comments. The UI is more customizable now and has calendar, themes, drop-downs, lists etc. Only 2-button interface, because some phones may not have the middle button.

The web-module is still under-development and plan is to release the full-package pre-beta version on 15th March after which, we can test, comment and get a direction to where we should take the mobile application. I don’t think SMS are the best way to send patient data. Atleast not for the number of elements and number of patients in Indian context. For which I suggest XForms are the best way forward.

image

image

image

image

image

image

image

image

···

Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

2

Hi Saptarshi

Hi,
Have done a complete revamp of the mobile client application. Earlier we
used simple MIDP 2.0 components and required programming the form. The form
was simple, but required JavaME knowledge. New code can be downloaded from
here.

I didn't get the "here" link :frowning: Please check - mybe my mail client.
But the screenshots look promising. Probably have to key through it
to really get a feeling.

The new approach has few advantages:
1.) Can be generated from DHIS2 by selecting datasets/data elements (No
JavaME programming required)
2.) Completely maven-ized. No need for ant
3.) Looks same on all phones (earlier had issues with low-end Nokia phones
which truncated textfield labels)
4.) Works on the cheapest currently manufactured java-enabled phone (tested
with Nokia 1680)
5.) Can be used to report patient program stage data elements
6.) No separate SMS Listener. Inside DHIS 2 web server. (needs some more
work)

What are the security considerations here? Will you be relying on the
closed user group? I know you have really packed a lot into the sms
format you have devised - is there space in their for any sort of
identifier (for audit purposes)? I don't have the answers to all of
these. Just firing off the questions :slight_smile:

Issues:
1.) Requires WTK libraries, which can be installed part of Sun WTK on the
DHIS 2 server, but the war file remains unaffected
2.) Requires health workers to download full application on phone, even if
only 1 data element is changed in the dataset
Attached are screenshots of the UI on which I need some comments. The UI is
more customizable now and has calendar, themes, drop-downs, lists etc. Only
2-button interface, because some phones may not have the middle button.
The web-module is still under-development and plan is to release the
full-package pre-beta version on 15th March after which, we can test,
comment and get a direction to where we should take the mobile application.
I don't think SMS are the best way to send patient data. Atleast not for the
number of elements and number of patients in Indian context. For which I
suggest XForms are the best way forward.

Yes that should also address issue number 2 above. I guess you are
planning http (or better https with client certificate
authentication)?

good stuff.

Bob

···

On 5 March 2010 17:50, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

3

Probably the here didnt like the lp link: https://code.launchpad.net/~sunbiz/+junk/javame_src

···

Regards,
Saptarshi PURKAYASTHA

Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

On 5 March 2010 21:40, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Saptarshi

On 5 March 2010 17:50, Saptarshi Purkayastha sunbiz@gmail.com wrote:

Hi,

Have done a complete revamp of the mobile client application. Earlier we

used simple MIDP 2.0 components and required programming the form. The form

was simple, but required JavaME knowledge. New code can be downloaded from

here.

I didn’t get the “here” link :frowning: Please check - mybe my mail client.

But the screenshots look promising. Probably have to key through it

to really get a feeling.

The new approach has few advantages:

1.) Can be generated from DHIS2 by selecting datasets/data elements (No

JavaME programming required)

2.) Completely maven-ized. No need for ant

3.) Looks same on all phones (earlier had issues with low-end Nokia phones

which truncated textfield labels)

4.) Works on the cheapest currently manufactured java-enabled phone (tested

with Nokia 1680)

5.) Can be used to report patient program stage data elements

6.) No separate SMS Listener. Inside DHIS 2 web server. (needs some more

work)

What are the security considerations here? Will you be relying on the

closed user group? I know you have really packed a lot into the sms

format you have devised - is there space in their for any sort of

identifier (for audit purposes)? I don’t have the answers to all of

these. Just firing off the questions :slight_smile:

Issues:

1.) Requires WTK libraries, which can be installed part of Sun WTK on the

DHIS 2 server, but the war file remains unaffected

2.) Requires health workers to download full application on phone, even if

only 1 data element is changed in the dataset

Attached are screenshots of the UI on which I need some comments. The UI is

more customizable now and has calendar, themes, drop-downs, lists etc. Only

2-button interface, because some phones may not have the middle button.

The web-module is still under-development and plan is to release the

full-package pre-beta version on 15th March after which, we can test,

comment and get a direction to where we should take the mobile application.

I don’t think SMS are the best way to send patient data. Atleast not for the

number of elements and number of patients in Indian context. For which I

suggest XForms are the best way forward.

Yes that should also address issue number 2 above. I guess you are

planning http (or better https with client certificate

authentication)?

good stuff.

Bob

Regards,

Saptarshi PURKAYASTHA

Director R & D, HISP India

Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

4

Hi Saptarshi,

nice work… Any chance we can push this code to trunk? We already have a mobile subdir in there…

Lars