00:00:00
00:00:01
Zach Bowders on Data-Driven Design: Navigating Inspiration, Innovation, and Client Collaboration
545 Plays2 days ago
In this episode of the PolicyViz Podcast, I talk with Zach Bowders on the intricacies of data visualization, the impact of dashboards on decision-making, and the fine line between plagiarism and inspiration. We discuss the importance of context-driven visualization choices over rigid adherence to traditional formats and highlight the need for flexibility. Our conversation stresses the balance between complexity and user familiarity, the value of learning from failures, and the necessity of client engagement to accurately meet their needs. We also talk about the challenges inherent in building trust with clients, sharing sensitive information, and the implications of changes to the Tableau public license for small nonprofits.
Keywords: PolicyVizPodcast, DataVisualization, JohnSchwabisch, ZachBauders, Dashboards, DecisionMaking, PlagiarismVsInspiration, TableauConference, InnovationInDataViz, FlexibilityInDesign, ContextDrivenChoices, VisualizationMethods, LearningFromFailures, DashboardDesign, ClientEngagement, StJudeResearch, TerminologyPrecision, ClientTrust, SensitiveData, TableauPublicLicense, Nonprofits, OriginalityInDesign, CitingInspiration, AttributionGuidelines, SkillDevelopment, ContinuousLearning, TechnicalSkills, SoftSkills, DataPlusLovePodcast, PodcastEpisode, CreativeFields, DataVisualizationChallenges, mathematics, Al, machine learning
Subscribe to the PolicyViz Podcast wherever you get your podcasts.
Become a patron of the PolicyViz Podcast for as little as a buck a month
Follow Zach on Twitter and find his podcast Data+Love on Spotify
Follow me on Instagram, LinkedIn, Substack, Twitter, Website, YouTube
Email: [email protected]
Transcript
00:00:13
Speaker
Welcome back to the Policyviz Podcast. I am once again your host, John Schwabisch. Hope you're having a nice start to fall. Hope you are safe if you are down in the southeastern part of the United States where we just had a hurricane blow through. I'm excited for this week's episode of the show. I've got Zach Bowders on the show. You might know Zach as a host of the Data Plus Love Podcast. Zach and I had a lot of fun in this one.
00:00:37
Speaker
Not just because we got to get back together after seeing each other at the Tableau Conference a few months ago, but because we recorded the conversation you're gonna hear today and then we flipped roles and Zach interviewed me and you can listen to that episode on his podcast, Data Plus Love. I'll link to it in the show notes. But for this part of that kind of almost two hour conversation, I talked to Zach about a few things. First off, we talk about his perspectives on data visualization rule makers and rule breakers. So we talk about data visualization rules. I put that in quotes, depending on your perspective. And we talk about Zach's perspective on rules in the data visualization field. We also talk about his thoughts on dashboard creation. What does it mean to make a dashboard? Are people doing too much when they're creating dashboards?
00:01:28
Speaker
um do Featured dashboards that you see out there in the Tableau world and the Power BI world on social media. Do they promote too many flashy things that aren't actually helping people make decisions? So we talk a lot about that. And then we also talk about inspiration and we talk about plagiarism.
00:01:49
Speaker
inspiration, copying, and an homage to data visualization. So we talk about a lot. There's a lot going on here. It's a really fun conversation. I think you're going to learn a lot. I think you're going to enjoy this. Zach is really fun to chat with. So I hope you listen to this. And then when you're done, head on over to his show, Data Plus Love. Subscribe to both channels. Make sure you listen to that one so you can hear me talk about some of the things that he wanted to pester me on. So hope you enjoy that. Here's my conversation with Zach only on the policy of his podcast.
00:02:19
Speaker
Zach, Zach, Zach. How are you doing, buddy? It's going great, John. How are you? ah that's Good. Good to see you again. Uh, let's see. we We saw each other Tableau conference, which was May. That is correct. I met you over jelly beans. Oh, right. Right. That is the one thing I will give props to of many of the things to Tableau conference is the snacks are are pretty good.
00:02:42
Speaker
It's you have to have a strong snack game to keep people engaged. ah You're getting long days and you're playing them with lots of alcohol in the evening. So you want to keep that sugar high rolling during the day. Yes. I also appreciate the fact I think I think last year in Vegas that it was a Pepsi town, but they had Diet Coke in the room, which I really appreciated their understanding for us Diet Coke aficionados. Wow. i did Okay. First of all, the fact that you even recognized like that the branding of a town or a region was impressive to me, but Like I never even picked up on that. So that's, that's how dedicated you are. um I'm dedicated and it's gotten worse because somehow Pepsi has the contract for all like the major airports. So at at DC national and DC Dallas, when I fly out, it's just Pepsi products. So you have to wait to get onto your flight to actually get the, uh, your soda of choice. Um, which is a real shame. It's a real shame. Anyway, you've got a lot of stuff going on these days.
00:03:38
Speaker
I try, I dabble. You dabble. Um, so let, let's talk about a few things I've seen you been talking about here and there. You have this post in your sub stack about rule breakers and rule makers. And so I'm curious about your take on those two groups and also how you think about rules when it comes to database. Like, do you subscribe to their strict rules or is it pretty loosey goosey?
00:04:04
Speaker
I sort of inspired it. I came up with this post and I've sort of expanded on a couple of times revisiting it back when Top Gun Maverick came out, which was yeah a movie that I don't think anyone had high hopes for because you're making a sequel to a 1980s movie that was kind of a cult classic. Like you're not expecting much. And it was kind of the movie that ended up saving theaters because everyone had tanked during Covid and they needed money.
00:04:27
Speaker
Um, but watching Top Gun Maverick, um, one of the things that sort of inspired me, and this is really weird that I'm sitting there in the theater thinking this, but, um, Maverick should be like, you know, an admiral or a Senator or something. Like he's pushing 60, but he still wants to be a pilot and he has been tapped.
00:04:45
Speaker
to teach ah younger versions of him how to fly what is effectively billed as a suicide mission. Like, we need this thing done. We don't expect all the pilots to make it out. And here's how you're going to teach it. But as a highly skilled individual contributor, Maverick sort of recognizes things that can be done.
00:05:05
Speaker
that the top brass don't necessarily recognize like he's totally familiar with the aircrafts their capabilities what pilots can pull off. And he has his own way of teaching from the middle sort of like leading from the middle and that's sort of where this sort of things started for me and then I started thinking about the two personas of the characters in the top 10 series there's the Mavericks which are the people that sort of push the boundaries and you know, sort of want to ah push things to their limit and see how far they can go. And then there's the ice man who's the buy the books kind of rulemaker guy who understands ah what what you should be doing, how to do it and how to execute it perfectly in that way. And how in data and in many other fields, honestly, there's sort of a a need for both of these things.
00:05:50
Speaker
because it's very important that we do have best practices, right? There are things that have been tried and tested and work consistently and effectively. And then there are other times when we really need people out there doing weird things that sort of push us forward. Like we we come up with new charts like spark lines or comet charts and stuff like that. And if we just followed the books and did stuff the way they'd always been done, we wouldn't have these new tools. And while many of these new tools or new practices may not always be useful,
00:06:19
Speaker
there may be a use case where they're the perfect thing. And while many of these rules and best practices are usually effective, they're not always effective. And there are some times where you might have to pivot, change your perspective, or do something different.
00:06:33
Speaker
One thing that I, I sort of, I debate this in my head a bit because, um, when I teach folks, I'm like, okay, so pie charts should sum to a hundred percent. I sort of say like, is that a rule or is that just like if to me, I'm like, that's just common sense. Like it should just like some 100%. So are there things within sort of the existing, I guess, corpus of data is that you subscribe to that you're like, you should never ever do. This bad thing or this other thing.
00:07:02
Speaker
It's funny because when I started writing these, um at the time there was somebody that really saw me as a real maverick. Like they thought I just had no regard for for rules insanity and And in reality, I think most people are a synthesis of both of these things. Like very few people are wholly rule-based and very few people are, I recognize no rules. I think for me, one thing that I had seen, um I had seen someone touting a dashboard and on this dashboard, they were using donut charts to represent percentage change over time. And I immediately just set off all these alarm bells for me and I was like, well,
00:07:36
Speaker
your percentage change could be greater than 100%. And it could also be a negative number, like this is an ineffective chart for this. So it's like, that was a a very clear case of like the Iceman and me being like, that's not a great chart for this. And there are other times where like, let's say someone needs you to create a sort of navigational tool and you might end up using a BI tool to essentially create a UI, which is definitely not an out of the box functionality. That's a real,
00:08:04
Speaker
Maverick move, but it's something that knowing the capabilities of the tool and what people can recognize ah with a common user interface that you know, Oh, I can build this thing. And while it's not typical of what you might use this for.
00:08:17
Speaker
it's definitely an effective use of that. So it's like, those are two different cases where it's yeah two entirely different things, but um sort of recognizing that sometimes ah there is a need to flex past what is sort of recognized as the standard. And there are other times where this thing is sort of out of standard. It's probably needs to be something more conservative.
00:08:39
Speaker
Right, so so you use the word effective there, which is the which is kind of the language that I like to use, like effectiveness, clarity, not like simple or good or bad, because as you just mentioned, it depends on who your audience is and and what you're doing. For you, and I'm just looking at your background, right? You've got like this cool beast worm chart and you've got this like radial chart. Like for you, when you think about breaking out of the standard whatever the show me tab and tableau or that just the dropdown in Excel. Like when, do you have some go to graphs that you go to first as like beyond the lines and bars and pies? I think it really comes down to your data type, um, what you're exploring and what you're trying to understand. So I've really been in love with network diagrams lately. Uh, and a lot of that's because it's something that has gotten a lot easier ah very, uh, very recently. So I'm able to.
00:09:34
Speaker
ah turn turning them out quickly understand if it's a good use of a network diagram or not. I tried making a NCAA Final Four bracket using a network diagram and it worked but it wasn't effective.
00:09:49
Speaker
I also tried doing a family tree using one and it was disastrous. It was, it was wholly ineffective. It was a bad use case, but I was like, you know what? I tried it. It didn't work. It's like I, what I'd learned was that this doesn't work this way. I mean, there might be a way to do it, but I didn't learn that way. So it's a, I think, uh, was it Edison that said he learned like a 10,000 ways how not to create a light bulb. I think sometimes it's important to have those opportunities for failure.
00:10:14
Speaker
ah whether it be ah necessarily through your work product that you're delivering at work or through your extracurricular activities, to take some swings out there, see what works and what doesn't, and at the end of the day, ah even if you just learned that doesn't work, that's one thing you've eliminated in the future. You mentioned dashboards earlier, and since you are neck deep, ear deep in the tableau world, and you've written about dashboard design and effective dashboards, how do you think about these sort of best practices in the dashboarding world? Because I think, I think one thing I hear from folks is like, well, I can create a more complicated, maybe less familiar graph because people have the opportunity to filter, click, hover, and they can sort of learn through the interaction how to read the graph. But I wonder if you approach it in that way.
00:11:08
Speaker
I think, I think, um, standards are the sort of bumper lanes, um, of learning. So like, if you're at the bowling alley, you know, they can, they can put those things that pop up on the gutters that keep the kids from just throwing gutter balls all day long. Um, and I think they're highly effective for, for sort of bringing people along and teaching them, uh, like keeping teaching them best practices. So for example, if you create a dashboard template where there's always a header and a footer and stuff like that,
00:11:35
Speaker
that's very effective for getting people used to the idea that I probably need to say what this is and I should have a date on it somewhere so people know when it's from. They may not even be thinking about these things consciously, but as the person building it, it's sort of ingraining that. And also for the user, it's teaching them like, I should probably understand what this thing is before I start reading it. And I should probably look down there to see if it's even current. um But I think ah it all begins with audience and understanding what people will and won't understand.
00:12:03
Speaker
And also understanding ah what they're looking for out of it. So I always ah tell sort of people I'm mentoring, like, don't just read the requirements document and go start doing that because it's like you don't necessarily understand what they're actually looking for. They have told you this.
00:12:19
Speaker
But what you really need to start understanding is the kind of decisions they're going to need to make based off of this. And then look at what they've asked for and say, does that actually deliver that? Because you can perfectly execute on a requirements document and create something that is an abysmal failure. And that's sort of the difference between someone that is like just a pure IT t technician that's just going to deliver on requirements like an engineer and an analyst who needs to be more thoughtful and sort of insert themselves in the process between sort of the end product and the user and say,
00:12:49
Speaker
But what are we really trying to get to here? Like what do you actually need to know? Because I can give you those things that you asked for, but that doesn't get what you need. Right. Can you talk a little bit more when you're working with students or clients and you have this requirement document? Like it sounds like it's almost just slightly insufficient to sort of get all the answers that you need when it comes to building something for someone.
00:13:11
Speaker
I typically assume they are. um I think that's the most reasonable place to start. um It's very rare that your client knows everything that they need um because oftentimes they're not an expert in how to communicate the data. They might be an expert in the processes.
00:13:29
Speaker
or the business that they they work within, but they may not necessarily know the best ways to communicate that. So you might get something where someone says, I need a pie chart that shows this. What they're trying to understand is the parts to a whole representation of something. And in their head, the pie chart is how you represent that.
00:13:44
Speaker
You could make the pie chart that shows that, but if they're asking for something that shows 50 different products, like that pie chart's going to be garbage. It's going to take up a lot of space. It's going to have a million wedges. ah One or two of them might actually be legible, um and you've delivered exactly what they asked for, but it doesn't help them understand it better. If you put that into a histogram or something else, they had much more easily see all of them. um They would be able to see the relative comparison to each of them, and they would all be legible in you know a similar size where all the text is readable and on the page. so ah That's just a simple example of, you know, sort of interpreting what they're saying and and sort of abstractly thinking and applying that based on your expertise and knowledge. Do you have like a document that you asked them to fill out and then, like, is your next step after that? So they say, you know, they fill out this document, they say, yeah, I want a pie chart. Is your next step to talk to them so that you can filter it down some more? Is it like another form set of emails? What does that process look like for you?
00:14:43
Speaker
I think for me, it's almost always a meeting of some kind. So while they may present you with a hey, this is what we're looking for going back then and asking questions and not being afraid of sounding foolish or dumb, like asking stupid questions that seem overly simplistic. So I want to make sure I understand when you say X, does it mean X or does it actually mean something else? I previously before I where I now work ah as a ah consultant with JLL, I work with Fortune 500 companies all over the world.
00:15:13
Speaker
um But previously I spent 13 years working in fundraising for change St. Jude Children's Research Hospital. So um I primarily worked with a program called Partner and Hope, which is a monthly giving program. So the idea being every month people's credit cards are ah debited or they send in a check or something. And we can know sort of predict out fundraising for years based on the predictability of these payments across various programs. ah So when someone would say something like, I want to know what the rate is of partner and hope giving, ah you need to ask, OK, when you say partner and hope giving, do you mean the entire program? Do you mean the DRTV function of it? ah Do you mean checks? Do you mean ah credit cards? Because the answer can be very different depending on the slice you look at it from. I remember I had a conversation once with someone who was a program manager within that.
00:16:04
Speaker
And I had done some projections for her. And she was looking at it and saying, well, this is wrong because there's 12 months of giving in each year. And I said, right. But not everybody starts on the first month of the year. Many of these people are going to be acquired during the year. So rather than expecting every single, you know, the first yeah month of the year to have all of your gifts hitting there and then continuing throughout the year with attrition dropping off, you're going to have new people coming in later in the year. You're going to have people that only gave one gift and dropped off.
00:16:34
Speaker
And it's sort of ah being able to use the historical trends of this to project it that you know we're able to look at that. So it's one of those things where the common knowledge of there's 12 months in a year, donors give 12 months. yeah I would expect that to happen across all 12 versus the reality of it. Not everybody starts giving in January. Many people will sign up for the first time in June. Yeah.
00:16:57
Speaker
Yeah. It's really interesting. I mean, how does that conversation differ when it's, I'll just make this general, like a non data person versus more of the data analyst person. Like, do you feel like you can use like different terms, maybe be a little more honest with like the data person? It depends. Um, and I think it's based on their level of comfort and their level of experience and also.
00:17:18
Speaker
ah Sometimes people have a lot of sort of preconceived notions about their own data and their own processes. And also perhaps you know you might inadvertently be contradicting something that they had previously experienced. So in your own findings, you might have to advocate for something that is not common sense to what they understand.
00:17:38
Speaker
um So that that's why I always typically do a a data exploration process at the beginning of every project where I can sort of show them a subset of their data, do some validation, say, is this look right to you? Is this, you know, based on your understanding of how your stuff works, would you expect cancellations to be this high or is that atypical, you know, so that you can start off with some confidence in what you're actually representing before you even try to approach the topic of visualization. Because if people don't have confidence in the data to begin with, whatever you make with it is also then going to be severely flawed and you're going to be in a perpetual cycle of validation and ah there's never going to be any real buy-in to what you make at the end of the day.
00:18:19
Speaker
Yeah, that's a really interesting, I guess, I don't know, challenge that we have when it's working with sort of the, I don't know, the non data folks versus, versus the data folks. I'm also curious on a kind of more of a technical question. So I assume you're spending most of your time in Tableau. That's correct.
00:18:37
Speaker
So this has come up actually more recently over the last few months ah with folks that I work with who are making dashboards for other folks and they've been having difficulty sharing the actual, and it might just be what you just said, like the first round, right? The first, the first view. And I'm curious from a technical standpoint, how do you.
00:18:58
Speaker
share your dashboard drafts, early versions. Are you putting them on your Tableau public? What about folks who don't want their stuff up in Tableau public? You're working on a desktop. Technically, like how do you do this sort of iteration process with your clients? I'm fortunate that my clients are, you know, we're I'm working with fortune 500 companies, but we're all using common server instances. So whatever I share, or they can access. We can permission it so that they have access.
00:19:24
Speaker
I mean, I've done ah teaching outside of this where I've done stuff with like Emory University and stuff like that. And typically for things like that, I can just put it on my tableau public and hide it. um None of it's sensitive information, but it's like I don't want them accessing stuff in advance. I want them to sort of access it as it becomes relevant to what we're teaching rather than them just being able to go out and like, oh, I want to see what lesson three is. And, you know, maybe get confused because they haven't you know had lesson than two yet. um So i think I do think that is an interesting challenge. Fortunately, one that I haven't encountered ah But I do think that that is a unique um ah unique challenge because people don't want their stuff necessarily on Tableau Public because with a flick of the switch it can accidentally be visible to anyone. You also don't necessarily want it to be just on you know some guy named Dave's desktop where when Dave leaves the company it's gone forever.
00:20:13
Speaker
ah And if the company isn't willing to pony up for a server or a cloud instance, I don't know what the best alternate solution is. Maybe, I mean, you're you're back to looking at cloud storage of some kind, right? Where you keep common Tableau desktop files somewhere. But many times your users aren't going to have Tableau desktop. They just need to access the thing. That's the thing. And I do wonder whether.
00:20:36
Speaker
the recent change of making the Tableau Public License where you can save it locally. I wonder if that changes the calculus for folks. Because my first instinct is often like yours, which is let's have a call and I'll walk you through it. but But what people often want then is you show them sort of like, here's the overview. Then they want to dive in and explore for themselves, see if it sort of meets their needs and their expectations. And if they don't have it in front of them where they can actually play with it, then you're in this murky world of I'm showing you, but you want to play with it, but I can't get it to you. So how do we like resolve all this? And, you know, a lot of the folks that, that, that I work with and and that we work with at Urban are, you know, they're small nonprofits, so they're not going to pony up the 1500, two grand or whatever it is for a Tableau desktop license. And that also puts you in a position where you're not able to build as interactive a dashboard. You're essentially having to create flat files for them to interact with three email or something. So you're taking, um, actions off the table. You're taking filters off the table.
00:21:35
Speaker
it's all something where it essentially has to be fully pre-baked because all they're going to see is an image as if they were seeing it in a PowerPoint deck. Yeah. Yeah. These technical challenges are interesting, I think. And I'm curious, I mean, I've heard you know a lot of people I talk to, you know they're using Tableau Server and I think that resolves a good chunk of it. um But I'm curious how others are handling ah Maybe the more common, I don't know, maybe it's the more common ah place where, you know, people are, you know, looking for freelancers are using outside folks to to do this sort of stuff. It's, it's really interesting challenge. Okay. I want to switch gears a little bit because one of the other interesting things that you've written about.
00:22:17
Speaker
and posted on LinkedIn, I think like three weeks ago and then like two weeks ago, I posted something similar. And for whatever reason, the two didn't cross is thoughts on sort of copying versus inspiration versus plagiarism. And so you have sort of a background story on this, which is on the post. but i'm So I'm curious if maybe you could tell that story. We could talk a little bit about this Venn diagram, overlapping lines. Not really sure how to draw it out, but yeah.
00:22:46
Speaker
Yeah, absolutely. So my story was ah last summer and um I like to dabble in all sorts of different topics and all sorts of his types and stuff. So I love when I find a topic and you find a niche chart that you can use for it that you don't typically use um because that's always a fun application. So it was a It wasn't last summer that I made it, but last summer was when this happened. So I'd seen a ah a data set that was about the changing sales across the music industry and how mediums are constantly shifting. So, you know, going from vinyl to eight track to cassette and CD and then how digital is ah the predominant force in the market right now. But vinyl is still kind of hanging on and coming back. um And I'd created this stream graph about it and. um
00:23:29
Speaker
At the time, I was like, oh, that was a really cool use of that. And it looks great. And it's really effective to understand where stuff comes and goes and how the market expands and contracts. And ah it was last summer. i and I know this because I was on the way to a cookout. My wife was doing a gathering with ah with a friend of hers. And I'm on the way there. And on the way there, I see from a ah sort of a ah data like news service, essentially. I'm not going to name names because i they're not the bad guy here. I'm the bad guy. OK.
00:23:56
Speaker
I'm setting that expectation forward. So I see that they have recently published um the same data set using the same chart type and it it was nearly identical to mine, ah which you would expect because it's the same data set and the same chart type. sure So I saw this and previously having been ah spurned by this organization, which I had submitted work to, my first feeling was, I can't believe you copied me.
00:24:22
Speaker
like you you turn me down and then you copy one of my things. So ah in in my in my frustration and my haste on the way to a cookout, I i put up a tweet like, i you you copied my thing and you turned me down. I can't believe it. And ah by the time I'm at the cookout, i'm I have no Wi-Fi, I have no connection wherever I am, for whatever reason. My phone's not working, but the last message I see is from my my friend and fellow Tablo visionary, Lindsey Betzendal, saying, yeah, so-and-so did that two years before you did.
00:24:52
Speaker
Hmm. And I immediately it's it's like getting hit with a ton of bricks because you realize the kind of assumptions that you put forward, which is, look, I did this thing. It's kind of a niche chart. It's a specific data set. I did this and they did this. And the other example was the exact same data set also. So right all three of us had done stream graphs of the same thing. And having said that, I had no prior knowledge to the other version.
00:25:20
Speaker
i I was like, oh, and I immediately realized how uncharitable I had been with my interpretation of the series of events, probably because I had felt personally burned by this place before. um But in thinking about it.
00:25:33
Speaker
I realized that as data professionals and understanding the tools that we have at our disposal with different charts and stuff, this is a very obvious chart type for this particular thing. And in fact, when I went back and I think you saw it in my LinkedIn post, I've found other examples of the same chart type used for the same data set. Because when you're a data person and you know what you can make and you see this thing, the shape of it becomes very logical. Oh, this is one of my options.
00:26:00
Speaker
Not everybody did that. Other people did ah area charts and other things, but many people did. And I realized, oh, what I clearly thought was a case of plagiarism is more of a case of this is this is logical. And I realized how often and how easy this can happen and based on what we interpret as, how uncharitable it can be. And that's not to say that work doesn't get copied. So if you go on Tableau Public and type in John Wick,
00:26:26
Speaker
ah You'll see visits by me, David Kelly and Kate Schaub, who each of us took on one of the John Wick movies. And then you'll see a dozen copies of each of those, where people have copied it, changed one or two things and republished it. um I personally don't care that much. I think it's great if anyone wants to download something.
00:26:45
Speaker
I don't feel like it's a threat to my reputation. I don't think it says anything about what I can do. um And i because I know what I can do, and I've i've got a plenty of track record experience. And more often than not, in fact, I would say 99% of the time, if you decide to call someone out for plagiarism, you will end up being the bad guy. um Because more often than not,
00:27:10
Speaker
ah It's it's more than likely harmless. So ah another example might be Andy Krebel famously adapted the Financial Times visual vocabulary into Tableau. It's the most viewed thing they have on there. It's got literal millions of views. ah But many, many, many, many people download and republish it.
00:27:30
Speaker
And the uncharitable interpretation that would be, this person wants to present this as if they made it. What I would probably take as the more realistic example, much like my John Wick things is, somebody thought this was interesting. They don't know how to make it themselves and would like to understand it better.
00:27:49
Speaker
They may or may not understand how to bookmark this, but they would like to take it and kind of mess with it and see what can be done. And I think that is probably the healthiest for all people interpretation of anything that feels like plagiarism. um It's not always the case.
00:28:07
Speaker
There are people out there that will take other people's work and try to present it as their own. The upside of this is it almost always burns them because they're not able to deliver the thing that they act like they can do. Right.
00:28:20
Speaker
Yeah, i the the post that I had um was was a really interesting case. It was from the European correspondent, which is a relatively new volunteer led news organization. And and I have really come to love their visuals, right? Like every day you get a newsletter and i rare'll I'll be honest, I rarely read all the texts because it's about Europe and I'm in the US and you know, but their their data database is really good. And they had a visual of um terrorist attacks.
00:28:50
Speaker
And it was, you know, the title was something like terrorism's bloody toll, right? And it had this like red bar chart, you know, ah inverted vertical bar chart and it was all red. And it like was really evocative of Simon Scarr's visualization from years ago. um Iraq's bloody toll. I mean, even down to that title, right? And so, but I wasn't sure because an inverted axis is not the most uncommon theme.
00:29:16
Speaker
ah thing to see but with the combination of the title and the inverted bar so I asked this question on on LinkedIn and I think a lot of people said you know this is pretty pretty blatant and unfortunately the EC folks wrote in and they were like yeah we were inspired by Simon's stuff and this is what we did and so then it becomes like then there's this weird like I was inspired by this great work I wanted to use it do I need to cite it? How should I cite it? I mean, that i mean then you get into these practical weeds of like, should I just write inspired by? Like, where should that go? So yeah, it's a really interesting question, I think. And I think it's also, where do we draw the line between what is sort of in the canon of visualizations versus what's kind of like, what's the new thing, right? Like bar charts, line charts, we' not
00:30:08
Speaker
citing Playfair. but you know like so So I don't know where this this line is, where there is a line, inspiration versus plagiarism versus an homage right to to someone else's work.
00:30:21
Speaker
I think that's a ah great ah great example because you know in the field of art, there are many people that are imagining someone else or taking a technique learned from someone else. like If no one ever sit on the shoulders of anyone else, our field would be absolute garbage and everyone would just be generating their own things. we We would never be progressing and learning. And that that goes back to that sort of Iceman and Mavericks dynamic I was talking about. But I think like it's very important that people feel safe to be able to use an idea I don't know where the threshold is for crediting or calling out. I don't know when it becomes copying versus homage versus learning. I mean, if you use a spark line, do you have to mention Edward Tufti every time? You probably don't. um
00:31:06
Speaker
But like if you use that in conjunction with something else, is that does it then be something you need to attribute? And I think it's just such a murky gray area. I don't think there's a clear answer. like i I enjoy comic books a lot. So if you did, i say, a a cover where you're recreating a very similar image from something else, they'll typically put after so-and-so because you're clearly homaging whatever. um Right.
00:31:31
Speaker
I think it's way less clear in what we do and I mean like yeah like you were saying with the ah with the sort of you know The are the Iraq's bloody toll how they use the the ah inverted bar chart to simulate blood drips and stuff Which I know I I brought this up Andy ah Andy Cocker even I had a debate about this once where Andy's like I loved it so effective I'm like I thought it was so grotesque and offensive like but it's like both of those are are you like as long as you can sort of articulate where you're coming from I don't think either is necessarily an unreasonable answer and I don't think like my sensibilities should determine what should be made. But I think, ah you know, people are going to do that. It's a very logical but thing to do. I mean, the fact that they use the same wording, I think that brings it a lot closer to the idea of being a copycat and knocking it off. But at the same time, like that's an iconic piece of work. It's like it seems like an homage. And I just think we sort of lack the tools and maybe institutional knowledge of how we should be crediting these things or in many cases like
00:32:27
Speaker
the example I had like you don't even know you're you're doing the same thing as someone else because sometimes it seems like a very logical chart choice. Yeah. And then there's also the case where like stuff doesn't exist online anymore or like also like you have this like echo in your mind of oh maybe I saw this thing but I can't remember who or what so like I'm gonna make my thing and But I do like your point about making something and then maybe not being able to sort of suggesting that you have a skill that maybe you don't actually have, right? You have either a creative skill or a technical skill to build this thing where really all you did was download Zach's Tableau workbook. You're able to change the data, but you couldn't make it some from scratch. And, and I think that sort of ends up revealing itself over time.
00:33:19
Speaker
I think that stuff always comes to light fairly rapidly, particularly if you're sort of using that thing to you know try to get a job. um I think that's why so many ah jobs that are more technical in the field of of you know visual intelligence um literally require you to do some kind of work to demonstrate it. um And i'm sure i'm look I'm sure people fake that too and pay someone else to do it. But then when you get the job and you can't deliver for the first six months, it's not going to last that long. it's like That's why it's important to work on developing your own skills and continually learning and progressing. Like, well, none of us may actually be able to own any of these these charts, like at the end of the day, right? Like, yeah we're all sort of doing remixes of remixes of remixes. We understand what all the ingredients are. and And your recipe is just a little bit different than mine. Like, well, at the end of the day,
00:34:08
Speaker
we may have started with the same data set and we we created similar things that you know show similar facets of the data. um I don't know if I can really own any of that. you know It might be something I made, but I don't get to tell other people that they can't do the same thing. So I'm curious as as we wrap up, I'm curious on this learning and progressing, what you are working on these days that you feel you are learning and progressing on.
00:34:36
Speaker
Well, I think for me, I sort of alternate between hard skills and soft skills because I think the two are equally viable. And I think sometimes we put an overemphasis on the hard skills. um So I found ah that when I was in my periods of sort of very hard skill centric, it's like when you have a hammer, every problem is a nail.
00:34:54
Speaker
And understanding that you have two different lobes of your brain, however you want to look at it. There are many times when a client is asking for something and really applying those soft skills and better understanding the business processes, understanding the players, understanding what they're asking.
00:35:10
Speaker
you may not even need a technical solution. Many times it's just better understanding the ask, understanding the user, understanding the need, ah can really transform how you approach something from a technical perspective. So rather than immediately rushing towards, oh yeah, like I could write a calculation that could do that, or these two charts in conjunction can show this thing, um start start better understanding ah the the people and the players. And it's something I have to relearn perpetually. And I think that's,
00:35:39
Speaker
ah That's just, ah ah maybe I'm Sisyphus, and maybe I'm pushing that that stone up the hill every day and just having to relearn stuff all the time. But it is funny how ah youll you'll feel very confident in one area and then you'll realize you're letting the other slide. So right now for me, I'm putting a lot of work back into people, ah people and understanding and that sort of thing. So ah that means the technical end will probably slip. I'll probably fall behind in some areas there and I'll need to play catch up at one point. But I've learned for me at least the two very rarely happen simultaneously.
00:36:08
Speaker
it's It's very infrequent that I'm able to develop both at a similar pace. Like I sort of have to alternate between the two. And that's not bad. That's just that's just what it is for me. And other people may not have the same experience. Right. Well, my friend, great to have you on the show. um Where can people find you for more details on your work?
00:36:29
Speaker
Uh, you can check me out on Twitter slash X at, at Zach powders. You can check me out on LinkedIn at Zach powders and search for my Tableau public profile. Zach powders. I am also the host of the data plus love podcast where we have, uh, actually many of John's guests on too. Um, we we have, but well, we have, we have similar
00:37:08
Speaker
Thanks for tuning into this week's episode of the show. I hope you enjoyed that. I hope you'll check out Zach's podcast, Data Plus Love. Don't forget, there's an episode with me featured in late September. You can check that out. Listen to him pepper me with questions. And of course, If you're watching this on YouTube, like, subscribe, whatever you need to do, let me know you're enjoying this. show. And if you'd like to learn more about data communication, you should check out my sub stack newsletter. It comes out every other week along with the show. So you get a preview of what's going to show up in the podcast along with a variety of other things. So until next time, this has been the policy of this podcast. Thanks so much for listening.