dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

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.

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