July 20, 2026 • 21 mins
A practical guide for developers to implement effective digital graphics using various code libraries. The text emphasizes that simplicity and clarity are paramount, as familiar formats like bar and line charts allow users to interpret data intuitively. By utilizing tools such as Flotr2 and D3.js, the author demonstrates how to construct interactive and static visualizations through step-by-step technical instructions. The source covers a wide range of applications, from geographic mapping and timelines to specialized structures like heat maps and word clouds. Additionally, Thomas addresses real-world development challenges, including cross-browser compatibility and debugging third-party library issues. Ultimately, the book serves as a roadmap for transforming abstract numerical sets into compelling, data-driven web applications.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Data-Visualization-JavaScript-Stephen-Thomas-ebook/dp/B00V20IFDG?&linkCode=ll2&tag=cvthunderx-20&linkId=a8d31698ffc4b51db32b2e8332ca15a5&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Data-Visualization-JavaScript-Stephen-Thomas-ebook/dp/B00V20IFDG?&linkCode=ll2&tag=cvthunderx-20&linkId=a8d31698ffc4b51db32b2e8332ca15a5&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Imagine you just pulled up to a gas station. You
put the nozzle in your car, you squeeze the handle,
and you pump twenty gallons of fuel. But like there's
this massive leak in the hose. Oh no, yeah, so
out of those twenty gallons, nineteen point nine gallons just
drip directly onto the concrete highway.
Speaker 2 (00:21):
That's terrible, right, you.
Speaker 1 (00:22):
Only actually get a few drops into your engine. I
mean that sounds completely.
Speaker 2 (00:25):
Absurd, right, it really does. But you know that is
exactly what is happening to our information right now.
Speaker 1 (00:30):
Exactly.
Speaker 2 (00:30):
We hear constantly about how much data we are generating
as a society, but the reality of how little we
actually use is staggering.
Speaker 1 (00:40):
It's crazy. One widely cited estimate suggests that ninety nine
point five percent of the data our systems collect just
goes to waste.
Speaker 2 (00:48):
Wow.
Speaker 1 (00:49):
Yeah, it just sits on servers, completely ignored. And the
reason for that massive waste is what we are tackling
in today's.
Speaker 2 (00:55):
Deep dive, which is such an important topic.
Speaker 1 (00:57):
It is our mission today is short cutting your path
to becoming a master of visual communication, because raw data,
by its very nature, is just an abstract headache for
the human brain.
Speaker 2 (01:10):
Right, Our brains aren't built for raw spreadsheets, No.
Speaker 1 (01:13):
They aren't. So we are pulling some incredible insights today
from a book by Stephen A. Thomas called Data Visualization
with JavaScript.
Speaker 2 (01:21):
And you know what I love about this specific book
is that it doesn't just treat charts like magic tricks, right.
It acknowledges that effective visualizations are really the only way
to transform those abstract, raw numbers into a shape that
the human brain can actually process, yeah, making it digestible exactly.
When a chart is built perfectly, you free the viewer
(01:43):
like they don't have to decisive the math, they just
get it. Yeah, they can just focus entirely on the
store that the data is trying to tell. But you
cannot build that kind of seamless experience unless you understand
the mechanics happening under the hood, Which means.
Speaker 1 (01:56):
We aren't just going to sit here and talk about,
you know, what makes a good chart on a theory
medical level.
Speaker 2 (02:00):
No, we're getting into the weeds.
Speaker 1 (02:03):
We really are. We are actually going to look at
how they are built. We're going to explore the underlying
logic of open source tools, specifically focusing on a JavaScript
library called flat ru two.
Speaker 2 (02:15):
It's a great tool.
Speaker 1 (02:16):
It is we are getting into the nuts and bolts
of how a computer draws a story. But before we
can start building complex, dazzling interactive graphics, we have to
master the absolute workhorse, the foundation, right, and I'm talking
about the simple bar chart.
Speaker 2 (02:32):
It really is the foundation of everything. I mean, you
have seen thousands of bar charts in your life, which
means there is zero learning curve for the viewer.
Speaker 1 (02:40):
Yeah, totally intuitive.
Speaker 2 (02:42):
The convention is so baked into our psychology that you
just absorb the information. But actually building one from scratch
reveals some really fascinating mechanics about how computers and humans, well,
they disagree on what makes sense?
Speaker 1 (02:54):
Yes, and the book walks us through a brilliant example
of this. Okay, let's unpack this. Let's do We look
at the English Mere League wins for the soccer team
Manchester City. This is from two thousand and six to
twenty twelve, and the data points show their performance shifting
pretty dramatically. They started thirteen wins in two thousand and six,
they drop to eleven wins in two thousand and seven,
(03:14):
and eventually they climb all the way up to twenty
eight wins by twenty twelve.
Speaker 2 (03:18):
Quite a jump.
Speaker 1 (03:19):
Yeah. Now, to get this data onto a web page
using that flow year two library, you can't just type
the numbers onto the screen. You have to use an
HTML canvas.
Speaker 2 (03:28):
Element right, And for anyone who hasn't built a web page,
think of an HTML canvas exactly like it sounds. It
is a literal, blank, invisible rectangle that the browser sets
aside on your screen, like a literal canvas exactly. It
doesn't process texts like a normal web page. It's a
dedicated sandbox specifically for a JavaScript library. To draw raw pixels.
Speaker 1 (03:50):
And to tell the library what to draw in that sandbox,
you have to feed it nested to raise a data
so you package the year and the wins together as coordinates.
Speaker 2 (03:58):
Sounds straightforward enough.
Speaker 1 (03:59):
It does, But here's the catch. If you just feed
those coordinates in and let the library use its default
mathematical settings, you run into a massive problem. The default
algorithm automatically calculates the vertical axis the y axis based
purely on your lowest and highest data points, so it
zooms in. Yes, because Manchester City's lowest number of wins
(04:20):
was eleven, the bottom of the chart starts.
Speaker 2 (04:23):
At eleven, which is an issue.
Speaker 1 (04:25):
Well, wait a minute, let me push back on this
for a second.
Speaker 2 (04:27):
Okay, go ahead.
Speaker 1 (04:28):
If I am a computer programmer, I might argue that
the computer is doing exactly what it should if the
data only exists between the numbers eleven and twenty eight.
Isn't starting the axis at eleven mathematically the most precise
way to show that specific variance? Technically, yes, right, So
why are we overwriting the computer when its math is
(04:49):
technically correct?
Speaker 2 (04:50):
That is the perfect question because it highlights the fundamental
difference between mathematical precision and human visual processing.
Speaker 1 (04:57):
Okay, how so.
Speaker 2 (04:58):
Well the math is correct visually, it is a total disaster.
When we look at a bar chart, our brains don't
just read the numbers on the side. We process the
proportion of the shapes. Oh, I see, We inherently believe
that if one bar is twice as tall as another,
the underlying value must be twice as large.
Speaker 1 (05:15):
That makes total sense. It's like cropping a photograph so
tightly that you lose all the background context.
Speaker 2 (05:21):
That's a perfect analogy. So if the bottom of your
chart is set to eleven, the bar for the year
two thousand and seven, where they won exactly eleven games,
completely disappears.
Speaker 1 (05:31):
Oh wow, because it's at the absolute bottom exactly.
Speaker 2 (05:33):
It has zero height. It's just a flat line on
the floor of the chart. To anyone quickly glancing at it,
it visually implies that Manchester City won absolutely zero games
that year.
Speaker 1 (05:44):
Right. Think about the last stock chart you looked at
on your phone. Did you actually check where the y
axis started? Probably not, because if it didn't start at zero,
you might have panicked over a visual drop that was
actually minuscule. In reality, it's a huge blind spot.
Speaker 2 (05:57):
Exactly. You end up manipulating the viewers perception of reality,
even if you did it completely by accident.
Speaker 1 (06:03):
Yeah, the visual.
Speaker 2 (06:04):
Distance between eleven wins and twenty eight wins looks like
a catastrophic chasm if eleven is.
Speaker 1 (06:09):
The floor, right, But when you go into the code
and manually force the y axis minimum to zero, the
eleven wind bar suddenly has weight.
Speaker 2 (06:17):
It changes everything the viewer sees.
Speaker 1 (06:19):
The true proportional difference. It was a bad year, sure,
but it wasn't a total failure.
Speaker 2 (06:25):
And while you are in the code fixing the axis,
you also have to fix the computer's assumptions about the
numbers themselves.
Speaker 1 (06:31):
Oh right.
Speaker 2 (06:32):
Because the computer algorithm assumes all data could potentially be fractions,
it helpfully adds decimal points to the labels. On the side.
Speaker 1 (06:38):
You cannot have fifteen point zero soccer.
Speaker 2 (06:41):
Wins exactly, so you pass a quick option in the code.
It's tick decimals zero. It cleans up the labels.
Speaker 1 (06:49):
It really proves that the code might be mathematically sound,
but you constantly have to manually adjust it for human reality.
Speaker 2 (06:55):
It is a constant translation between machine logic and human intuition.
Speaker 1 (06:59):
Okay, so forcing a zero baseline fixes a static bar chart,
but that really only works for discrete, separated moments in time.
What if we're tracking something massive and continuous, like say
climate change over fifty years.
Speaker 2 (07:12):
That gets tricky.
Speaker 1 (07:13):
Yeah, a bar chart with fifty individual pillars would just
look like a crowded fence.
Speaker 2 (07:17):
The trend gets lost. How does the code handle decades
of continuous movement? That is where you have to transition
to line charts. They really excel at revealing the overall
narrative in massive data sets without bogging the viewers bring
down in the individual year by year data.
Speaker 1 (07:33):
Points, and the book uses this incredible data set from NOAA,
the National Oceanic and Atmospheric Administration. It's a great example.
It spans over fifty years tracking the carbon dioxide concentration
in the atmosphere from Manola, Hawaii alongside the global surface
temperature deviations for that exact same time period.
Speaker 2 (07:53):
Which presents a notoriously difficult challenge for a developer. You
are trying to plot two very critical but very different,
currently measured metrics on the exact same piece of digital paper.
Speaker 1 (08:03):
Here's where it gets really interesting. We are talking about
putting two completely different scales on the same.
Speaker 2 (08:09):
Chart, the double access dilemmas exactly.
Speaker 1 (08:11):
You have CO two, which is measured in parts per million.
Those are large absolute numbers in the three hundreds and
four hundreds, right, and then you have temperature deviations which
are measured in tiny fractions of a single degree celsi's
numbers like zero point zero seven or point one.
Speaker 2 (08:24):
Two, So completely different scales.
Speaker 1 (08:27):
If you just overlay them, the grid lines clash, the
values don't align, and the viewer just gives up. But
beyond the formatting, the whole concept of a deviation metric
is confusing. It really is the temperature values aren't absolute temperatures,
they are deviations from the twentieth century historical average. So
how on earth does a developer make that historical average
(08:49):
clear to the end user without just slapping a giant
paragraph of explanatory text onto the screen.
Speaker 2 (08:55):
What's fascinating here is one of my favorite techniques in
the book. The author uses a brilliant yet incredibly simple
coding trick.
Speaker 1 (09:02):
I love this part.
Speaker 2 (09:03):
To represent that twentieth century average baseline, the coder literally
injects a completely fake dummy data set into the JavaScript array.
Speaker 1 (09:13):
Wait fake data.
Speaker 2 (09:14):
Yes, for every single year from nineteen fifteen nine to
twenty twelve, they add a corresponding data point of exactly zero.
Speaker 1 (09:20):
Oh, it's like drawing a firm line in the sand,
so you can accurately measure exactly how far the tide
is coming in.
Speaker 2 (09:26):
That's a great way to think about it. And they
don't just leave it looking like a normal line of data.
What do they do in the code? They style this
specific zero line to be only one pixel wide. They
color it a dark, subtle gray, and they completely disable
its drop shadow, so it blends in exactly. By changing
those visual properties, it stops looking like a data set
to the human eye and starts looking like a piece
(09:48):
of the charts structural framework.
Speaker 1 (09:50):
It creates an instant visual anchor. You don't have to
read an explanation. Your brain immediately understands that anything above
that gray line is warmer than the historical average, and
anything below it is cooler. It's so intuitive, And the
author does one more subtle thing in the code that
I found so clever. When you have multiple lines, you
obviously need a legend so the user knows what they're looking.
Speaker 2 (10:11):
At, right a key.
Speaker 1 (10:13):
By default, the computer will just list the legend items
in whatever random order you fed the arrays into the code.
Speaker 2 (10:18):
Which again is the computer just doing what it's told,
but completely ignoring human logic.
Speaker 1 (10:24):
Right. But if you intentionally swamp the order of the
data series in your code, specifically putting the temperature deviation
data right next to that dummy baseline zero data, they
get grouped together visually in the little legend box.
Speaker 2 (10:38):
Oh that's smart.
Speaker 1 (10:38):
It intuitively links the concept of the temperature with the
baseline for the viewer before their eyes even move over
to analyze the graph itself. To tiny psychological match.
Speaker 2 (10:48):
It proves that building these things isn't just about plotting points.
You are designing a cognitive experience. You are quietly guiding
the user's eye to make the right connections.
Speaker 1 (10:58):
So we've solved tracking things over continuous time. But what
if time isn't the factor at all? Okay, what if
you want to take a snapshot of the world right
now and figure out if two entirely different variables actually
cause each other, or at least correlate.
Speaker 2 (11:12):
That is the perfect scenario for a scatter chart. You
aren't looking at trends over time. You are looking for
relationships between disparate things.
Speaker 1 (11:19):
The Deep Dive moves into this fascinating twenty ten OECD
data set. It compares healthcare spending as a percentage of
a country's GDP against the average life expectancy of its citizens.
Speaker 2 (11:31):
A classic comparison.
Speaker 1 (11:33):
Yeah, the fundamental question is does spending a higher percentage
of your national wealth on healthcare actually equal a longer
life for your people?
Speaker 2 (11:42):
It is a very complex question. You are plotting dozens
of individual countries as floating dots based on those two
independent variables.
Speaker 1 (11:50):
But once again, if you just hand this raw data
to the flat er two library, the default output is
pretty claustrophobic, very crammed. The library tries to maximize the space,
so the points get crammed right against the very edges
of the chart box. The dot for the country with
the lowest spending physically touches the left wall, and the
highest bending touches the right wall.
Speaker 2 (12:09):
That's hard to read.
Speaker 1 (12:11):
It just like framing a beautiful painting but letting the
picture frame cover up the outer two inches of the canvas.
Your eyes need margins to comfortably process the words, and
data points need margins to be compared accurately.
Speaker 2 (12:22):
And while visualization libraries almost always have an autoscale feature
that tries to fix this mathematically, they often fall short
of what the human eye actually needs.
Speaker 1 (12:31):
So it's the fix.
Speaker 2 (12:32):
A skilled visualizer will look at that cramped box and
manually override the defaults. You explicitly tell the code set
the x axis minimum to five and the maximum to twenty.
You intentionally pad the axes to give the data breathing room.
Speaker 1 (12:47):
It separates the cluster of information from the boundaries of
the chart, but the breathing room isn't the only thing
the user needs. The x axis represents a percentage, bending
as a percentage GDP. But the raw data in the array,
it's just the integers five, ten, fifteen, extrail numbers. Yeah.
If you leave it like that, the user has to
look at the number fifteen, scan their eyes over to
(13:09):
the access title, read percentage of GDP, and then remind
themselves right that number fifteen means fifteen percent.
Speaker 2 (13:15):
Which sounds incredibly minor, but in the world of data consumption,
that is cognitive friction. It slows down comprehension, and as.
Speaker 1 (13:21):
A developer, you have the power to just remove that friction.
Flutoo allows you to write a custom formatting function for
the axis labels. That's really handy.
Speaker 2 (13:29):
So instead of just accepting the default integers, you write
a tiny piece of logic that intercepts the label right
before the browser draws it on the canvas, and simply
a pens a percentage signed to it. Oh nice. The
user just sees fifteen percent and instantly understands the value,
and you really want them to understand it quickly, because
the payoff of this specific data set is amazing. When
(13:51):
you step back and look at the scatterplot, you don't
see a perfect diagonal line going up.
Speaker 1 (13:56):
No, you don't, and that is exactly why you need
a scatterplot instead of a bar chart. If you just
average the data out into bars, you would miss the reality.
You miss the whole point exactly. The scatter reveals a
messy cluster. It visually proves that simply spending more money
on healthcare does not guarantee a linear, straight line increase
in life expectancy.
Speaker 2 (14:17):
Right, they are country spending less that are achieving longer
life stands.
Speaker 1 (14:20):
The spread is the story.
Speaker 2 (14:21):
It's brilliant. But speaking of cognitive friction, well, we have
to talk about the most controversial chart in the entire
corporate world, and frankly.
Speaker 1 (14:30):
The messy reality of the code that builds them. I
am talking, of course, about the notorious pie chart.
Speaker 2 (14:35):
The chart that data scientists absolutely love to hate.
Speaker 1 (14:39):
Okay, I have to play devil's advocate here. Wait, everyone
loves a colorful pie chart. They're in literally every boardroom
presentation and every quarterly report ever made. Why do developers
usually hate them?
Speaker 2 (14:50):
Well, if we connect this to the bigger picture, it
comes down to a fundamental biological flaw in how the
human brain processes geometry. Really biology, Yeah, we are actually
terrible at judging the relative size of areas. We are
very good at comparing lengths, like the height of vertical
bars in a bar chart.
Speaker 1 (15:09):
Sure, and that's easy.
Speaker 2 (15:10):
If one bar is just a few pixels taller than another,
your eye catches it instantly. But when you take a circle,
slice it into five or six irregularly sized wedges, and
then ask the human eye to rank them.
Speaker 1 (15:21):
By size to a guessing game.
Speaker 2 (15:23):
We fail miserably. Unless the difference is drastic. We just
cannot accurately compare those non rectangular areas. If you're comparing
multiple values against each other, a bar chart is almost
always better.
Speaker 1 (15:35):
Okay, fair enough, But the book actually defends them in
one very specific scenario.
Speaker 2 (15:40):
Yes it does. They are highly effective for one task
emphasizing a single fraction against a hole.
Speaker 1 (15:47):
Ooh.
Speaker 2 (15:47):
If you only have two slices and you want to
show the sheer proportion of one piece relative to everything else,
it is incredibly powerful.
Speaker 1 (15:55):
The example in the book is striking. It uses World
Bank data from two thousand and eight to visualize extreme
global poverty.
Speaker 2 (16:02):
It's a sobering visual, it really is.
Speaker 1 (16:04):
It highlights that twenty two point four percent of the
world's population was living on less than a dollar and
twenty five cents a day. Wow. When you put that
single red wedge of twenty two point four percent against
a solid, massive circle representing the rest of humanity, you
don't need to compare multiple variables. The impact is visceral
and instant.
Speaker 2 (16:22):
In that context, the pie chart strips away everything extraneous
and forces you to confront that single massive proportion.
Speaker 1 (16:28):
But actually getting that pie chart to render brings us
to my absolute favorite part of this deep dive. It
is the reality versus ideal world philosophy of the book,
which is so relatable because we tend to think of
computer programming as this pristine, perfect science where everything is logical.
But the reality is that even great widely used open
source cools have hilarious, messy corps.
Speaker 2 (16:51):
Software is written by humans, and humans use tape and
glue to hold things together.
Speaker 1 (16:56):
Exactly so the author details this known deliberate and the
Flatschow Library. When the library is trying to calculate how
big to draw the charts, the size the text, the
width of labels, everything, it has to physically create dummy
HTML elements in the background of your web browser to
measure them.
Speaker 2 (17:14):
It has to generate them to size them up right.
Speaker 1 (17:16):
But obviously it doesn't want the user to see these
weird dummy text elements popping up on the web page
while it does the mask.
Speaker 2 (17:23):
They need to exist on the page to be measured,
but they need to be invisible to the user.
Speaker 1 (17:27):
So what does this all mean? How do the developers
hide them? Well, every web page is structured using something
called the DOM, the document object model, the blueprint. It's
basically the blueprint of the page, and you style that
blueprint using CSS. The developers of this library wrote a
CSS rule using absolute positioning. They told these dummy text
(17:48):
elements to be placed exactly ten thousand pixels above the
top of the.
Speaker 2 (17:52):
User's screen using a negative value.
Speaker 1 (17:54):
Yes, they use a top margin of negative ten thousand
picks on.
Speaker 2 (17:57):
The logic being just throw it so far off the
screen that no one will ever see it out of sight,
out of mind exactly.
Speaker 1 (18:04):
But here is the catch. CSS absolute positioning is tricking.
It is like telling someone go stand one hundred feet north,
but north of what the center of the earth, the
room you were currently standing in.
Speaker 2 (18:16):
It's relative.
Speaker 1 (18:17):
That is what happens to the browser. Sometimes, depending on
how your specific web page is built, that negative ten
thousand pixels is calculated relative to a container inside your page,
not the absolute top of the browser.
Speaker 2 (18:29):
Window, which becomes a massive problem if the user's document
is extremely long.
Speaker 1 (18:34):
Yes, if you are building a massive, long, scrolling dashboard
full of charts, that negative ten thousand pisel trick completely backfires.
The browser's positioning gets confused.
Speaker 2 (18:43):
Oh, I can picture it now.
Speaker 1 (18:44):
Suddenly the user is scrolling down your beautiful dashboard and
they start seeing random pieces of invisible chart text scattering
like confetti across your website.
Speaker 2 (18:54):
It is the perfect encapsulation of how coding in the
real world actually works. You can have the most elegant
data structures, but you are still at the mercy of
a web browser misinterpreting a CSS hack from a third
party library.
Speaker 1 (19:09):
And I absolutely love the book's practical takeaway for this.
The author basically says, Look, you could theoretically go into
the open source library, dig through thousands of lines of
source code and rewrite their positioning logic to be perfect.
Or you can just be a pragmatic developer.
Speaker 2 (19:23):
Sometimes you just need a quick fix.
Speaker 1 (19:25):
He suggests just writing a single line of jQuery to
find and hide the library's messy invisible.
Speaker 2 (19:31):
Elements for those unfamiliar. jQuery is just a shortcut language
for web developers. It allows you to quickly find elements
on a web page after it has loaded and manipulate them.
Speaker 1 (19:40):
Right so, the author says, just write a quick jQuery
script that targets the specific class name of those messy
invisible elements, the dot, float, dummy div class and just
brutally forces them to hide once the chart is done drawing.
Speaker 2 (19:55):
It's a band aid, but sometimes the best solution is
the pragmatic one. It saves you hours of de and
it gets the visualization working for the user, which is
the ultimate goal.
Speaker 1 (20:03):
It is such a wonderfully messy reality check. Yeah, which
actually brings us to the most important question for you,
the listener. We've spent this time talking about arrays, HTML canvases,
y axis minimums, and CSS bugs. Why does knowing the
JavaScript logic behind these charts actually matter to you?
Speaker 2 (20:20):
It matters deeply because visual communication is a language, and
right now in the modern world, data is being spoken
at you constantly all day long.
Speaker 1 (20:29):
Exactly think about it. Whether you are actively trying to
program a dashboard at your job, prepping a slide deck
for a board meeting, or simply just sitting on your
couch trying to consume your daily news on your phone
without being misled.
Speaker 2 (20:41):
It's everywhere.
Speaker 1 (20:42):
Understanding how axes are manipulated, why data points, meat, breathing room,
and when a pie chart is actually useful makes you
a vastly sharper, more critical consumer of information.
Speaker 2 (20:53):
You stop just looking at the geometric shapes and you
start seeing the underlying structure.
Speaker 1 (20:58):
You start to recognize the choices the creator made, and.
Speaker 2 (21:00):
Even more importantly, you start to recognize the choices they
decided not to make.
Speaker 1 (21:04):
Absolutely. Yeah, so we want to leave you with this thought.
Tom all over today. Now that you know exactly how
easily a chart's entire narrative can be radically altered just
by tweaking the minimum value of a y axis in
the code, or switching from comparative bars to an unreadable
pie slice.
Speaker 2 (21:21):
Yeah, think about that.
Speaker 1 (21:23):
How much the data you scrolled past today was intentionally
designed to manipulate your perception rather than actually inform you
Imagine you just pulled up to a gas station. You
put the nozzle in your car, you squeeze the handle,
and you pump twenty gallons of fuel. But like there's
this massive leak in the hose. Oh no, yeah, so
out of those twenty gallons, nineteen point nine gallons just
drip directly onto the concrete highway.
Speaker 2 (00:21):
That's terrible, right, you.
Speaker 1 (00:22):
Only actually get a few drops into your engine. I
mean that sounds completely.
Speaker 2 (00:25):
Absurd, right, it really does. But you know that is
exactly what is happening to our information right now.
Speaker 1 (00:30):
Exactly.
Speaker 2 (00:30):
We hear constantly about how much data we are generating
as a society, but the reality of how little we
actually use is staggering.
Speaker 1 (00:40):
It's crazy. One widely cited estimate suggests that ninety nine
point five percent of the data our systems collect just
goes to waste.
Speaker 2 (00:48):
Wow.
Speaker 1 (00:49):
Yeah, it just sits on servers, completely ignored. And the
reason for that massive waste is what we are tackling
in today's.
Speaker 2 (00:55):
Deep dive, which is such an important topic.
Speaker 1 (00:57):
It is our mission today is short cutting your path
to becoming a master of visual communication, because raw data,
by its very nature, is just an abstract headache for
the human brain.
Speaker 2 (01:10):
Right, Our brains aren't built for raw spreadsheets, No.
Speaker 1 (01:13):
They aren't. So we are pulling some incredible insights today
from a book by Stephen A. Thomas called Data Visualization
with JavaScript.
Speaker 2 (01:21):
And you know what I love about this specific book
is that it doesn't just treat charts like magic tricks, right.
It acknowledges that effective visualizations are really the only way
to transform those abstract, raw numbers into a shape that
the human brain can actually process, yeah, making it digestible exactly.
When a chart is built perfectly, you free the viewer
(01:43):
like they don't have to decisive the math, they just
get it. Yeah, they can just focus entirely on the
store that the data is trying to tell. But you
cannot build that kind of seamless experience unless you understand
the mechanics happening under the hood, Which means.
Speaker 1 (01:56):
We aren't just going to sit here and talk about,
you know, what makes a good chart on a theory
medical level.
Speaker 2 (02:00):
No, we're getting into the weeds.
Speaker 1 (02:03):
We really are. We are actually going to look at
how they are built. We're going to explore the underlying
logic of open source tools, specifically focusing on a JavaScript
library called flat ru two.
Speaker 2 (02:15):
It's a great tool.
Speaker 1 (02:16):
It is we are getting into the nuts and bolts
of how a computer draws a story. But before we
can start building complex, dazzling interactive graphics, we have to
master the absolute workhorse, the foundation, right, and I'm talking
about the simple bar chart.
Speaker 2 (02:32):
It really is the foundation of everything. I mean, you
have seen thousands of bar charts in your life, which
means there is zero learning curve for the viewer.
Speaker 1 (02:40):
Yeah, totally intuitive.
Speaker 2 (02:42):
The convention is so baked into our psychology that you
just absorb the information. But actually building one from scratch
reveals some really fascinating mechanics about how computers and humans, well,
they disagree on what makes sense?
Speaker 1 (02:54):
Yes, and the book walks us through a brilliant example
of this. Okay, let's unpack this. Let's do We look
at the English Mere League wins for the soccer team
Manchester City. This is from two thousand and six to
twenty twelve, and the data points show their performance shifting
pretty dramatically. They started thirteen wins in two thousand and six,
they drop to eleven wins in two thousand and seven,
(03:14):
and eventually they climb all the way up to twenty
eight wins by twenty twelve.
Speaker 2 (03:18):
Quite a jump.
Speaker 1 (03:19):
Yeah. Now, to get this data onto a web page
using that flow year two library, you can't just type
the numbers onto the screen. You have to use an
HTML canvas.
Speaker 2 (03:28):
Element right, And for anyone who hasn't built a web page,
think of an HTML canvas exactly like it sounds. It
is a literal, blank, invisible rectangle that the browser sets
aside on your screen, like a literal canvas exactly. It
doesn't process texts like a normal web page. It's a
dedicated sandbox specifically for a JavaScript library. To draw raw pixels.
Speaker 1 (03:50):
And to tell the library what to draw in that sandbox,
you have to feed it nested to raise a data
so you package the year and the wins together as coordinates.
Speaker 2 (03:58):
Sounds straightforward enough.
Speaker 1 (03:59):
It does, But here's the catch. If you just feed
those coordinates in and let the library use its default
mathematical settings, you run into a massive problem. The default
algorithm automatically calculates the vertical axis the y axis based
purely on your lowest and highest data points, so it
zooms in. Yes, because Manchester City's lowest number of wins
(04:20):
was eleven, the bottom of the chart starts.
Speaker 2 (04:23):
At eleven, which is an issue.
Speaker 1 (04:25):
Well, wait a minute, let me push back on this
for a second.
Speaker 2 (04:27):
Okay, go ahead.
Speaker 1 (04:28):
If I am a computer programmer, I might argue that
the computer is doing exactly what it should if the
data only exists between the numbers eleven and twenty eight.
Isn't starting the axis at eleven mathematically the most precise
way to show that specific variance? Technically, yes, right, So
why are we overwriting the computer when its math is
(04:49):
technically correct?
Speaker 2 (04:50):
That is the perfect question because it highlights the fundamental
difference between mathematical precision and human visual processing.
Speaker 1 (04:57):
Okay, how so.
Speaker 2 (04:58):
Well the math is correct visually, it is a total disaster.
When we look at a bar chart, our brains don't
just read the numbers on the side. We process the
proportion of the shapes. Oh, I see, We inherently believe
that if one bar is twice as tall as another,
the underlying value must be twice as large.
Speaker 1 (05:15):
That makes total sense. It's like cropping a photograph so
tightly that you lose all the background context.
Speaker 2 (05:21):
That's a perfect analogy. So if the bottom of your
chart is set to eleven, the bar for the year
two thousand and seven, where they won exactly eleven games,
completely disappears.
Speaker 1 (05:31):
Oh wow, because it's at the absolute bottom exactly.
Speaker 2 (05:33):
It has zero height. It's just a flat line on
the floor of the chart. To anyone quickly glancing at it,
it visually implies that Manchester City won absolutely zero games
that year.
Speaker 1 (05:44):
Right. Think about the last stock chart you looked at
on your phone. Did you actually check where the y
axis started? Probably not, because if it didn't start at zero,
you might have panicked over a visual drop that was
actually minuscule. In reality, it's a huge blind spot.
Speaker 2 (05:57):
Exactly. You end up manipulating the viewers perception of reality,
even if you did it completely by accident.
Speaker 1 (06:03):
Yeah, the visual.
Speaker 2 (06:04):
Distance between eleven wins and twenty eight wins looks like
a catastrophic chasm if eleven is.
Speaker 1 (06:09):
The floor, right, But when you go into the code
and manually force the y axis minimum to zero, the
eleven wind bar suddenly has weight.
Speaker 2 (06:17):
It changes everything the viewer sees.
Speaker 1 (06:19):
The true proportional difference. It was a bad year, sure,
but it wasn't a total failure.
Speaker 2 (06:25):
And while you are in the code fixing the axis,
you also have to fix the computer's assumptions about the
numbers themselves.
Speaker 1 (06:31):
Oh right.
Speaker 2 (06:32):
Because the computer algorithm assumes all data could potentially be fractions,
it helpfully adds decimal points to the labels. On the side.
Speaker 1 (06:38):
You cannot have fifteen point zero soccer.
Speaker 2 (06:41):
Wins exactly, so you pass a quick option in the code.
It's tick decimals zero. It cleans up the labels.
Speaker 1 (06:49):
It really proves that the code might be mathematically sound,
but you constantly have to manually adjust it for human reality.
Speaker 2 (06:55):
It is a constant translation between machine logic and human intuition.
Speaker 1 (06:59):
Okay, so forcing a zero baseline fixes a static bar chart,
but that really only works for discrete, separated moments in time.
What if we're tracking something massive and continuous, like say
climate change over fifty years.
Speaker 2 (07:12):
That gets tricky.
Speaker 1 (07:13):
Yeah, a bar chart with fifty individual pillars would just
look like a crowded fence.
Speaker 2 (07:17):
The trend gets lost. How does the code handle decades
of continuous movement? That is where you have to transition
to line charts. They really excel at revealing the overall
narrative in massive data sets without bogging the viewers bring
down in the individual year by year data.
Speaker 1 (07:33):
Points, and the book uses this incredible data set from NOAA,
the National Oceanic and Atmospheric Administration. It's a great example.
It spans over fifty years tracking the carbon dioxide concentration
in the atmosphere from Manola, Hawaii alongside the global surface
temperature deviations for that exact same time period.
Speaker 2 (07:53):
Which presents a notoriously difficult challenge for a developer. You
are trying to plot two very critical but very different,
currently measured metrics on the exact same piece of digital paper.
Speaker 1 (08:03):
Here's where it gets really interesting. We are talking about
putting two completely different scales on the same.
Speaker 2 (08:09):
Chart, the double access dilemmas exactly.
Speaker 1 (08:11):
You have CO two, which is measured in parts per million.
Those are large absolute numbers in the three hundreds and
four hundreds, right, and then you have temperature deviations which
are measured in tiny fractions of a single degree celsi's
numbers like zero point zero seven or point one.
Speaker 2 (08:24):
Two, So completely different scales.
Speaker 1 (08:27):
If you just overlay them, the grid lines clash, the
values don't align, and the viewer just gives up. But
beyond the formatting, the whole concept of a deviation metric
is confusing. It really is the temperature values aren't absolute temperatures,
they are deviations from the twentieth century historical average. So
how on earth does a developer make that historical average
(08:49):
clear to the end user without just slapping a giant
paragraph of explanatory text onto the screen.
Speaker 2 (08:55):
What's fascinating here is one of my favorite techniques in
the book. The author uses a brilliant yet incredibly simple
coding trick.
Speaker 1 (09:02):
I love this part.
Speaker 2 (09:03):
To represent that twentieth century average baseline, the coder literally
injects a completely fake dummy data set into the JavaScript array.
Speaker 1 (09:13):
Wait fake data.
Speaker 2 (09:14):
Yes, for every single year from nineteen fifteen nine to
twenty twelve, they add a corresponding data point of exactly zero.
Speaker 1 (09:20):
Oh, it's like drawing a firm line in the sand,
so you can accurately measure exactly how far the tide
is coming in.
Speaker 2 (09:26):
That's a great way to think about it. And they
don't just leave it looking like a normal line of data.
What do they do in the code? They style this
specific zero line to be only one pixel wide. They
color it a dark, subtle gray, and they completely disable
its drop shadow, so it blends in exactly. By changing
those visual properties, it stops looking like a data set
to the human eye and starts looking like a piece
(09:48):
of the charts structural framework.
Speaker 1 (09:50):
It creates an instant visual anchor. You don't have to
read an explanation. Your brain immediately understands that anything above
that gray line is warmer than the historical average, and
anything below it is cooler. It's so intuitive, And the
author does one more subtle thing in the code that
I found so clever. When you have multiple lines, you
obviously need a legend so the user knows what they're looking.
Speaker 2 (10:11):
At, right a key.
Speaker 1 (10:13):
By default, the computer will just list the legend items
in whatever random order you fed the arrays into the code.
Speaker 2 (10:18):
Which again is the computer just doing what it's told,
but completely ignoring human logic.
Speaker 1 (10:24):
Right. But if you intentionally swamp the order of the
data series in your code, specifically putting the temperature deviation
data right next to that dummy baseline zero data, they
get grouped together visually in the little legend box.
Speaker 2 (10:38):
Oh that's smart.
Speaker 1 (10:38):
It intuitively links the concept of the temperature with the
baseline for the viewer before their eyes even move over
to analyze the graph itself. To tiny psychological match.
Speaker 2 (10:48):
It proves that building these things isn't just about plotting points.
You are designing a cognitive experience. You are quietly guiding
the user's eye to make the right connections.
Speaker 1 (10:58):
So we've solved tracking things over continuous time. But what
if time isn't the factor at all? Okay, what if
you want to take a snapshot of the world right
now and figure out if two entirely different variables actually
cause each other, or at least correlate.
Speaker 2 (11:12):
That is the perfect scenario for a scatter chart. You
aren't looking at trends over time. You are looking for
relationships between disparate things.
Speaker 1 (11:19):
The Deep Dive moves into this fascinating twenty ten OECD
data set. It compares healthcare spending as a percentage of
a country's GDP against the average life expectancy of its citizens.
Speaker 2 (11:31):
A classic comparison.
Speaker 1 (11:33):
Yeah, the fundamental question is does spending a higher percentage
of your national wealth on healthcare actually equal a longer
life for your people?
Speaker 2 (11:42):
It is a very complex question. You are plotting dozens
of individual countries as floating dots based on those two
independent variables.
Speaker 1 (11:50):
But once again, if you just hand this raw data
to the flat er two library, the default output is
pretty claustrophobic, very crammed. The library tries to maximize the space,
so the points get crammed right against the very edges
of the chart box. The dot for the country with
the lowest spending physically touches the left wall, and the
highest bending touches the right wall.
Speaker 2 (12:09):
That's hard to read.
Speaker 1 (12:11):
It just like framing a beautiful painting but letting the
picture frame cover up the outer two inches of the canvas.
Your eyes need margins to comfortably process the words, and
data points need margins to be compared accurately.
Speaker 2 (12:22):
And while visualization libraries almost always have an autoscale feature
that tries to fix this mathematically, they often fall short
of what the human eye actually needs.
Speaker 1 (12:31):
So it's the fix.
Speaker 2 (12:32):
A skilled visualizer will look at that cramped box and
manually override the defaults. You explicitly tell the code set
the x axis minimum to five and the maximum to twenty.
You intentionally pad the axes to give the data breathing room.
Speaker 1 (12:47):
It separates the cluster of information from the boundaries of
the chart, but the breathing room isn't the only thing
the user needs. The x axis represents a percentage, bending
as a percentage GDP. But the raw data in the array,
it's just the integers five, ten, fifteen, extrail numbers. Yeah.
If you leave it like that, the user has to
look at the number fifteen, scan their eyes over to
(13:09):
the access title, read percentage of GDP, and then remind
themselves right that number fifteen means fifteen percent.
Speaker 2 (13:15):
Which sounds incredibly minor, but in the world of data consumption,
that is cognitive friction. It slows down comprehension, and as.
Speaker 1 (13:21):
A developer, you have the power to just remove that friction.
Flutoo allows you to write a custom formatting function for
the axis labels. That's really handy.
Speaker 2 (13:29):
So instead of just accepting the default integers, you write
a tiny piece of logic that intercepts the label right
before the browser draws it on the canvas, and simply
a pens a percentage signed to it. Oh nice. The
user just sees fifteen percent and instantly understands the value,
and you really want them to understand it quickly, because
the payoff of this specific data set is amazing. When
(13:51):
you step back and look at the scatterplot, you don't
see a perfect diagonal line going up.
Speaker 1 (13:56):
No, you don't, and that is exactly why you need
a scatterplot instead of a bar chart. If you just
average the data out into bars, you would miss the reality.
You miss the whole point exactly. The scatter reveals a
messy cluster. It visually proves that simply spending more money
on healthcare does not guarantee a linear, straight line increase
in life expectancy.
Speaker 2 (14:17):
Right, they are country spending less that are achieving longer
life stands.
Speaker 1 (14:20):
The spread is the story.
Speaker 2 (14:21):
It's brilliant. But speaking of cognitive friction, well, we have
to talk about the most controversial chart in the entire
corporate world, and frankly.
Speaker 1 (14:30):
The messy reality of the code that builds them. I
am talking, of course, about the notorious pie chart.
Speaker 2 (14:35):
The chart that data scientists absolutely love to hate.
Speaker 1 (14:39):
Okay, I have to play devil's advocate here. Wait, everyone
loves a colorful pie chart. They're in literally every boardroom
presentation and every quarterly report ever made. Why do developers
usually hate them?
Speaker 2 (14:50):
Well, if we connect this to the bigger picture, it
comes down to a fundamental biological flaw in how the
human brain processes geometry. Really biology, Yeah, we are actually
terrible at judging the relative size of areas. We are
very good at comparing lengths, like the height of vertical
bars in a bar chart.
Speaker 1 (15:09):
Sure, and that's easy.
Speaker 2 (15:10):
If one bar is just a few pixels taller than another,
your eye catches it instantly. But when you take a circle,
slice it into five or six irregularly sized wedges, and
then ask the human eye to rank them.
Speaker 1 (15:21):
By size to a guessing game.
Speaker 2 (15:23):
We fail miserably. Unless the difference is drastic. We just
cannot accurately compare those non rectangular areas. If you're comparing
multiple values against each other, a bar chart is almost
always better.
Speaker 1 (15:35):
Okay, fair enough, But the book actually defends them in
one very specific scenario.
Speaker 2 (15:40):
Yes it does. They are highly effective for one task
emphasizing a single fraction against a hole.
Speaker 1 (15:47):
Ooh.
Speaker 2 (15:47):
If you only have two slices and you want to
show the sheer proportion of one piece relative to everything else,
it is incredibly powerful.
Speaker 1 (15:55):
The example in the book is striking. It uses World
Bank data from two thousand and eight to visualize extreme
global poverty.
Speaker 2 (16:02):
It's a sobering visual, it really is.
Speaker 1 (16:04):
It highlights that twenty two point four percent of the
world's population was living on less than a dollar and
twenty five cents a day. Wow. When you put that
single red wedge of twenty two point four percent against
a solid, massive circle representing the rest of humanity, you
don't need to compare multiple variables. The impact is visceral
and instant.
Speaker 2 (16:22):
In that context, the pie chart strips away everything extraneous
and forces you to confront that single massive proportion.
Speaker 1 (16:28):
But actually getting that pie chart to render brings us
to my absolute favorite part of this deep dive. It
is the reality versus ideal world philosophy of the book,
which is so relatable because we tend to think of
computer programming as this pristine, perfect science where everything is logical.
But the reality is that even great widely used open
source cools have hilarious, messy corps.
Speaker 2 (16:51):
Software is written by humans, and humans use tape and
glue to hold things together.
Speaker 1 (16:56):
Exactly so the author details this known deliberate and the
Flatschow Library. When the library is trying to calculate how
big to draw the charts, the size the text, the
width of labels, everything, it has to physically create dummy
HTML elements in the background of your web browser to
measure them.
Speaker 2 (17:14):
It has to generate them to size them up right.
Speaker 1 (17:16):
But obviously it doesn't want the user to see these
weird dummy text elements popping up on the web page
while it does the mask.
Speaker 2 (17:23):
They need to exist on the page to be measured,
but they need to be invisible to the user.
Speaker 1 (17:27):
So what does this all mean? How do the developers
hide them? Well, every web page is structured using something
called the DOM, the document object model, the blueprint. It's
basically the blueprint of the page, and you style that
blueprint using CSS. The developers of this library wrote a
CSS rule using absolute positioning. They told these dummy text
(17:48):
elements to be placed exactly ten thousand pixels above the
top of the.
Speaker 2 (17:52):
User's screen using a negative value.
Speaker 1 (17:54):
Yes, they use a top margin of negative ten thousand
picks on.
Speaker 2 (17:57):
The logic being just throw it so far off the
screen that no one will ever see it out of sight,
out of mind exactly.
Speaker 1 (18:04):
But here is the catch. CSS absolute positioning is tricking.
It is like telling someone go stand one hundred feet north,
but north of what the center of the earth, the
room you were currently standing in.
Speaker 2 (18:16):
It's relative.
Speaker 1 (18:17):
That is what happens to the browser. Sometimes, depending on
how your specific web page is built, that negative ten
thousand pixels is calculated relative to a container inside your page,
not the absolute top of the browser.
Speaker 2 (18:29):
Window, which becomes a massive problem if the user's document
is extremely long.
Speaker 1 (18:34):
Yes, if you are building a massive, long, scrolling dashboard
full of charts, that negative ten thousand pisel trick completely backfires.
The browser's positioning gets confused.
Speaker 2 (18:43):
Oh, I can picture it now.
Speaker 1 (18:44):
Suddenly the user is scrolling down your beautiful dashboard and
they start seeing random pieces of invisible chart text scattering
like confetti across your website.
Speaker 2 (18:54):
It is the perfect encapsulation of how coding in the
real world actually works. You can have the most elegant
data structures, but you are still at the mercy of
a web browser misinterpreting a CSS hack from a third
party library.
Speaker 1 (19:09):
And I absolutely love the book's practical takeaway for this.
The author basically says, Look, you could theoretically go into
the open source library, dig through thousands of lines of
source code and rewrite their positioning logic to be perfect.
Or you can just be a pragmatic developer.
Speaker 2 (19:23):
Sometimes you just need a quick fix.
Speaker 1 (19:25):
He suggests just writing a single line of jQuery to
find and hide the library's messy invisible.
Speaker 2 (19:31):
Elements for those unfamiliar. jQuery is just a shortcut language
for web developers. It allows you to quickly find elements
on a web page after it has loaded and manipulate them.
Speaker 1 (19:40):
Right so, the author says, just write a quick jQuery
script that targets the specific class name of those messy
invisible elements, the dot, float, dummy div class and just
brutally forces them to hide once the chart is done drawing.
Speaker 2 (19:55):
It's a band aid, but sometimes the best solution is
the pragmatic one. It saves you hours of de and
it gets the visualization working for the user, which is
the ultimate goal.
Speaker 1 (20:03):
It is such a wonderfully messy reality check. Yeah, which
actually brings us to the most important question for you,
the listener. We've spent this time talking about arrays, HTML canvases,
y axis minimums, and CSS bugs. Why does knowing the
JavaScript logic behind these charts actually matter to you?
Speaker 2 (20:20):
It matters deeply because visual communication is a language, and
right now in the modern world, data is being spoken
at you constantly all day long.
Speaker 1 (20:29):
Exactly think about it. Whether you are actively trying to
program a dashboard at your job, prepping a slide deck
for a board meeting, or simply just sitting on your
couch trying to consume your daily news on your phone
without being misled.
Speaker 2 (20:41):
It's everywhere.
Speaker 1 (20:42):
Understanding how axes are manipulated, why data points, meat, breathing room,
and when a pie chart is actually useful makes you
a vastly sharper, more critical consumer of information.
Speaker 2 (20:53):
You stop just looking at the geometric shapes and you
start seeing the underlying structure.
Speaker 1 (20:58):
You start to recognize the choices the creator made, and.
Speaker 2 (21:00):
Even more importantly, you start to recognize the choices they
decided not to make.
Speaker 1 (21:04):
Absolutely. Yeah, so we want to leave you with this thought.
Tom all over today. Now that you know exactly how
easily a chart's entire narrative can be radically altered just
by tweaking the minimum value of a y axis in
the code, or switching from comparative bars to an unreadable
pie slice.
Speaker 2 (21:21):
Yeah, think about that.
Speaker 1 (21:23):
How much the data you scrolled past today was intentionally
designed to manipulate your perception rather than actually inform you
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Hey Jonas!
Hey Jonas! The official Jonas Brothers podcast. Hosted by Kevin, Joe, and Nick Jonas. It’s the Jonas Brothers you know... musicians, actors, and well, yes, brothers. Now, they’re sharing another side of themselves in the playful, intimate, and irreverent way only they can. Spend time with the Jonas Brothers here and stay a little bit longer for deep conversations like never before.
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.