Data browser functionality

Support - Assistance technique
1

Dear Devs,
I have been working to document the Maintenance section of DHIS2, and
have a few observations and would like to have some feedback before I
file, what I think should be a blueprint.

One of my big complaints about DHIS2 is that it is exceedingly
difficult to simply browse data that has been entered. One can create
a report (rather painful) or use the data entry screens to browse
data, but this too seems a bit of a kludge, when I might just want to
simply quickly view data for a given orgunit/period/dataset
combination. This is a very common operation on the part of users. I
was expecting to find this in the "Data browser", however, this is not
exactly what the data browser does, as far as I can tell. The data
browser provides a summary of the data contained in the database,
providing the number of data element values that are present, and they
can be grouped a couple of different ways. I have reviewed the
/dhis2/dhis-2/dhis-api/src/main/java/org/hisp/dhis/databrowser/DataBrowserTable.java
and also crosschecked this against the screen found at
(DHIS2 App Hub).
This appears to be a summary of the number of elements contained in a
given dataset for a given period interval. This is fine and quite
handy I guess.

Now, this is where things get tricky..

http://dhis.uio.no/demo/dhis-web-maintenance-dataadmin/searchResult.action?searchOption=DataSet&parent=233&periodType=Monthly&toDate=2009-08-31&fromDate=2009-04-01

provides a summary ( I think) of the number of data element values for
a given data element and period interval, which is also handy.

However, I feel this may be very misleading, because of the name "Data
browser". We are looking here at the "COUNT" of data element values,
not the "SUM" and not browsing the actual data values themselves. If
an untrained eye were to see the results of the URL above, it might be
very misleading. I therefore would like to suggest that we come up
with a new name for the "Data browser", but I do not really know what
it should be called. I just think that it should be clear that we are
not actually browsing data, but rather looking at a summary (namely
the number of data element values) for a particular set of parameters.

Regardless of this, I think having the functionality to simply browse
raw data itself, without having to go either through a report, or data
entry form, would be very useful. I was planning to write this up as a
blueprint, but would appreciate some comments on what I have written
here first.

Best regards,
Jason

2

I fully agree, Jason - not having an easy way to browse through the actual data other than the data entry screen is a problem.

The reason for the idea behind the “data browser” in the first place was frustration with how hard it was to find out where there actually is data when approaching e.g. the demo database (or indeed any unknown database) - the only way to find out (short of querying the db directly) was to click through a lot of periods for each dataset in the data entry screen, which is both inefficient and unintuitive. So what we have now is a pretty useful tool to locate the data, but what it lacks is an easy way to see the actual data - for that you have to make a note of where the data is, and then return to the data entry screen - talk about cumbersome…

I think the current data browser should therefore be extended with links to the actual data, presented in neat tables (perhaps something like the current “web pivot”, and with an easy way of “flipping through” screens (i.e. move backwards or forwards in time by clicking on some Ajax arrows or similar). But it should also be possible to go directly to this screen from a menu selection, populated with the latest data. This new functionality should be the “Data browser”.

The current “Data browser” could perhaps be renamed “Data locator” - or does someone have a better name?

Knut

···

On Tue, Jan 19, 2010 at 5:20 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Dear Devs,

I have been working to document the Maintenance section of DHIS2, and

have a few observations and would like to have some feedback before I

file, what I think should be a blueprint.

One of my big complaints about DHIS2 is that it is exceedingly

difficult to simply browse data that has been entered. One can create

a report (rather painful) or use the data entry screens to browse

data, but this too seems a bit of a kludge, when I might just want to

simply quickly view data for a given orgunit/period/dataset

combination. This is a very common operation on the part of users. I

was expecting to find this in the “Data browser”, however, this is not

exactly what the data browser does, as far as I can tell. The data

browser provides a summary of the data contained in the database,

providing the number of data element values that are present, and they

can be grouped a couple of different ways. I have reviewed the

/dhis2/dhis-2/dhis-api/src/main/java/org/hisp/dhis/databrowser/DataBrowserTable.java

and also crosschecked this against the screen found at

(http://dhis.uio.no/demo/dhis-web-maintenance-dataadmin/searchResult.action?periodTypeId=Monthly&fromDate=2009-04-01&toDate=2009-08-31&searchOption=DataSet).

This appears to be a summary of the number of elements contained in a

given dataset for a given period interval. This is fine and quite

handy I guess.

Now, this is where things get tricky…

http://dhis.uio.no/demo/dhis-web-maintenance-dataadmin/searchResult.action?searchOption=DataSet&parent=233&periodType=Monthly&toDate=2009-08-31&fromDate=2009-04-01

provides a summary ( I think) of the number of data element values for

a given data element and period interval, which is also handy.

However, I feel this may be very misleading, because of the name "Data

browser". We are looking here at the “COUNT” of data element values,

not the “SUM” and not browsing the actual data values themselves. If

an untrained eye were to see the results of the URL above, it might be

very misleading. I therefore would like to suggest that we come up

with a new name for the “Data browser”, but I do not really know what

it should be called. I just think that it should be clear that we are

not actually browsing data, but rather looking at a summary (namely

the number of data element values) for a particular set of parameters.

Regardless of this, I think having the functionality to simply browse

raw data itself, without having to go either through a report, or data

entry form, would be very useful. I was planning to write this up as a

blueprint, but would appreciate some comments on what I have written

here first.

Best regards,

Jason

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

–
Cheers,
Knut Staring

3

Perhaps "Data summary" but this also seems a bit misleading. "Data
counter", "Data tally" are two other suggestions.
I agree that having a link to the "raw" data would be a great
funcation. It is quite close actually, I think. I think from the link
I gave earlier, showing a table of raw data by clicking on a data
element would be a good start. The period dimension could be one
confined axis (columns) while the rows could be the unconfined axis
(orgunits). Of course, we strart down a slippery slope of what this
data table should look like, and having the ability to pivot it. But
since several parameters have already been defined as part of the
"Data browser" it would seem like a relatively simple matter to feed
these parameters into the web pivot. This is obviously going to take
development hours, but renaming the whole thing to something else, is
a very easy fix, and would help, I think, to correct any
misconceptions about what this is. Obviously, if the functionality is
extended to being able to actually browse the data, this module should
be moved out the "Maintenance" section and into the "Analysis"
section, and then its name would probably be appropriate, IMHO.

···

On Tue, Jan 19, 2010 at 6:40 PM, Knut Staring <knutst@gmail.com> wrote:

I fully agree, Jason - not having an easy way to browse through the actual
data other than the data entry screen is a problem.
The reason for the idea behind the "data browser" in the first place was
frustration with how hard it was to find out where there actually is data
when approaching e.g. the demo database (or indeed any unknown database) -
the only way to find out (short of querying the db directly) was to click
through a lot of periods for each dataset in the data entry screen, which is
both inefficient and unintuitive. So what we have now is a pretty useful
tool to locate the data, but what it lacks is an easy way to see the actual
data - for that you have to make a note of where the data is, and then
return to the data entry screen - talk about cumbersome....
I think the current data browser should therefore be extended with links to
the actual data, presented in neat tables (perhaps something like the
current "web pivot", and with an easy way of "flipping through" screens
(i.e. move backwards or forwards in time by clicking on some Ajax arrows or
similar). But it should also be possible to go directly to this screen from
a menu selection, populated with the latest data. This new functionality
should be the "Data browser".
The current "Data browser" could perhaps be renamed "Data locator" - or does
someone have a better name?
Knut

On Tue, Jan 19, 2010 at 5:20 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:

Dear Devs,
I have been working to document the Maintenance section of DHIS2, and
have a few observations and would like to have some feedback before I
file, what I think should be a blueprint.

One of my big complaints about DHIS2 is that it is exceedingly
difficult to simply browse data that has been entered. One can create
a report (rather painful) or use the data entry screens to browse
data, but this too seems a bit of a kludge, when I might just want to
simply quickly view data for a given orgunit/period/dataset
combination. This is a very common operation on the part of users. I
was expecting to find this in the "Data browser", however, this is not
exactly what the data browser does, as far as I can tell. The data
browser provides a summary of the data contained in the database,
providing the number of data element values that are present, and they
can be grouped a couple of different ways. I have reviewed the

/dhis2/dhis-2/dhis-api/src/main/java/org/hisp/dhis/databrowser/DataBrowserTable.java
and also crosschecked this against the screen found at

(DHIS2 App Hub).
This appears to be a summary of the number of elements contained in a
given dataset for a given period interval. This is fine and quite
handy I guess.

Now, this is where things get tricky..

DHIS2 App Hub

provides a summary ( I think) of the number of data element values for
a given data element and period interval, which is also handy.

However, I feel this may be very misleading, because of the name "Data
browser". We are looking here at the "COUNT" of data element values,
not the "SUM" and not browsing the actual data values themselves. If
an untrained eye were to see the results of the URL above, it might be
very misleading. I therefore would like to suggest that we come up
with a new name for the "Data browser", but I do not really know what
it should be called. I just think that it should be clear that we are
not actually browsing data, but rather looking at a summary (namely
the number of data element values) for a particular set of parameters.

Regardless of this, I think having the functionality to simply browse
raw data itself, without having to go either through a report, or data
entry form, would be very useful. I was planning to write this up as a
blueprint, but would appreciate some comments on what I have written
here first.

Best regards,
Jason

_______________________________________________
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

--
Cheers,
Knut Staring

4

Hi,

I agree that the data browser results can be misleading to an untrained eye. A first thing to do is to actually provide a heading above the data (count) table that says something like “Number of values reported for:”. I agree that we can call it something else, and “Data summary” is not a bad name. ( I am also not sure the browse by orgunit actually works, at least it doesn’t seem to aggregate up the counts as most districts have ‘0’ values in that view. )

I must say that I actually find the data entry screen quite useful for looking up raw data a given orgunit-period-dataset combination, and find it a very fast tool to switch between periods, orgunits and datasets for such a view. When it comes to other views into the raw data, like a few data elements over many periods or other pivoted views I agree we need something more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table tool in Reports to “Data browser”. After all we are not interested in developing a fully fledged pivot tool, and data browser reflects more of what that tool is. Let’s try to brainstorm what kind of functionality we would have to add in order to come up with a proper data browser. Here is a few things I can think of right now:

  • support for data elements, not just indicators
  • filter by dataset, not only groups
  • automatic datamart export triggered in the background (like with report tables)
  • filter (parameter selection window like datamart export etc.) to select any data element, period, orgunit (at the same level) and then get an ad-hoc pivot table from that

What else?

Ola

···

2010/1/19 Jason Pickering jason.p.pickering@gmail.com

Perhaps “Data summary” but this also seems a bit misleading. "Data

counter", “Data tally” are two other suggestions.

I agree that having a link to the “raw” data would be a great

funcation. It is quite close actually, I think. I think from the link

I gave earlier, showing a table of raw data by clicking on a data

element would be a good start. The period dimension could be one

confined axis (columns) while the rows could be the unconfined axis

(orgunits). Of course, we strart down a slippery slope of what this

data table should look like, and having the ability to pivot it. But

since several parameters have already been defined as part of the

“Data browser” it would seem like a relatively simple matter to feed

these parameters into the web pivot. This is obviously going to take

development hours, but renaming the whole thing to something else, is

a very easy fix, and would help, I think, to correct any

misconceptions about what this is. Obviously, if the functionality is

extended to being able to actually browse the data, this module should

be moved out the “Maintenance” section and into the “Analysis”

section, and then its name would probably be appropriate, IMHO.

On Tue, Jan 19, 2010 at 6:40 PM, Knut Staring knutst@gmail.com wrote:

I fully agree, Jason - not having an easy way to browse through the actual

data other than the data entry screen is a problem.

The reason for the idea behind the “data browser” in the first place was

frustration with how hard it was to find out where there actually is data

when approaching e.g. the demo database (or indeed any unknown database) -

the only way to find out (short of querying the db directly) was to click

through a lot of periods for each dataset in the data entry screen, which is

both inefficient and unintuitive. So what we have now is a pretty useful

tool to locate the data, but what it lacks is an easy way to see the actual

data - for that you have to make a note of where the data is, and then

return to the data entry screen - talk about cumbersome…

I think the current data browser should therefore be extended with links to

the actual data, presented in neat tables (perhaps something like the

current “web pivot”, and with an easy way of “flipping through” screens

(i.e. move backwards or forwards in time by clicking on some Ajax arrows or

similar). But it should also be possible to go directly to this screen from

a menu selection, populated with the latest data. This new functionality

should be the “Data browser”.

The current “Data browser” could perhaps be renamed “Data locator” - or does

someone have a better name?

Knut

On Tue, Jan 19, 2010 at 5:20 PM, Jason Pickering > > > jason.p.pickering@gmail.com wrote:

Dear Devs,

I have been working to document the Maintenance section of DHIS2, and

have a few observations and would like to have some feedback before I

file, what I think should be a blueprint.

One of my big complaints about DHIS2 is that it is exceedingly

difficult to simply browse data that has been entered. One can create

a report (rather painful) or use the data entry screens to browse

data, but this too seems a bit of a kludge, when I might just want to

simply quickly view data for a given orgunit/period/dataset

combination. This is a very common operation on the part of users. I

was expecting to find this in the “Data browser”, however, this is not

exactly what the data browser does, as far as I can tell. The data

browser provides a summary of the data contained in the database,

providing the number of data element values that are present, and they

can be grouped a couple of different ways. I have reviewed the

/dhis2/dhis-2/dhis-api/src/main/java/org/hisp/dhis/databrowser/DataBrowserTable.java

and also crosschecked this against the screen found at

(http://dhis.uio.no/demo/dhis-web-maintenance-dataadmin/searchResult.action?periodTypeId=Monthly&fromDate=2009-04-01&toDate=2009-08-31&searchOption=DataSet).

This appears to be a summary of the number of elements contained in a

given dataset for a given period interval. This is fine and quite

handy I guess.

Now, this is where things get tricky…

http://dhis.uio.no/demo/dhis-web-maintenance-dataadmin/searchResult.action?searchOption=DataSet&parent=233&periodType=Monthly&toDate=2009-08-31&fromDate=2009-04-01

provides a summary ( I think) of the number of data element values for

a given data element and period interval, which is also handy.

However, I feel this may be very misleading, because of the name "Data

browser". We are looking here at the “COUNT” of data element values,

not the “SUM” and not browsing the actual data values themselves. If

an untrained eye were to see the results of the URL above, it might be

very misleading. I therefore would like to suggest that we come up

with a new name for the “Data browser”, but I do not really know what

it should be called. I just think that it should be clear that we are

not actually browsing data, but rather looking at a summary (namely

the number of data element values) for a particular set of parameters.

Regardless of this, I think having the functionality to simply browse

raw data itself, without having to go either through a report, or data

entry form, would be very useful. I was planning to write this up as a

blueprint, but would appreciate some comments on what I have written

here first.

Best regards,

Jason

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

–

Cheers,

Knut Staring

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

5

I must agree a bit with Ola here… The work-flow of such a browser would be to select orgunit, then dataset, then period and then get some sort of display of the data - which is exactly what we have in the data entry screen. Me too thinks that extending the web pivot to use aggregated data values and entered data values (with data set filter instead of group) is a good idea that would not require too much development time. We could put this on the list.

Lars

···

On Wed, Jan 20, 2010 at 10:03 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

Hi,

I agree that the data browser results can be misleading to an untrained eye. A first thing to do is to actually provide a heading above the data (count) table that says something like “Number of values reported for:”. I agree that we can call it something else, and “Data summary” is not a bad name. ( I am also not sure the browse by orgunit actually works, at least it doesn’t seem to aggregate up the counts as most districts have ‘0’ values in that view. )

I must say that I actually find the data entry screen quite useful for looking up raw data a given orgunit-period-dataset combination, and find it a very fast tool to switch between periods, orgunits and datasets for such a view. When it comes to other views into the raw data, like a few data elements over many periods or other pivoted views I agree we need something more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table tool in Reports to “Data browser”. After all we are not interested in developing a fully fledged pivot tool, and data browser reflects more of what that tool is. Let’s try to brainstorm what kind of functionality we would have to add in order to come up with a proper data browser. Here is a few things I can think of right now:

  • support for data elements, not just indicators
  • filter by dataset, not only groups
  • automatic datamart export triggered in the background (like with report tables)
  • filter (parameter selection window like datamart export etc.) to select any data element, period, orgunit (at the same level) and then get an ad-hoc pivot table from that

What else?

Ola

6

Hi,

I agree that the data browser results can be misleading to an untrained eye. A first thing to do is to actually provide a heading above the data (count) table that says something like “Number of values reported for:”. I agree that we can call it something else, and “Data summary” is not a bad name. ( I am also not sure the browse by orgunit actually works, at least it doesn’t seem to aggregate up the counts as most districts have ‘0’ values in that view. )

I must say that I actually find the data entry screen quite useful for looking up raw data a given orgunit-period-dataset combination, and find it a very fast tool to switch between periods, orgunits and datasets for such a view. When it comes to other views into the raw data, like a few data elements over many periods or other pivoted views I agree we need something more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table tool in Reports to “Data browser”. After all we are not interested in developing a fully fledged pivot tool, and data browser reflects more of what that tool is. Let’s try to brainstorm what kind of functionality we would have to add in order to come up with a proper data browser. Here is a few things I can think of right now:

  • support for data elements, not just indicators
  • filter by dataset, not only groups
  • automatic datamart export triggered in the background (like with report tables)
  • filter (parameter selection window like datamart export etc.) to select any data element, period, orgunit (at the same level) and then get an ad-hoc pivot table from that

What else?

Ola

I must agree a bit with Ola here… The work-flow of such a browser would be to select orgunit, then dataset, then period and then get some sort of display of the data - which is exactly what we have in the data entry screen.

Yes, we have most of what is needed already, which hopefully means improving it would not be too much work.

The reason the data entry in itself is not sufficient is that it only offers the one-dimensional list - for a data browser you would like to compare many orgunits for a period or many periods for an orgunit or many datasets for one period/orgunit combo - and this is indeed the kind of thing the current web pivot can do.

So what would greatly enhance the usability of DHIS2 would be integration of the Data Entry and the Web Pivot (i.e. links to allow you to quickly get screens where you see your recently added data in context - and then we can add intuitive links from the Data Summary (currently misnamed Data browser) to this integrated Data Browser.

So we are basically talking about intelilgent links between what is currently three separate modules. This would reduce clicking dramatically and make it easier to get an understanding of what is available.

As a further step, I think it would be great if what the user has selected to see in the Web Pivot could then also be made into a report table with the click of a button. We have a lot of good parts that could become very powerful if linked better.

Knut

···

2010/1/21 Lars Helge Øverland larshelge@gmail.com

On Wed, Jan 20, 2010 at 10:03 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

Me too thinks that extending the web pivot to use aggregated data values and entered data values (with data set filter instead of group) is a good idea that would not require too much development time. We could put this on the list.

Lars

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

–
Cheers,
Knut Staring

7

Hi,

I agree that the data browser results can be misleading to an untrained eye. A first thing to do is to actually provide a heading above the data (count) table that says something like “Number of values reported for:”. I agree that we can call it something else, and “Data summary” is not a bad name. ( I am also not sure the browse by orgunit actually works, at least it doesn’t seem to aggregate up the counts as most districts have ‘0’ values in that view. )

I must say that I actually find the data entry screen quite useful for looking up raw data a given orgunit-period-dataset combination, and find it a very fast tool to switch between periods, orgunits and datasets for such a view. When it comes to other views into the raw data, like a few data elements over many periods or other pivoted views I agree we need something more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table tool in Reports to “Data browser”. After all we are not interested in developing a fully fledged pivot tool, and data browser reflects more of what that tool is. Let’s try to brainstorm what kind of functionality we would have to add in order to come up with a proper data browser. Here is a few things I can think of right now:

  • support for data elements, not just indicators
  • filter by dataset, not only groups
  • automatic datamart export triggered in the background (like with report tables)
  • filter (parameter selection window like datamart export etc.) to select any data element, period, orgunit (at the same level) and then get an ad-hoc pivot table from that

What else?

Ola

I must agree a bit with Ola here… The work-flow of such a browser would be to select orgunit, then dataset, then period and then get some sort of display of the data - which is exactly what we have in the data entry screen.

I don’t understand why you think this would be the only workflow - in fact I think a user would usually want to leave one or two of those core dimensions free, and only select one of them (i.e. the what, where, when - called the “grain” in data warehouse terminology http://en.wikipedia.org/wiki/Fact_table )

To me, a typical use case would be to initially select between either raw datavalues or indicator values (though even this may be too restrictive), then an orgunit level and then a period type. These, but only these are essential.

Then, you would select either a dataelement, a period or an orgunit.

This would result in three possible matrix views:

  1. Orgunits X Periods for one selected dataelement or indicator

  2. Orgunits X Dataelements for one selected period

  3. Datalements x Periods

Ideally, it would be easy to change the selections smoothly, from drop down lists or arrows.

The openhealth prototype did this very well (it also allowed alternative ways of entering data, e.g. by orgunit or period, another feature lacking from DHIS - though not a high priority, I think).

Knut

···

2010/1/21 Knut Staring knutst@gmail.com

2010/1/21 Lars Helge Øverland larshelge@gmail.com

On Wed, Jan 20, 2010 at 10:03 AM, Ola Hodne Titlestad olatitle@gmail.com wrote:

Yes, we have most of what is needed already, which hopefully means improving it would not be too much work.

The reason the data entry in itself is not sufficient is that it only offers the one-dimensional list - for a data browser you would like to compare many orgunits for a period or many periods for an orgunit or many datasets for one period/orgunit combo - and this is indeed the kind of thing the current web pivot can do.

So what would greatly enhance the usability of DHIS2 would be integration of the Data Entry and the Web Pivot (i.e. links to allow you to quickly get screens where you see your recently added data in context - and then we can add intuitive links from the Data Summary (currently misnamed Data browser) to this integrated Data Browser.

So we are basically talking about intelilgent links between what is currently three separate modules. This would reduce clicking dramatically and make it easier to get an understanding of what is available.

As a further step, I think it would be great if what the user has selected to see in the Web Pivot could then also be made into a report table with the click of a button. We have a lot of good parts that could become very powerful if linked better.

Knut

Me too thinks that extending the web pivot to use aggregated data values and entered data values (with data set filter instead of group) is a good idea that would not require too much development time. We could put this on the list.

Lars

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

–
Cheers,
Knut Staring

–
Cheers,
Knut Staring

8

I think it would be good to have a look at DevInfo. I thought I would
never write that, but there you go. They have a sort of wizard, that
allows people to select different dimensions (time, places,
indicators) and then choose the output format (tables, maps, graphs).
It is a very constrained workflow, but it is a defined and flexible
workflow, and might be worth taking a look at.

Regards,
Jason

···

2010/1/21 Knut Staring <knutst@gmail.com>:

2010/1/21 Knut Staring <knutst@gmail.com>

2010/1/21 Lars Helge Øverland <larshelge@gmail.com>

On Wed, Jan 20, 2010 at 10:03 AM, Ola Hodne Titlestad >>> <olatitle@gmail.com> wrote:

Hi,

I agree that the data browser results can be misleading to an untrained
eye. A first thing to do is to actually provide a heading above the data
(count) table that says something like "Number of values reported for:". I
agree that we can call it something else, and "Data summary" is not a bad
name. ( I am also not sure the browse by orgunit actually works, at least it
doesn't seem to aggregate up the counts as most districts have '0' values in
that view. )

I must say that I actually find the data entry screen quite useful for
looking up raw data a given orgunit-period-dataset combination, and find it
a very fast tool to switch between periods, orgunits and datasets for such a
view. When it comes to other views into the raw data, like a few data
elements over many periods or other pivoted views I agree we need something
more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table
tool in Reports to "Data browser". After all we are not interested in
developing a fully fledged pivot tool, and data browser reflects more of
what that tool is. Let's try to brainstorm what kind of functionality we
would have to add in order to come up with a proper data browser. Here is a
few things I can think of right now:

- support for data elements, not just indicators
- filter by dataset, not only groups
- automatic datamart export triggered in the background (like with
report tables)
- filter (parameter selection window like datamart export etc.) to
select any data element, period, orgunit (at the same level) and then get
an ad-hoc pivot table from that

What else?

Ola

I must agree a bit with Ola here... The work-flow of such a browser would
be to select orgunit, then dataset, then period and then get some sort of
display of the data - which is exactly what we have in the data entry
screen.

I don't understand why you think this would be the only workflow - in fact I
think a user would usually want to leave one or two of those core dimensions
free, and only select one of them (i.e. the what, where, when - called the
"grain" in data warehouse
terminology Fact table - Wikipedia )
To me, a typical use case would be to initially select between either raw
datavalues or indicator values (though even this may be too restrictive),
then an orgunit level and then a period type. These, but only these are
essential.
Then, you would select *either* a dataelement, a period or an orgunit.
This would result in three possible matrix views:
1) Orgunits X Periods for one selected dataelement or indicator
2) Orgunits X Dataelements for one selected period
3) Datalements x Periods
Ideally, it would be easy to change the selections smoothly, from drop down
lists or arrows.
The openhealth prototype did this very well (it also allowed alternative
ways of entering data, e.g. by orgunit or period, another feature lacking
from DHIS - though not a high priority, I think).
Knut

Yes, we have most of what is needed already, which hopefully means
improving it would not be too much work.
The reason the data entry in itself is not sufficient is that it only
offers the one-dimensional list - for a data browser you would like to
compare many orgunits for a period or many periods for an orgunit or many
datasets for one period/orgunit combo - and this is indeed the kind of thing
the current web pivot can do.
So what would greatly enhance the usability of DHIS2 would be integration
of the Data Entry and the Web Pivot (i.e. links to allow you to quickly get
screens where you see your recently added data in context - and then we can
add intuitive links from the Data Summary (currently misnamed Data browser)
to this integrated Data Browser.
So we are basically talking about intelilgent links between what is
currently three separate modules. This would reduce clicking dramatically
and make it easier to get an understanding of what is available.
As a further step, I think it would be great if what the user has selected
to see in the Web Pivot could then also be made into a report table with the
click of a button. We have a lot of good parts that could become very
powerful if linked better.
Knut

Me too thinks that extending the web pivot to use aggregated data values
and entered data values (with data set filter instead of group) is a good
idea that would not require too much development time. We could put this on
the list.

Lars

_______________________________________________
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

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

_______________________________________________
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

9

I agree that there is no sense in trying to offer “everything”, which would be a nightmare to program and confusing to users. And there are clear advantages to guiding people through paths that will work. However, I don’t like forcing people unnecessarily through only one workflow - that is what we have today, and it can be very cumbersome. If you have already made a bunch of selections, it is much more user friendly to not have to make them again in a completely different screen - and there should be several ways to get to the concise data display.

Jason, if you have time, you and I could collaborate on a step-by-step blueprint for this. We need to break suggested improvements into smaller chunks and not have this become a huge undertaking. It is a good idea to see how things are done in DevInfo, see what works well and what doesn’t - same for CRIS. Maybe the best place to start when considering how we want data browsing to end up is the current Report Table definition screen - with the kind of Web Pivot view just another take on the HTML output? Seems to me there is both some consolidation of output and linkages to the output needed?

Knut

···

2010/1/21 Jason Pickering jason.p.pickering@gmail.com

I think it would be good to have a look at DevInfo. I thought I would

never write that, but there you go. They have a sort of wizard, that

allows people to select different dimensions (time, places,

indicators) and then choose the output format (tables, maps, graphs).

It is a very constrained workflow, but it is a defined and flexible

workflow, and might be worth taking a look at.

Regards,

Jason

2010/1/21 Knut Staring knutst@gmail.com:

2010/1/21 Knut Staring knutst@gmail.com

2010/1/21 Lars Helge Øverland larshelge@gmail.com

On Wed, Jan 20, 2010 at 10:03 AM, Ola Hodne Titlestad > > >>> olatitle@gmail.com wrote:

Hi,

I agree that the data browser results can be misleading to an untrained

eye. A first thing to do is to actually provide a heading above the data

(count) table that says something like “Number of values reported for:”. I

agree that we can call it something else, and “Data summary” is not a bad

name. ( I am also not sure the browse by orgunit actually works, at least it

doesn’t seem to aggregate up the counts as most districts have ‘0’ values in

that view. )

I must say that I actually find the data entry screen quite useful for

looking up raw data a given orgunit-period-dataset combination, and find it

a very fast tool to switch between periods, orgunits and datasets for such a

view. When it comes to other views into the raw data, like a few data

elements over many periods or other pivoted views I agree we need something

more like a web pivot tool.

I actually think we should build on and possibly rename the pivot table

tool in Reports to “Data browser”. After all we are not interested in

developing a fully fledged pivot tool, and data browser reflects more of

what that tool is. Let’s try to brainstorm what kind of functionality we

would have to add in order to come up with a proper data browser. Here is a

few things I can think of right now:

  • support for data elements, not just indicators
  • filter by dataset, not only groups
  • automatic datamart export triggered in the background (like with

report tables)

  • filter (parameter selection window like datamart export etc.) to

select any data element, period, orgunit (at the same level) and then get

an ad-hoc pivot table from that

What else?

Ola

I must agree a bit with Ola here… The work-flow of such a browser would

be to select orgunit, then dataset, then period and then get some sort of

display of the data - which is exactly what we have in the data entry

screen.

I don’t understand why you think this would be the only workflow - in fact I

think a user would usually want to leave one or two of those core dimensions

free, and only select one of them (i.e. the what, where, when - called the

“grain” in data warehouse

terminology http://en.wikipedia.org/wiki/Fact_table )

To me, a typical use case would be to initially select between either raw

datavalues or indicator values (though even this may be too restrictive),

then an orgunit level and then a period type. These, but only these are

essential.

Then, you would select either a dataelement, a period or an orgunit.

This would result in three possible matrix views:

  1. Orgunits X Periods for one selected dataelement or indicator
  1. Orgunits X Dataelements for one selected period
  1. Datalements x Periods

Ideally, it would be easy to change the selections smoothly, from drop down

lists or arrows.

The openhealth prototype did this very well (it also allowed alternative

ways of entering data, e.g. by orgunit or period, another feature lacking

from DHIS - though not a high priority, I think).

Knut

Yes, we have most of what is needed already, which hopefully means

improving it would not be too much work.

The reason the data entry in itself is not sufficient is that it only

offers the one-dimensional list - for a data browser you would like to

compare many orgunits for a period or many periods for an orgunit or many

datasets for one period/orgunit combo - and this is indeed the kind of thing

the current web pivot can do.

So what would greatly enhance the usability of DHIS2 would be integration

of the Data Entry and the Web Pivot (i.e. links to allow you to quickly get

screens where you see your recently added data in context - and then we can

add intuitive links from the Data Summary (currently misnamed Data browser)

to this integrated Data Browser.

So we are basically talking about intelilgent links between what is

currently three separate modules. This would reduce clicking dramatically

and make it easier to get an understanding of what is available.

As a further step, I think it would be great if what the user has selected

to see in the Web Pivot could then also be made into a report table with the

click of a button. We have a lot of good parts that could become very

powerful if linked better.

Knut

Me too thinks that extending the web pivot to use aggregated data values

and entered data values (with data set filter instead of group) is a good

idea that would not require too much development time. We could put this on

the list.

Lars

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

–

Cheers,

Knut Staring

–

Cheers,

Knut Staring

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

–
Cheers,
Knut Staring