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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> Thanks for the thoughts, Jim. Some comments below. >>> >>> On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> *Date: *Sat, 15 Feb 2014 16:30:30 +0800 (SGT) >>>>> *To: *[email protected]<[email protected]>; Knut Staring< >>>>> [email protected]>; Dhis2-users<dhis2-users-bounces+alvin.marcelo= >>>>> [email protected]>; [email protected]< >>>>> [email protected]> >>>>> *ReplyTo: * Brajesh Murari <[email protected]> >>>>> *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 < >>>>> [email protected]> 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" <[email protected]> >>>>> Date: Sat, 15 Feb 2014 07:41:03 >>>>> To: Knut Staring<[email protected]>; >>>>> Dhis2-users<dhis2-users-bounces+alvin.marcelo= >>>>> [email protected]>; [email protected]< >>>>> [email protected]> >>>>> Reply-To: [email protected] >>>>> 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 <[email protected]> >>>>> Sender: "Dhis2-users" >>>>> <[email protected]>Date: >>>>> Sat, 15 Feb 2014 08:16:23 >>>>> To: [email protected]<[email protected]> >>>>> Subject: [Dhis2-users] Maps of outbreaks >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-users >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dhis2-users >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-users >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dhis2-users >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-users >>>>> Post to : [email protected] >>>>> 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 : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
