Sign me up on this! Almost every dashboard I build have components that are built on dynamic data based on api queries. Not being able to label the series from the data source means bad visualisation.
Keep up the good work, Klipfolio! Still love ya´
/Jimmy
We would really love this feature. we have graphs with multiple series and dynamic series labels would be great.
I am happy to share that dynamic series are supported in the new Metrics Monitoring capabilities that were recently released in beta. When you visualize a metric on a bar or line chart the series are automatically added for each member. The series change dynamically to reflect the members with values in the specified time range.
You can learn more about metrics here. As well the Knowledge Base has a bunch of useful articles.
Thank you,
Stephen
Metrics don't support hidden data filters, so they are a non-starter for me. All of my Klips will have at least two hidden data filters, one based on a user property (emailAddress) and one based on the variable for a user input Klip (Selected Group). Some of my Klips will then also have another hidden data filter based on another user input Klip (Selected Member of Selected Group).
The right way to do this is to put in a 2nd series that is based on a text column. The text column values then determine the colors, so I might have a series 'population' (the metric) and a second series 'gender' and x-axis 'state'. This would then show me a separate column based on population for each of the 3 values of gender (Male, Female, Unknown/Other) for each state.
Hi Klipfolio, any update on this?
I think something was missed in the requirements gathering for PowerMetrics. What lead to Klipfolio's success (or at least what made the decision for me) was the access control down to a row level, and other features that enabled dashboards to be shared with different entities. This meant I could maintain a dashboard for different clients/partners to access and show their relevant data.
Granted, many of the weaknesses of the original Klipfolio have been addressed in PowerMetrics, such as ease of creation, variable graph series items, historical data snapshots, but now we have 2 almost great products, both of which have some limitations that could force people away.
What I need to get in the one place is user variables and variable series items.
So my interpretation of what you're trying to do is build a dashboard and share it with different users. Each user you share it with would have a different filter value set and you don't want users to be able to change those filters. In order to do this, you will need:
If I got that right, I think a hidden filter in this context is a reasonable requirement and a feature we can implement. In order to get a dynamic filter, I think supporting a variable should also be possible. I'll take this back to the team and see when it might be possible to address this. We'd appreciate your help testing this out with your use case if we decide to implement it. Thanks again for your input and I'll keep you posted.
Hi David,
The first part is correct, I do have a dashboard that I have filters set for different users. But for my case, it was fine to do this with a user property.
I actually needed internal users to be able to change that variable when viewing the dashboard. I was able to achieve this by relating a dropdown filter on the dashboard to the same variable as the user property, and then restrict access to that dropdown. External users have the variable set by the user property and internal users can change it with the dropdown.
My point about mentioning the variety of access controls in Klips, is that I can't do the same type of thing with PowerMetrics. And, relating this back to the original topic of this thread, that matters when I would like to have a bar graph showing different series dynamically based on the data, not based on me creating 100+ series' in the Klip. I have achieved the graph I want in PowerMetrics, but it's no use without the access control of Klips.
The most direct feature solution that I can think of is to have a labels element as a sub element of the series element, very similar to pie charts have, except you need to have it related to a series. The values on the graph are taken from the series element same as now, but if a labels element is present, then it will split values the same way as different series do and add to the graph key, again the same way series do.
Or... thinking about how this distinction is made is other tools, don't call element that provide values to the graph "series". Call it "metric" and under "metric" you can have an element call "series". Then you can add more "metrics" to the graph, but within that metric it can be split into different series based on a correspond column to the value, again same as your value/label relationship works for pie charts. Same as series currently works now, you can relate metrics to different y axis. Both solutions work the same way, just different names for the elements.
ie.
Bar graph
> metric (has values to plot on x/y)
>> series (matched to metric values by row, then splits metric values, assigns different colours and uses returned value as the label)
> y-axis
> x-axis
But, with change management in mind, it would be more practical to keep calling the main element "series" and then, when there is only one series, allow adding a "label" element under series. This way, current graph klips can continue to work with multiple series, but new klips can use one series and add labels that will do the work of multiple series.
ie.
Bar graph
> series (has values to plot on x/y)
>> label (matched to series values by row, then splits series values, assigns different colours and uses returned value as the label)
> y-axis
> x-axis
Thanks for clarifying. We already have the capability of segmenting data by dimension/series in PowerMetrics - one of the core reasons we developed it. Perhaps some visualization enhancements are still needed to represent things exactly how you want. However, implementing this same capability in Klips will not be possible since the schema was not designed to support this. The good news is, we should be able to implement the hidden filter and variable functionality to at least solve part of the problem.
