dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

On Fri, Jun 11, 2010 at 12:12 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:

>
> On 11 June 2010 11:50, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>
>>
>>
>> On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>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 <abyota@xxxxxxxxx> 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 <
>>>> olatitle@xxxxxxxxx> 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:
>>>>> titlestado@xxxxxxx|Tel: +41 788216897
>>>>> Website: www.healthmetricsnetwork.org
>>>>>
>>>>> Better Information. Better Decisions. Better Health.
>>>>>
>>>>>
>>>>> On 9 June 2010 11:28, Abyot Gizaw <abyota@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>