Turning Data-Flows Into a Practice

Moving data around is by far the most confusing, time-consuming, mind-numbing part of data-visualization. It’s the part of this whole mapping process with the most potential to drag you down a nasty rabbit-hole and cause you to beat your head against the wall.

sumApp was designed to minimize that challenge and frustration. And the simpler your data flow, the easier this can be. But since sumApp was also designed to be adaptable, and most mappers quickly start making changes everywhere – there’s no way around it – things can still get messy.

We’ve tried to have sumApp stop you before things get too far out of control. And we’ll do our best in this knowledge base to spell out the specifics of how to avoid a mess at each step. But we can’t anticipate every possible thing someone could try to do with their datasets, their sumApp set-up, or in Kumu. And we don’t yet have a budget like the big boys do, so we can’t create the super-sophisticated logics in our interfaces that we’d like to.

So your best defense is having a basic understanding of data flows. Plus, if you plan to be a real mapper, there’s no way a little more of that kind of understanding hurts.

I try to use it as a practice. A practice of attention, being fully present (yes – present to the damn spreadsheet on my screen), patience, questioning, examining assumptions.

At the most basic level, we, as mapping technicians, need to be in the habit of cross-examining our data and our assumptions about that data at every step. From beginning to end, here are the things we need to ask ourselves:

• What, exactly, am I trying to accomplish with this move?
• Do I understand all my options before I take this step?
• Is there a cleaner, simpler way to approach this?
• Where is this data coming from?
• What does it look like here?
  • Are the column headers labeled correctly?
  • Is the data clean?
    • No duplicate persons/organizations
    • No bad emails
    • Everything in the right column?
    • No empty cells that shouldn’t be empty?
    • Are there extra header rows that will confuse the software?
    • Are there exceptions to the patterns?
• Where is it going next?
  • Will people see & interact with it next, or will a software program be dealing with it?
  • What does that require?
• Does it look the way it needs to, to land properly in that next place?
• What changes will happen to it in that place?
  • Can members change what they see?
  • Does sumApp do something to change it?
  • What do we want to have happen?
• If I add more data, how will that impact previous changes?
• Whenever I’m looking at a data-point:
  • Do I know where that came from?
  • Do I know why it looks the way it does?
  • Is it what I expected to see? and if not, why not?
• Where is it going to next?

It’s actually all pretty basic – I don’t mean to scare you.

Mostly, it’s just this – I (Christine) am naturally sloppy and cavalier with data. I know what I want it to do, I know how I want to visualize it, and I know the transformations required to get it from State A to State B. But I get impatient when handling the raw bulk of it. My mind starts to buzz a little and I want to be done already. Which is why Tim deals with our client data.

And since I’ve learned the hard way (repeatedly over 2 decades) that I need to slow myself down and pay attention, just at the moment when I’d rather speed up & get this over with – I figure there’s no need for you to learn the way I have if I can nudge you in the right direction.

So just step back and ask yourself – what does my data look like, in it’s rawest form – before you commit. Do that regularly and you should be just fine.