sectioning a paper form/dataset

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.

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@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

I was just about to suggest the "graying" out of certain cells. We
have some data elements in Zambia that generally correspond to a
catcombo, but for some reasons, are not actually recorded. For
instance the data element "Hypertension" is only recorded for the age
group "Over 5" although all the other data elements on the form are
collected with "Under 1", and "1-5" age groups. There must be some way
to indicate that these catcombos are not applicable and should not be
included. Another option/workaround, would be to generate the default
grid data entry form, and the just have the form implementer remove
them. However, this would really not be the most ideal solution.

I have not had a chance to read the document yet, but will provide
some more feedback when I get a chance.

Regards,
Jason

···

On Thu, Jun 10, 2010 at 8:30 PM, Abyot Gizaw <abyota@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 <olatitle@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:
titlestado@who.int|Tel: +41 788216897
Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw <abyota@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:

number of dataelements - like display area?
categorycombo - for example nice looking uniform table heading?
some kind of public health logic - for example dividing disease
collection form into - airborne, waterborne,.... disease ?
.....

Thank you
Abyot.
_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

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

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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.

···

On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-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

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@gmail.com

On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad olatitle@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.

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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-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

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.

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.

···

On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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

···

On 11 June 2010 11:50, Abyot Gizaw abyota@gmail.com wrote:

On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad olatitle@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.


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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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…

···

On Fri, Jun 11, 2010 at 12:12 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

On 11 June 2010 11:50, Abyot Gizaw abyota@gmail.com wrote:

On Fri, Jun 11, 2010 at 9:05 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

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@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 olatitle@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: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

On 9 June 2010 11:28, Abyot Gizaw abyota@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

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp