Data Communication is all about unpacking and repacking

A concept I can't seem shake off. I posted a ~2min teaser video to twitter last night about a new feature wherein:

• I created a query peeking at an entire table (a select-*) to see what we had
• Then created 2 separate queries on the canvas pulled from that initial block (in this case 2 group-bys with different aggregate fields - there are now 3 blocks)
• Each are then used to create charts (in 2 additional blocks - so now there are 5 blocks on my canvas)
• The charts are modified and then combined together into a single block, thus merging the charts by a shared X axis (creating a simple "layered" viz - in addition to retaining the discrete charts created)
• Finally, the source queries are moved into the layered viz block to save space (but can still be browsed and view via block tabs - back down to 2 blocks, the parent select-* query and the layered-viz)

This whole idea of using a spatial canvas to explore data / examine it / chop it up / draw it / and then collapse the "good parts" back together to present it - is really compelling to me.  

It's def a riff on the old "Skeuomorphic Desktop" concept from UI days past. Hell, that kind of physical -> representational trope has been used in so many ways for so many things that people often forget what it means.

I guess it goes without saying that I'm trying to do that with human consumable data products. For humans, by humans.

Let's lay out all the pieces that we might want to work with slice them up, combine them, throw them away, pivot them - and what you end up with is something of interest - either to you, or to your consumers.

Same as if they were index cards or pieces of graph paper on a large table - let's break out the scissors, sharpies, highlighters, and tape.

When we deliver data to other humans we are essentially just reducing / transforming / and (ultimately) re-packaging the database values into something smaller that will can easily be posted into the "human understanding API".

I intermittently taught dashboarding classes at a previous company - and I used to say "Sometimes the best dashboard is a giant red square that says 'No' in it.". It was meant to be tongue-in-cheek - but there is a lot of truth there.

That being said - if your job is to distill a ton of information into a humane visual message that informs someone succinctly enough where they then perform some set of actions based on that story - a set of actions that moves the shared mission forward... then you have done your job.

In a world drowning in abstractions, step-by-step wizards, magic dialog boxes, multiple-modes, and procedure-based UI disasters - maybe taking a hard turn back to skeuomorphic thinking can be a breath of fresh air.

A database is carboard box full of paper - and a report is a distillation of those tomes. This is my experiment in treating it like one.

- Un-pack -> Understanding

- Re-pack -> Communicating

Shit, you might even be able to keep your desk clean.