dhis2-users team mailing list archive

[Lars Kristian Roland <lars@xxxxxxxxx>]

A slight detour of the thread, but how about a server side apps part for
gsoc. So we can process the web api on the server on behalf of the client.
For non javascript enabled clients such as SMS and mobile light? Server
side javascript or other...

And a json db for apps would be nice. Instead of just settings... That
would have been good during the inf5750 group work.

Lars
15. feb. 2014 20:06 skrev "Saptarshi Purkayastha" <sunbiz@xxxxxxxxx>
følgende:

> 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
>>
>>
>
> _______________________________________________
> 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
>
>