5

Displaying empty labels on graphs

Daniel Rutherfoord-Jones

May 14, 2020 13:09

None

Follow

Currently if a bar graph does not contain values for a label the bar itself does not display on the graph. Users would like to see a graph's label even if there is no data for the label.

Generally speaking being made aware of the absence of data is just as important as the presence of data.

As an example when looking at a count of projects per phase / stage, if there are no projects in planning the label for planning does not appear which can be overlooked in comparison to showing the label with a zero count and posing questions like "why are there no projects in planning?" and "should there be projects in planning?"

Another example would be when looking at a count of projects per project manager(or another field indicating responsibility).When we don't  show the label one overlooks the fact that a project manager doesn't have any projects, by displaying the label it is immediately brought to our attention.

A few more examples that show value in the absence of data are seeing no value for a month in a revenue per month graph, seeing no progress issues on our projects when viewing a count of issues per type (when our projects are behind in progress) and lastly why are there no more work items that are user facing on the backlog when looking at the number of work items per impact.

Allowing for this enhancement would prove beneficial in many scenarios similar to the above and would prevent the need for hard-coded custom reports/dashboards that are not maintainable.

1 comment

• 
  PPO Development May 18, 2020 09:52 Official comment

  Hi Daniel

  Since you took the time to articulate your issue so well I will try to provide a detailed response which will hopefully be useful for other people as well.

  Unfortunately there is no simple, generic solution for this, not even conceptually. The problem is well known in data analysis and reporting in general and is usually addressed by using a "left join" strategy (to use the relational model parlance). You specifically mention graphs but the problem is relevant to a simple, summarised data table as well.

  To use one of your examples, a common requirement is to know the number of projects per some attribute e.g. phase, status, project manager, etc.  All of these can be done by simply starting with your list of projects and then grouping by the attribute and calculating the count for each. This is something that we do all the time, whether it is in an Excel Pivot Table, some BI tool or in PPO. 

  As you point out however, if there are no projects in a particular phase (also given the fact that you may be filtering the data), then your summary will not contain any records for that phase. It is not that "the label is empty", there simply is no records in the original dataset that has that phase and consequently, the summary will not contain it either.

  If you must have a row for the phase (with a zero count), then one way to do this is to instead start with the list of phases and "left join" to the list of projects. This however introduces a number of problems including that it adds a lot of complexity and also requires that you are able to define what the "left hand" is e.g. which phases there "should" be.  This may sound straight forward but given that phases may be taken out of use or new phases added or you have different phases for different project types,  it results in hardcoding / maintainability issues or cases where a project is in a phase that is not in your "left hand" list resulting in those records being dropped i.e. you start running into data integrity issues. With attributes like project manager, these problems become even more intractable.

  The bottom line is that although the problem can be partially solved in certain specific cases, e.g. the functionality that we provide to include specific columns in a pivot, or user usage per day, we cannot solve it generically without introducing a lot of other problems. In most cases, the additional complexity, costs and risk to data integrity is just not worth it.