Bar Chart Improvements

I am pleased to hear that the bar chart will included in the rebuild. It may not be as flashy on the presentation side, but it is often the best tool for intuitive communication to prompt management decisions.

If you are working toward minimum and maximum controls, then please allow us to pass those values to the graph via flow variable. Attempts at “automating” these values based off of the domain will fall short of user requirements because uses, preferences and story telling requirements varies so heavily. (For instance, our charts are often used to represent budget adjustments based on averages. When doing this, great care must be taken to visually display in a way that clearly shows average differences for decision making purposes without setting a min / max that skews a user’s interpretation of those differences.)

I utilize reference lines in all of my reporting. They are a crucial tool for displaying budget vs actual, instant visual feedback of changes applied during user interaction, and visual feedback as to how a change is being applied. Here are some visual examples.

2014-04-12_01-00-324
This shows a basic image of a calculated “per bar” reference line that can be used to easily show budget vs actual within an interactive dashboard.

reflines_scope1
This shows other ways that I utilize reference lines to display different calculation practices. (Ignore the label of “Average” as this is not really a great use case for the need of this capability) Ideally all of these reference line approaches could be utilized, uniquely formatted and overlapped on the same chart, as well as multiple uses of the same type of reference line (aka more than 1 per bar reference line showing 2 different concepts, such as one reference line for budget and another for user proposed changes). A reference line controls should include color, thickness, percent of the bar area, value / labeling and “fill up to line” (this would fill the area up to the reference line with a certain color / transparency either in the background or layered in front of the graph.) The “tooltip” should also be customizable with information from other fields / text.

A strong upgrade of this interactive bar chart would be a massive game changer. It represents an entry point opportunity for me (and potentially thousands of other business users) to fully migrate from Tableau server over to what would become a much simpler and more capable platform of KNIME Business Hub.

In general, I would add that there is far more KNIME revenue potential for exponential growth of Business Hub with a heavier development shift toward highly flexible “business reporting friendly” interactive visualizations and user dashboard interaction control options.

Aggregation: Just wanted to add that I would definitely prioritize enhanced visualization options over “in chart aggregations”. We already have almost infinite possibilities to handle aggregations in the KNIME platforms prior to our chart visualizations. I personally can’t imagine ever using “in chart” aggregation options for review, adjustment and proofing reasons.

Maybe there are a few things that might be user friendly like combined total on a stacked bar chart for value display or something, but I don’t see why we can’t just calculate things like averages and labels first and just feed them through for display in columns. There will always be way more flexibility in the overall platform then anything you can pull off with a single visualization node.

Hi @iCFO and thanks for your detailed thoughts. I know you had a bit of dialogue with @DanielBog about this already, but tagging him here so he knows what you’ve compiled.

1 Like

Thanks @ScottF and @DanielBog

The only other big obstacle after improving these visualization nodes is the combined sharing of filters / selections between graphs. At this point selections on each visualizations can only be applied to downstream nodes in a linear fashion and applying those selections requires the use of a refresh button. While I can work around some of these limitations by creating / writing to / reading back selection values from a log file, that is an inefficient and less stable approach.

I think that selection changes in visualization nodes should be able to pass user selection variables and refresh triggers back upstream somehow via another relay connector. It would essentially be a loop back relay of selection values / retrigger connector (which I assume would need a relay node on the upstream end). Because of the linear flow through the KNIME structure, in order for this action to be seamless the loop process and refresh signals would have to be initiated by the visualization nodes themselves upon user selection. Still trying to think it through and test workarounds. I will likely make this another post when I have a clearer description mapped out.

Hey @iCFO,
there are a lot of interesting points in this thread! Let me tackle them one after the other.
Regarding custom min/max:
We are currently working on this and you will be able to set these values also via flow variables. I will post a screenshot into this thread as soon as its ready and I am looking forward to hear your opinion on this.
Regarding the reference lines:
Thanks for the examples and the explanation. I agree that having such a possibility would be very nice. We are currently thinking about how to solve this with KNIME and I will update this thread as soon as I have news on this.
Regarding the aggregation:
This is handled way more flexible in the new views and there you have the option to not aggregate at all.
Regarding selections between graphs:
Very interesting point and we might have gone in this direction with the new views. The selection of the new views does now work completely different compared to the current views. Previously selection was bound to the component context they were in. The new views now propagate their selection across the whole workflow and into every node (not only view nodes). To make use of the selection you would still need to manifest this selection with a collector node, but this collector node could for example auto re-execute as soon as the selection is changed. (this auto re-execution is not done currently). Happy to hear your thoughts on this, but I think for the sake of visibility we should open a new thread for this particular feature.

Greetings,
Daniel

4 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Just saw that this was marked as implemented in KNIME 5.2! Can’t wait to try it out!

1 Like