dhis2-users team mailing list archive

[Saptarshi Purkayastha <sunbiz@xxxxxxxxx>]

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.<appname>.<settingkey> can be managed through the
app's UI

---
Regards,
Saptarshi PURKAYASTHA


On 16 February 2014 00:23, Knut Staring <knutst@xxxxxxxxx> 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
>
>
> On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace <jimgrace@xxxxxxxxx> 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.)
>>
>> Cheers,
>> Jim
>>
>>
>> On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring <knutst@xxxxxxxxx> wrote:
>>
>>> Thanks for the thoughts, Jim. Some comments below.
>>>
>>> On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace <jimgrace@xxxxxxxxx> 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
>>>>
>>>>
>>>>
>>>> On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo <
>>>> alvin.marcelo@xxxxxxxxx> 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@xxxxxxxxx>
>>>>> *Date: *Sat, 15 Feb 2014 16:30:30 +0800 (SGT)
>>>>> *To: *alvin.marcelo@xxxxxxxxx<alvin.marcelo@xxxxxxxxx>; Knut Staring<
>>>>> knutst@xxxxxxxxx>; Dhis2-users<dhis2-users-bounces+alvin.marcelo=
>>>>> gmail.com@xxxxxxxxxxxxxxxxxxx>; dhis2-users@xxxxxxxxxxxxxxxxxxx<
>>>>> dhis2-users@xxxxxxxxxxxxxxxxxxx>
>>>>> *ReplyTo: * Brajesh Murari <brajesh.murari@xxxxxxxxx>
>>>>> *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@xxxxxxxxx> 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@xxxxxxxxx>
>>>>> Date: Sat, 15 Feb 2014 07:41:03
>>>>> To: Knut Staring<knutst@xxxxxxxxx>;
>>>>> Dhis2-users<dhis2-users-bounces+alvin.marcelo=
>>>>> gmail.com@xxxxxxxxxxxxxxxxxxx>; dhis2-users@xxxxxxxxxxxxxxxxxxx<
>>>>> dhis2-users@xxxxxxxxxxxxxxxxxxx>
>>>>> Reply-To: alvin.marcelo@xxxxxxxxx
>>>>> 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@xxxxxxxxx>
>>>>> Sender: "Dhis2-users"
>>>>> <dhis2-users-bounces+alvin.marcelo=gmail.com@xxxxxxxxxxxxxxxxxxx>Date:
>>>>> Sat, 15 Feb 2014 08:16:23
>>>>> To: dhis2-users@xxxxxxxxxxxxxxxxxxx<dhis2-users@xxxxxxxxxxxxxxxxxxx>
>>>>> Subject: [Dhis2-users] Maps of outbreaks
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>> Post to    : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>> More help  : https://help.launchpad.net/ListHelp
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>> Post to    : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>> More help  : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Knut Staring
>>> Dept. of Informatics, University of Oslo
>>> +4791880522
>>> http://dhis2.org
>>>
>>
>>
>
>
> --
> Knut Staring
> Dept. of Informatics, University of Oslo
> +4791880522
> http://dhis2.org
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-users
> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-users
> More help   : https://help.launchpad.net/ListHelp
>
>