Foundry-workshop : add average value on a chart displaying parameter evolution

I'm looking for a way to display a line showing the average value of a parameter in a chart dedicated to this parameter's evolution.

I have a dataset, let's take as an example the following structure :

Product |  Month  | Price
P1        2021-01   13.00
P1        2021-02   13.50
P1        2021-03   15.00
P1        2021-04   14.50
P2        2021-01   3.00
P2        2021-02   3.50
P2        2021-03   5.00
P2        2021-04   4.50

In a chart, I display de price's evolution for each selected product (multi select filter upstream) and I would like to add, also for each product, a line showing the average for the displayed period.

I tried so far 2 different approaches:

• Use multiple series and add one dedicated to this average. But I did not manage to calculate this average. Actually, to display the initial chart, the evolution of my property, it looks like I must use an aggregation function (each layer type requires to define series where the first parameter to define is an aggregation function)
• Create a summary dataset, with aggregates values for each product, and the latest calculation date. It looks like this:

Product |  Latest Month  | Avg Price | Max Price | Min Price
P1           2021-04        14.00        15.00       13.00
P2           2021-04         4.0          5.00        3.00

But I'm not able to overlay these values, as there is no time series to define the same X-axis.

I considered a 3rd solution, but looks dirty to me: to add the aggregate values in the first dataset. Each row would contain avg/max/min values for the period of time so that I can display these values the same way as any other property.

Finally, writing this post made me wonder if I well understood how this tool works, as I feel that what I implemented should have led to display the average values I'm looking for, but it's the only way I found to display a "simple" property's evolution.

Thanks in advance for your help.

There are a few considerations at play here with regards to building your charts that lead to different approaches when it comes to deciding how to represent your data.

One point up front about charting in Workshop is, as you've observed, the chart expects you to aggregate the granular per-object data to create each data point of your visualization. If you want to instead draw some feature of the chart (a dot or bar) per object, then you'll need to select an appropriately narrow bucket size. In this case, if you have one object per product per month, then choosing a granularity of monthly or less should result in having one data point per object.

As for options related to deriving the average, let's look at three approaches:

1. Temporal Metrics Schema

Creating an ontology with a primary object (i.e. the "Product") and then a linked object type for storing values of metrics about that object (i.e. the "Product Metrics") can be a flexible approach that works well with Workshop and Quiver charting expectations.

Consider a modification of your original granular schema like this:

Product |  Timestamp  | Value | Metric Type
P1          2021-01     13.00    Monthly Price
P1          2021-02     13.50    Monthly Price
P1          2021-03     15.00    Monthly Price
P1          2021-04     14.50    Monthly Price
P2          2021-01     3.00     Monthly Price
P2          2021-02     3.50     Monthly Price
P2          2021-03     5.00     Monthly Price
P2          2021-04     4.50     Monthly Price
P1          2021-03     14.00    Quarterly Average
P2          2021-03     4.00     Quarterly Average
...

This schema is quite flexible and robust; you can easily add new metrics later, or even use a tool like Taurus to let users define their own rules to generate metrics that fit into this schema. It has the advantage of storing the metric type as data itself, which means that in your Workshop app, for example, you can let the user choose, using a Filter List widget, which metrics to display on a chart.

This pattern also ensures consistency of what the date "means" when presented to the user. Having, for example, a quarterly average pre-calculated means that every user will get the same information from reviewing the chart, regardless of what time period they filter to, whereas a dynamic average based on the user's selection could lead two different users to quite different conclusions based on how they chose to filter the data.

And finally, for this pattern, it becomes quite easy to show the chart itself, since you simply choose to plot the filtered object set of metrics and choose the "Metric Type" as the series property, bucket by a small granularity (say "Day") and have the chart interpolate any gaps. This means that even aperiodic metrics along with metrics recorded at different periods can all render on the same chart.

This pattern is somewhat formalized with the nascent Time-Dependent Property feature of the Foundry Ontology. If the Time-Dependent Property feature is available on your Foundry instance, you can read more about it in the Ontology product documentation in the "How to create a Time-Dependent Property" section.

2. Dynamic Charts with Functions

Let's say you don't want to precompute the metrics for whatever reason, and instead want your chart to exactly render a line based on the average price values that are in the object set. One approach to accomplish this is to use a Function-backed Chart and a simple Typescript function that takes in as a parameter to object set of price information and returns a 2DimensionAggregation type that represents two data points: the first and last timestamp of the period represented by the input object set each paired with the average value calculated across the price values or a 3DimensionalAggregation since you perhaps want these two data points for each product category.

You can find clear steps in the Workshop and Functions product documentation for producing Function-backed Charts as well as examples of various Typescript Function implementations in the Foundry Training and Resources project on your Foundry instance.

3. Dynamic Charts using Quiver

The Workshop XY Chart is still under active development and a number of features that might be useful are not yet available. In some circumstances creating the chart in Quiver and embedding it in your Workshop app with the Quiver Canvas widget can give you flexibility to build charts with "derived" values that you cannot currently accomplish directly with the Workshop chart.

I'm adding this for completeness; I don't actually think it'd be the best solution in this specific case. The power in this pattern comes from taking an object-backed bar or line chart in Quiver and using the "Convert to Timeseries" feature to unlock Quiver's timeseries plotting and transformation capabilities. You can check out the Quiver documentation for more guidance on how to create object-derived timeseries and how to turn a Quiver canvas into an Object Template to be embedded elsewhere.