One could indeed make an app for appsetting management since devs can already save/retrieve settings for apps by using the usersettings or systemsettings web api.
Knut, I think its quite feasible for this app to be built during gsoc 3-month timeline.
This app can also help create convention on how apps should name their settings.
Something like settings.. can be managed through the app’s UI
···
Regards,
Saptarshi PURKAYASTHA
On 16 February 2014 00:23, Knut Staring knutst@gmail.com wrote:
Thanks Jim - I will try to find time to get more Data Entry ideas into a Blueprint.
Also very much like your thoughts about extending the current bare-bones app management in DHIS2 to include configuration of each app - maybe something for GSoC?
Knut
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp
On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace jimgrace@gmail.com wrote:
Hi Knut,
Nice thoughts about more flexible data entry forms “pivoting” in different dimensions. And given how much easier the auto-generated forms are than designing your own, it would be great to expand the number of cases that one can use auto-generated forms for. Developing a detailed proposal for this sounds like a very useful effort. Any takers?
I quite agree that we should provide “tools for people who are not programmers allowing them to configure what they want”. My question about the appropriate use of apps isn’t really focused on when do we expect users to write their own. It’s more the question of when are features provided in the core vs. when are they provided in the app store.
Speaking of which, if we provide general-purpose, configurable apps in the app store, I wonder how we can provide a user-friendly way to customize app metadata through DHIS, so the user wouldn’t have to edit the manifest file inside the app. We could extend the DHIS UI to be able to configure app-specific metadata settings for an app that has been uploaded. I wonder if the app manifest itself could describe the various system settings choices to be made (e.g., the allowable numeric range of a metadata setting, the list of choices, etc.) I’m not familiar enough yet with the app manifest format to know whether it supports this already, or how awkward it might be to graft it on. I known that OpenMRS modules, for example, can add their own settings section to the OpenMRS UI, so they can be configured through OpenMRS. The end result is that the non-programmer user can simply download an OpenMRS module, install it, and then configure it through the OpenMRS UI. The equivalent for DHIS apps could be very useful. Or should the app include its own configuration screens, and the configuration data is somehow stored in DHIS? (I apologize for my lack of knowledge about apps.)
–
Knut Staring
Dept. of Informatics, University of Oslo
+4791880522
http://dhis2.org
Cheers,
Jim
On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring knutst@gmail.com wrote:
Thanks for the thoughts, Jim. Some comments below.
On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:
Hi Knut,
It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)
Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.
Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.
In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.
But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.
Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?
I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.
It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/
It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?
That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.
Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.
Knut
Cheers,
Jim
–
Knut Staring
Dept. of Informatics, University of Oslo
+4791880522
http://dhis2.org
On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:
+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…
Sent from my BB Curve 9320
From: Brajesh Murari brajesh.murari@yahoo.com
Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)
To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
ReplyTo: Brajesh Murari brajesh.murari@yahoo.com
Subject: Re: [Dhis2-users] Maps of outbreaks
Hi,
There are some synonyms for ‘outbreak’ are given below
explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,
I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.
Regards
Brajesh Murari
On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:
I’m not sure if I got the 3Cs correctly. Pls google too…
Sent from my BB Curve 9320
-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03
To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks
Hi Knut,
My two cents as we recently experienced a measles ‘outbreak’.
First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.
Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.
Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.
The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).
I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.
We’ll leave it up to the health officials to call it an outbreak.
Alvin
Sent from my BB Curve 9320
-----Original Message-----
From: Knut Staring knutst@gmail.com
Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Subject: [Dhis2-users] Maps of outbreaks
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp