Feature request
One can currently see the impact of different processes in the supply chain via a bar chart:
And via a Sankey graph:
Our client would like to have a more interactive contribution analysis based on an expanding tree. This would follow the standard "clickable triangle" pattern where clicking on the triangle expands impacts. The basic interface would look something like this:
Reference flow: [dropdown]
Impact indicator: [dropdown]
Tag system: [dropdown]
┐ Reference flow
├─ Input A
├─ Input B
└─ Input C
Where Input A, etc., could be clicked to expand or contract.
To calculate the initial set of impacts, run graph traversal in the same way as the Sankey example. This graph traversal object should be kept in memory, so that further calculations can be done quickly. The initial calculation should use a shallow max_depth, either 1 or 2, and subsequent calculations (upon clicks) should do the same thing, but starting from the clicked node as the new functional unit.
If a tag system is chosen, then inputs should be grouped, so one would instead see something like:
┐ Reference flow
├─ Tag A
├─ Tag B
└─ Input C
Specific tasks:
Feature request
One can currently see the impact of different processes in the supply chain via a bar chart:
And via a Sankey graph:
Our client would like to have a more interactive contribution analysis based on an expanding tree. This would follow the standard "clickable triangle" pattern where clicking on the triangle expands impacts. The basic interface would look something like this:
Where
Input A, etc., could be clicked to expand or contract.To calculate the initial set of impacts, run graph traversal in the same way as the Sankey example. This graph traversal object should be kept in memory, so that further calculations can be done quickly. The initial calculation should use a shallow
max_depth, either 1 or 2, and subsequent calculations (upon clicks) should do the same thing, but starting from the clicked node as the new functional unit.If a
tag systemis chosen, then inputs should be grouped, so one would instead see something like:Specific tasks:
NavigatorWidgetclass for contribution tree, and make it available in this row:tagssystem. Tags are a part of our fundamental data schema, and are designed to be categorical (quantitative values would normally be aproperty).Databaseobject instead of scanning the whole database when doing any initial load.tagssystem to the results. Handle missingtagselegantly.NavigatorWidgetclass