Indicators have been implemented to support the Go Code Colorado submission. The basic functionality is good. Below is feedback based on the initial version. I don't know how much of this is possible given the capabilities of the built-in component. Maybe we'll need to build our own widget
Maybe the widget documentation property table should have the standard properties at the top (type, name, etc.) and then alphabetize the rest of the properties. General Properties can be used in the description above and then use Widget Properties or similar before the specific properties.
Documentation needs example of event handlers. Also need to make clear that the eventHandlers is an array of objects that includes the properties in the documentation table. Could link to a section on event handlers in the main dashboards page.
The documentation could benefit from a best practices section for the main discussion. For example, since name must be unique for lookups, maybe should use the widget type in the name, for example BasinSelector rather than Basin? Is there a need for code to search all the dashboards in an application and warn about non-unique names as a non-fatal configuration problem?
Need to document the classification file with an example. I wonder if we are going to be able to use the same file for maps and indicators, with columns as needed. This would minimize the number of files.
It would be handy if indicators could read DateValue files in addition to csv. This would eliminate the need to publish both files. I don't know if internally handling the data as a time series would help with some other functionality (like sparklines, discussed below).
Because skipDataLines is specific to certain input, maybe it should be called data.csv.skipDataLines or similar?
Need an indicatorValue property that indicates what value is displayed. The default is the last value read from dataPath. I expect that we will add more functionality in the future.
Need a referenceValue property that is used to compute the change. The default is the value previous to indicatorValue. I expect that we will add more functionality in the future.
Need titleTooltip, indicatorValueTooltip, referenceValueTooltip to allow explanations to be provided to the user. The default is no tooltip.
Need a way to control whether the status icon is shown. For example, it may not be possible or required to provide an indicator status and just a value is shown. In this case the status icon is not needed. Maybe use a property like statusVisible=true or determine based on whether a classification is provided?
Need a way to show a data type icon rather than or in addition to the status. For example, show a data type icon to the left of the status icon. See examples of dashboard indicators that were provided when we started implementing dashboards to see what this might look like (waves for water, etc.).
Need a way to provide a link to documentation explaining the indicator. Maybe this is an info button or a kebab with information menu.
Maybe move the change value to below the indicator value? This would associate the change with the value and provide room for a sparkline graph (see below).
Need option to show units for values. Could specify a units property or determine from data. For example time series have the units. Units should be displayed to the right of the indicator value and maybe the change value.
Add a sparklineVisible=true and show a small sparkline graph below the status icon (would have space if change is moved to under the indicator. Additional properties might be needed like sparklineCount for the number of points used in the sparkline, with appropriate defaults. It may be necessary to specify a time period for the spark line, which could be useful in the tooltip for the sparkline graph. Plotly seems to have a sparkline capability but might need something else.
Indicators have been implemented to support the Go Code Colorado submission. The basic functionality is good. Below is feedback based on the initial version. I don't know how much of this is possible given the capabilities of the built-in component. Maybe we'll need to build our own widget
type
,name
, etc.) and then alphabetize the rest of the properties. General Properties can be used in the description above and then use Widget Properties or similar before the specific properties.eventHandlers
is an array of objects that includes the properties in the documentation table. Could link to a section on event handlers in the main dashboards page.name
must be unique for lookups, maybe should use the widget type in the name, for exampleBasinSelector
rather thanBasin
? Is there a need for code to search all the dashboards in an application and warn about non-unique names as a non-fatal configuration problem?skipDataLines
is specific to certain input, maybe it should be calleddata.csv.skipDataLines
or similar?indicatorValue
property that indicates what value is displayed. The default is the last value read fromdataPath
. I expect that we will add more functionality in the future.referenceValue
property that is used to compute the change. The default is the value previous toindicatorValue
. I expect that we will add more functionality in the future.titleTooltip
,indicatorValueTooltip
,referenceValueTooltip
to allow explanations to be provided to the user. The default is no tooltip.statusVisible=true
or determine based on whether a classification is provided?units
property or determine from data. For example time series have the units. Units should be displayed to the right of the indicator value and maybe the change value.sparklineVisible=true
and show a small sparkline graph below the status icon (would have space if change is moved to under the indicator. Additional properties might be needed likesparklineCount
for the number of points used in the sparkline, with appropriate defaults. It may be necessary to specify a time period for the spark line, which could be useful in the tooltip for the sparkline graph. Plotly seems to have a sparkline capability but might need something else.