Several people have asked for the link to the Google doc, and I have added them to the list of editors. I also changed the permissions to allow anyone to read it. These are some random thoughts I have had about the whole categories/combos/options. Your mileage may vary.
I have some more thoughts which I will add when I get a chance, after this email, but feel free to add your thoughts as well to the doc. Once we reach some consensus, if ever, perhaps this can evolve into a more specific blueprint. Here is the link... https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en On 12/7/10, Bob Jolliffe <[email protected]> wrote: > On 7 December 2010 10:17, Ola Hodne Titlestad <[email protected]> wrote: >> On 7 December 2010 10:41, Bob Jolliffe <[email protected]> wrote: >>> >>> there seem to be 3 primary motivations for an implementor to use >>> categories >>> (i) it can make auto-generated forms do what you want >>> (ii) it reduces the number of dataelements you have to design >>> (iii) it provides an axis for analysis >>> >>> In the best of cases these three conspire together to produce a good >>> result. eg datavalues which are collected disaggregated by sex. >>> >>> In other cases the benefits of (i) are so compelling that the fact >>> that (iii) is not consistent is not considered. I've seen a few >>> proposed solutions to this (I think most recently a setting which >>> indicates whether a category is a "summing" category or not). Not >>> sure if I'm too happy with any of them, but one observation is that in >>> almost all cases I've seen this occur, it is related to >>> stock/inventory. This might just be a coincidence but sure looks like >>> a pattern to me. perhaps there might be a point in recognizing the >>> special case of inventory and make a small inventory module rather >>> than handling through "standard" data entry. >>> >> >> In Kenya it is actually the human resources form that is the problem. They >> repeat 10 columns (that do not add up) over about 40-50 different cadres, >> so >> many data elements. > > OK. I guess HR, like inventory, proceeds with its own logic which is > hard to completely capture in a simple data collection model. > > I do also find myself agreeing with you that in a situation like this > and given current concrete reality, it should be better practice to > group data collection by category rather than to proliferate so many > dataelement names. But the consequences still bother me. Will think > more later ... > > Cheers > Bob > >> But I agree that stock forms are the most common one and that we should >> look >> into better support for logistics functionality, at least the simpler >> inventory stuff that is close to our model anyway. >> I think we have put "use of calculated expressions in custom data entry" >> on >> the roadmap somewhere. These will then provide a tools for adding more >> complex calculations that are needed in the form. Of course if we limit >> this >> functionality to the custom forms, which seems easier and less complex, >> then >> we can't use the auto-generated forms anyway..... >> Ola >> >>> >>> Looking at the 4 categoryoptions there is an opening balance, amount >>> issued, amount received and avg monthly requirement in each case. As >>> well as stock reorder amounts etc associated with each dataelement. >>> Thuy seems to have done a good job in removing some of the extra >>> calculated values. Though I am not sure about average monthly >>> requirement. is that really an observation or is it calculated >>> somehow? And how do we persist things like the min/max amounts etc. >>> Anyway there seems to be a particular and repeated logic which drives >>> these stock/inventory dataelements. A stock/inventory module could >>> provide form layout based on that logic rather than on categorycombo. >>> As well as some extra data attributes for inventory related stuff >>> which would not be what we would term datelement. >>> >>> From analysis perspective the fewer the categories the better, reusing >>> categories is good and categories which don't add up are bad as they >>> create confusion and complication at the output end. >>> >>> From UI perspective, unless we can provide an alternative simple way >>> of achieving the simple tabular layout, users will continue to (ab)use >>> the categories for this. The labour saving is really just too much. >>> >>> Sorry Thuy this is a bit of a distrasction from your initial question, >>> which I see Johan is addressing :-) >>> >>> Cheers >>> Bob >>> >>> On 7 December 2010 08:23, Jason Pickering <[email protected]> >>> wrote: >>> > This has got me thinking once again what a category/combo/option >>> > actually is and how the current implementation makes too many >>> > assumptions, like that categories should add up to a total. >>> > >>> > I would suggest we continue thinking about it in background document >>> > I created a while back.. >>> > >>> > >>> > https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en >>> > >>> > >>> > On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <[email protected]> wrote: >>> >> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen >>> >> <[email protected]> wrote: >>> >>> Dear Johan, >>> >>> Thank you for your suggestions. Please scroll down to see my mail >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Dec 7, 2010 at 1:59 AM, <[email protected]> wrote: >>> >>>> >>> >>>> Dear Thuy, >>> >>>> >>> >>>> I'm not very familiar with the requirements in Sri Lanka, but I have >>> >>>> a few >>> >>>> general comments. First, the categories and combinations should be >>> >>>> used >>> >>>> when we want to aggregate them into a data element that is a natural >>> >>>> total >>> >>>> of these categories. For stock, this is usually not the case, as we >>> >>>> do not >>> >>>> want to add start balance, received, issued, and monthly requirement >>> >>>> (in >>> >>>> this case). >>> >>> >>> >>> About the total meaning of categories and categories options. I got >>> >>> the >>> >>> lesson from my mistake in Vietnam. So I didn't want to repeat again >>> >>> by >>> >>> explanation people here. But again because of the instant benefit of >>> >>> category data elements such as the defaul entry form will generate >>> >>> automatically with good form which DHIS provided. And the shorting of >>> >>> creating data elements,... So the person who do this project decided >>> >>> to use >>> >>> categories for this report as well as other reports for equipments >>> >>> like >>> >>> beds, tables,... I knew it is wrong for the meaning of categories >>> >>> which >>> >>> developers in DHIS wish to use. But I don't know serious reason for >>> >>> defense >>> >>> on this. That's why I consult you to know what will happen in the >>> >>> future >>> >>> when data base become huge if we use category options like this for >>> >>> data >>> >>> elements? Is it affecting to retrieving information later? >>> >> >>> >> Hi Thuy, >>> >> >>> >> I personally think one has to weight these things against each other. >>> >> I understand very well the desire to have nice autogenerated forms, >>> >> and I don't really see the big problem with using categories this way >>> >> AS LONG AS one bears in mind that the total will not work. I think the >>> >> major downside to doing it like this is that Pivot tables will not >>> >> work well on these dataelements, since the whole point of pivot tables >>> >> is to easily sum up - and if some of the sums are meaningless, that >>> >> restricts the usefulness of the pivot tables. >>> >> >>> >> It would be nice if it were possible to easily generate good looking >>> >> forms without violating the semantics of the aggregation model, though >>> >> I suppose that would require a decoupling of the form section >>> >> generating machinery from the data element model. One would then be >>> >> able to assign categorycombos to a section, but also group data >>> >> elements in sections external to the disaggregation model. >>> >> >>> >> Knut >>> >> >>> >> _______________________________________________ >>> >> Mailing list: https://launchpad.net/~dhis2-devs >>> >> Post to : [email protected] >>> >> Unsubscribe : https://launchpad.net/~dhis2-devs >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> > >>> > >>> > >>> > -- >>> > Jason P. Pickering >>> > email: [email protected] >>> > tel:+260968395190 >>> > >>> > _______________________________________________ >>> > Mailing list: https://launchpad.net/~dhis2-devs >>> > Post to : [email protected] >>> > Unsubscribe : https://launchpad.net/~dhis2-devs >>> > More help : https://help.launchpad.net/ListHelp >>> > >> >> > -- Jason P. Pickering email: [email protected] tel:+260968395190 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
