When you are building data products and filtering data files, it is important to keep track of what you have combined to make a new data set and what you have removed. This feature has saved us countless hours.
From an audit perspective we can build a complete history of a dataset - when it was added to the platform, how it was processed and when/who/where it was delivered / downloaded. This takes a removes a time-draining communication burden from our teams.
We can also add commentary and narratives to a data set. This helps us build transparency and persistent-state knowledge about data.
The tools available to produce charts and visualize data are sadly lacking in a critical area. While much focus has been placed on producing interesting visualizations, one problem has yet to be solved: it is all too easy to separate the Data layer from the Presentation layer in a chart. It is easy for the context of a chart to be lost when it becomes separated from its source. When that happens we lose meaning and we potentially introduce bias and ambiguity.
In plain english, when you produce a chart in Excel or Google Sheets, the source data is in the same document. When you embed that chart in a PowerPoint or Google slide deck you lose some of the source information. When you convert that presentation into a PDF and email it to someone, you risk losing all connections to the source. Step by step it becomes too easy to remove context from a chart.
Yes, you can label the chart. You can cite your source but neither are foolproof methods. These are like luggage tags, while they are attached they work but they are all too easy to remove.
In analytics, reproducibility and transparency are critical to building a credible story. Where did the data come from, could someone else remake the chart following these instructions (source, series information, filters applied, etc). Do the results stand up to objective scrutiny?
At Knowledge Leaps, we are building a system that ensures reproducibility and transparency by binding the context of the data and its "recipe" to the chart itself. This is built into the latest release of our application.
When charts are created we bind them to their source data (easy) and we bind the "recipe". We then make them easily searchable and discoverable, unhindered by any silo information i.e. slide, presentation, folder, etc.
The end-benefit data and charts can be shared without loss of the underlying source information. People not actively involved in creating the chart can interpret and understand its content without any ambiguity.
We have just released the charting feature in Knowledge Leaps. The ethos behind the design is this: in our experience, if you are going to make one chart using a data set you are probably going to make many charts using the data.
Specifying lots of charts one-by-one is painful, especially as a data set will typically have lots of variables that you want to plot against one specific variable, date for example. Our UI has been built with this in mind: specify multiple charts quickly, and simply, then spend the time you save putting your brain to work figuring out what the data narrative is.
Charts tend to get buried further into a silo - either as part of a workbook or a presentation. This requires contextual knowledge: to know where the chart is. In other words, you need to know where the chart is to know what story it tells. This is suboptimal, so we fixed that too. Knowledge Leaps platform lets all the your charts remain searchable and shareable. That also goes for your co-workers' charts as well. This feature allows insight to be easily discovered and shared with a wider team - helping build persistent-state organizational intelligence, faster.