← Back to team overview

dhis2-devs team mailing list archive

Re: sectioning a paper form/dataset

 

If we all agree then perfect!

Look forward to test and starting to use this functionality.

BTW, I think some optional shading on the generated table headers and column
headings might be a small (I assume) thing to add that would make a big
difference to the users.

Ola
-----------

2010/6/11 Lars Helge Øverland <larshelge@xxxxxxxxx>

>
>
> 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.
>>
>> 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".
>>
>>
> I think that is what Abyot is saying. Automatically creating a "form
> section" per category combo is what we are doing today. Which data elements
> to include in a section will be user editable in the new version. Abyot's
> point is that the data elements which the user selects will have to share
> the same category combo.
>
>
>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>

References