On Fri, Jun 11, 2010 at 12:12 PM, Ola Hodne Titlestad <olati...@gmail.com>wrote:
> > On 11 June 2010 11:50, Abyot Gizaw <aby...@gmail.com> wrote: > >> >> >> On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad >> <olati...@gmail.com>wrote: >> >>> Hi Abyot, >>> >>> It sounds like you didn't get my point. >>> >>> What I was trying to say is that we need to be flexible, as today, in >>> allowing the user to define the sections and add data elements to these >>> sections freely, with the constraints being: >>> - data elements and their sections must belong to the dataset (obviously) >>> - data elements in one section must share the same catcombo >>> BUT there can be many sections with the same catcombo, which often >>> happens with the default (can't believe we still use that silly name) >>> catcombo. >>> >> >> "a section to have only one categorycombo" --- Abyot >> "data elements in one section must share the same catcombo" ... Ola >> >> I think we are talking the same thing. >> >> On that constraint we agree yes. > > I think we differ when it comes to how sections are created. I still think > we should leave it to the user completely. If there are no sections defined > for a dataset then the default form is created as today, which is one table > per catcombo. I think it should be up to the user to define extra sections > in the form and thereby control how many data elements that go into each of > them, the order of data elements within each section, as well as which > fields should be greyed out in each section. > > From what you are saying it seems you want some kind of logic built in to > the system to create sections when the user hasn't defined any. I don't > think we need that. At least not in this first round of trying to improve > the form design. > I guess we are talking the same thing.... > > Ola > --------- > > > > > In addition to the above constraint we can break a section by size of >> dataelements or some public health logic. Because for example putting all >> dataelements of a dataset (that belong to a given categorycombo) in one >> section might lead to a large of scrollable section area --- we can break >> such a section into smaller pieces. that is what you mean by >> "there can be many sections with the same catcombo, which often happens >> with the default "...... >> >> How we break such a section could be based on number of dataelements, or >> some public health logic --- what size? what logic?... it is up to the users >> to define that - there will be no hard coding or automatic table generation. >> Of course we will generate the tables automatically if there are no sections >> defined. >> >> >> As to the naming ..... please feel free to suggest any name (including >> Knut's comment for Section Vs Form) >> >> >> Thank you >> Abyot. >> >> >> >>> So I am not saying that sections should be created per catcombo, I am >>> saying that which data elements belong to which section is up to the user to >>> define. I guess that is what you call "number of data elements". >>> >>> And then in the data entry screen you will create one table per section. >>> If you create one table per catcombo, as today, then my example from Sierra >>> Leone will not be supported, where the form has multiple tables using the >>> default catcombo. That is why I asked for this functionality in the first >>> place..... I think this is already well documented on this list over the >>> past months. >>> >>> I hope this is clear now. >>> >>> Ola >>> --------- >>> >>> >>> On 10 June 2010 20:30, Abyot Gizaw <aby...@gmail.com> wrote: >>> >>>> Thank you Ola, I got your points. >>>> >>>> With the lists I was proposing which one to use .... so you are >>>> suggesting categorycombo. meaning a section to have only one categorycombo. >>>> and also public health logic which is effectively number of dataelements ? >>>> >>>> yes ... graying out of a cell will also be implemented. >>>> >>>> Abyot. >>>> >>>> >>>> On Thu, Jun 10, 2010 at 5:51 PM, Ola Hodne Titlestad < >>>> olati...@gmail.com> wrote: >>>> >>>>> Hi Abyot, >>>>> >>>>> I would like to freely group data elements of a dataset into sections >>>>> and have these sections be displayed as separate tables on a data entry >>>>> screen with an optional heading for each of them. >>>>> I don't think we need to restrict to one or more of your numbered items >>>>> below. A key restriction for me would be to only allow one catcombo per >>>>> section, if not you will not be able to auto-generate the tables. >>>>> >>>>> To me the main point of this functionality is to as much as possible >>>>> avoid having to design custom forms, especially when the forms you are >>>>> dealing with are tabular and somewhat logically built up. >>>>> >>>>> Many of the forms we were designing in Sierra Leone recently had >>>>> multiple tables, some with more than one column, some with only one >>>>> column. >>>>> That means some sections would have a catcombo corresponding to many >>>>> columns, like: >>>>> | Data Element | < 5, male | < 5, female | > 5, male | <5 female | >>>>> >>>>> while other tables were made up of data elements with the default >>>>> catcombo, on the type: >>>>> | Data Element | Value | >>>>> >>>>> But we would typically have multiple tables (aka sections) which had >>>>> the default catcombo that were separated due to their public health >>>>> program >>>>> or subprogram (ANC, Deliveries, Pregnancy complications etc.), and each of >>>>> these would have their own heading. >>>>> >>>>> So to use your words, the baseline to divide the data entry screen (I >>>>> assume you mean how to build sections) in our case could not be >>>>> automatically generated, but in stead the user had to manually create the >>>>> sections and add data elements to these. What guides the user will then be >>>>> the various tables on the paper form. >>>>> >>>>> In addition to be able to auto generate those tables in the data entry >>>>> screen I would like to freely set the order of the tables/sections and for >>>>> each table/section specify which fields that need to be greyed out on the >>>>> data entry screen. >>>>> >>>>> The tables can be listed one by one under each other, at least as the >>>>> first basic step. Being able to put tables next to each other horizontally >>>>> would be a bonus, but the vertical order of tables is more important. >>>>> >>>>> Hope this helps to clarify the needs. >>>>> >>>>> Ola >>>>> ---------- >>>>> >>>>> >>>>> >>>>> >>>>> Ola Hodne Titlestad |Technical Officer| >>>>> Health Metrics Network (HMN) | World Health Organization >>>>> Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: >>>>> titlest...@who.int|Tel: +41 788216897 >>>>> Website: www.healthmetricsnetwork.org >>>>> >>>>> Better Information. Better Decisions. Better Health. >>>>> >>>>> >>>>> On 9 June 2010 11:28, Abyot Gizaw <aby...@gmail.com> wrote: >>>>> >>>>>> Hi Dears, >>>>>> >>>>>> Just wanted to have your inputs ... >>>>>> >>>>>> Currently I am working on sections - simply dividing dataentry screens >>>>>> into sections, disabling/enabling dataentry cells (grayed fields) and >>>>>> stuff >>>>>> like that. I will take off from the existing section >>>>>> code/functionality.... >>>>>> so a question I have is - what is the base line to divide a dataentry >>>>>> screen: >>>>>> >>>>>> >>>>>> 1. number of dataelements - like display area? >>>>>> 2. categorycombo - for example nice looking uniform table heading? >>>>>> >>>>>> 3. some kind of public health logic - for example dividing disease >>>>>> collection form into - airborne, waterborne,.... disease ? >>>>>> 4. ..... >>>>>> >>>>>> Thank you >>>>>> Abyot. >>>>>> _______________________________________________ >>>>>> Mailing list: >>>>>> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >>>>>> Post to : dhis2-devs@lists.launchpad.net >>>>>> Unsubscribe : >>>>>> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
