9.10: Detailed Figure Captions - Chapter 9
- Page ID
- 60919
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\dsum}{\displaystyle\sum\limits} \)
\( \newcommand{\dint}{\displaystyle\int\limits} \)
\( \newcommand{\dlim}{\displaystyle\lim\limits} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\(\newcommand{\longvect}{\overrightarrow}\)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\ket}[1]{\left| #1 \right>}\)
\(\newcommand{\bra}[1]{\left< #1 \right|}\)
\(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
\(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
\(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
\(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
\(\newcommand{\expect}[1]{\langle #1 \rangle}\)
\(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)
Advanced Visualization Techniques, Dashboarding, and Storytelling — Figure Specifications
Overview
-
Chapter: 9 — Advanced Visualization Techniques, Dashboarding, and Storytelling
-
Total Figures Proposed: 8
-
Figure Types Used: Conceptual Illustration, Comparison Table, Flowchart, Data Chart, Architecture Diagram, Infographic
Figure 9.1.1
Title: Shneiderman's Visual Information-Seeking Mantra
Detailed Caption: Three stage boxes connected by large right-pointing arrows walk the viewer through Shneiderman's foundational interaction design mantra left to right: a light-navy "Overview First" box contains a dense thumbnail scatterplot representing the full dataset; a light-teal "Zoom & Filter" box shows that same scatterplot magnified and partially grayed out as a subset is isolated; and a light-gold "Details-on-Demand" box shows a single highlighted point with a tooltip reading "Value: 142 / Category: A." The three-stage sequence converts an abstract design principle into a concrete interaction recipe that applies equally to a simple scatter plot and a million-row dashboard: before any filtering or drill-down is possible, the analyst needs a navigable overview that establishes context and scale; once that overview reveals a region or cluster worth investigating, zoom and filter operations reduce visual noise and bring the target subset into focus; and only when the analyst has narrowed to a specific item does requesting a tooltip or detail panel make sense, because at that scale the cognitive load of reading detailed labels is proportional to the insight gained. By illustrating all three stages on a single canvas with matched visual thumbnails, the figure gives students a reusable mental model they can apply whenever they design or critique an interactive visualization: if an interaction workflow skips straight to details without an overview, or if it presents a wall of detail that requires filtering before any orientation is possible, the mantra names exactly which stage is missing and why that omission hurts usability.
Figure 9.2.1
Title: Advanced Chart Type Selection Guide
Detailed Caption: A five-row comparison table organizes five advanced chart types — treemap, bullet chart, network graph, Sankey diagram, and radar chart — across four columns: Chart Type (with a small iconic thumbnail of each), Best For, Key Strength, and Key Limitation, with column headers on a navy background in white text and alternating teal-tinted and white row fills that aid horizontal scanning. The table converts what would otherwise be five separate prose discussions into a single reference grid that answers the analyst's most practical pre-design question: given the data scenario in front of me right now, which chart type is the most defensible choice? Each row captures the essential tradeoff in one sentence per cell — treemaps compress hierarchical part-to-whole data compactly but become illegible when many categories are similarly sized; bullet charts pack a KPI, its target, and three performance bands into a single horizontal bar but puzzle audiences unfamiliar with the format; network graphs expose clusters and hub nodes but collapse into unreadable hairballs under dense connectivity; Sankey diagrams make flow volumes and stage drop-offs immediately intuitive but grow unwieldy as the node count rises; and radar charts offer a holistic multi-variable profile at a glance but produce misleading angular distortions when too many spokes are present. By presenting all five entries simultaneously rather than sequentially, the table also invites cross-row comparison — for instance, a student can immediately see that both Sankey and network graphs share a scalability limitation, while bullet and radar charts share an audience-familiarity limitation — a higher-order pattern that sequential prose naturally obscures.
Figure 9.2.2
Title: Anatomy of a Bullet Chart
Detailed Caption: A single horizontal bullet chart for "Q3 Revenue ($M)" dominates the figure, with its three core components isolated by color-coded annotation callout lines: three background range bands in graduated grays labeled "Poor (< $2M)," "Satisfactory ($2M–$3.5M)," and "Excellent (> $3.5M)" establish the qualitative performance context; a bold teal primary-measure bar extending to the $3.1M mark carries the actual observed value; and a thin vertical navy line at $3.5M marks the comparative target, with a horizontal quantitative scale from $0 to $4.5M running along the bottom. By dissecting every component on a single labeled artifact, the figure transforms what is to most audiences an unfamiliar glyph — a bar inside a bar inside a shaded rectangle — into a readable anatomy reference that students can return to whenever they need to reconstruct the logic of a bullet chart from first principles. The deliberate choice to annotate all three layers simultaneously rather than building up the chart in stages makes the figure's central argument visible in one pass: a bullet chart is not a stripped-down bar chart but a purposefully layered encoding that answers three questions at once — how much was achieved, how does it compare to the target, and in which qualitative performance band does the result fall — and each visual layer carries exactly one of those answers, with no redundancy and no wasted ink.
Figure 9.2.3
Title: Sankey Diagram Depicting a Hiring Funnel (Simplified Example)
Detailed Caption: The diagram is a Sankey chart — a type of flow diagram where the width of each connecting band is proportional to the quantity flowing between stages. It illustrates a hiring process funnel with progressively narrowing bands, visually highlighting where candidate drop-offs occur.
The funnel flows from bottom to top through the following stages:
Applications: 52 (bottom, widest band) — The process begins with 52 applicants. This is the broadest point of the funnel.
Rejected: 45 (branching off to the bottom-right, red/brown band) — The largest drop-off occurs here: 45 out of 52 applicants are rejected before the interview stage. This massive narrowing is immediately visually apparent from the thick outward-flowing band.
Formal Interview: 7 (middle node, much narrower band) — Only 7 candidates advance to the formal interview stage.
No Offer: 6 (branching off to the right, gray band) — Of the 7 interviewed, 6 receive no offer.
Offer: 1 (top, thinnest band) — Only 1 candidate ultimately receives an offer — represented by the narrowest band at the top of the funnel.
The Sankey diagram is an effective storytelling tool for process data — it tells a story of movement. In this example, the visual immediately highlights that the largest attrition (45 of 52, or ~87%) happens at the application screening stage, while the interview-to-offer conversion is also steep (only 1 of 7). This makes complex funnels easy to grasp at a glance.
Figure 9.2.3.2
Title: Sankey Diagram — E-Commerce Conversion Funnel
Detailed Caption: Five vertical node bars — "Website Visitors (10,000)" through "Purchase (900)" — are connected left to right by flowing bands whose widths are strictly proportional to the user counts they carry, and at each transition a thinner gray branch splits downward to a "Drop-off" node that labels the count of users who exited the funnel at that stage, with the largest single drop-off annotated as "Largest drop-off: 35% bounce" at the first transition. The proportional-width encoding is the chart's defining feature and its primary pedagogical contribution: unlike a standard bar chart that would require side-by-side comparisons to reveal drop-off magnitude, or a table that would require mental subtraction, the Sankey immediately makes both absolute volume and relative loss perceptually available — the thinning of the main band and the widening of the drop-off band produce a gestalt impression of funnel efficiency that no tabular format can replicate. The e-commerce scenario is chosen deliberately because conversion funnels are among the most universally understood business processes, letting students focus on learning to read the visual encoding rather than decoding an unfamiliar domain: once the logic of proportional bands and branching drop-offs is internalized on a familiar funnel, students can transfer the same reading skill to less familiar Sankey applications such as energy flows, budget allocations, or migration patterns.
Figure 9.3.1
Title: Dashboard Layout with Visual Hierarchy
Detailed Caption: A wireframe dashboard layout shows three KPI summary boxes side by side at the top — "Total Sales: $1.2M," "Conversion Rate: 4.8%," "Active Users: 12.4K" — with navy headers and warm-gold accent numbers; below them, a teal-outlined central zone labeled "Overview Visualization (e.g., trend line or map)" occupies roughly 40% of the layout; four smaller chart placeholder boxes in a 2×2 grid fill the lower half; a "Filters" panel with placeholder dropdowns runs along the left sidebar; and a large dashed arrow traces a Z-pattern across the full layout labeled "Z-Pattern Reading Flow," with annotations marking "Primary focus area" at the KPIs and "Supporting details" at the lower charts. The Z-pattern annotation is the figure's core instructional contribution: it makes explicit the implicit reading convention that most dashboard designers rely on but rarely articulate — viewers scan horizontally across the top (catching the KPIs), drop diagonally to the lower-left (arriving at the overview chart), then scan horizontally across the bottom (processing the supporting details) — and by drawing this path directly on a layout template, the figure gives students a spatial argument for why KPIs belong at the top left and why the largest, most important visualization belongs in the center-left zone rather than the lower-right. The wireframe format rather than a polished design is deliberate: abstracting away data and color keeps the focus on spatial hierarchy principles that apply to any dashboard regardless of domain, tool, or visual style.
Figure 9.3.2
Title: Responsive Dashboard Adaptation Across Devices
Detailed Caption: Three device silhouettes — desktop monitor, tablet, and smartphone — are shown side by side, each rendering the same dashboard content adapted to its screen width: the desktop displays the full layout with a top KPI row of three side-by-side metric boxes, a large central chart, two smaller charts placed side by side below it, and a filter sidebar on the left; the tablet collapses the sidebar into a hamburger menu icon and stacks the two smaller charts vertically; the smartphone retains only the KPI row stacked as three vertical rows and the main chart, with a "More charts" button at the bottom and no sidebar, carrying the annotation "Non-essential elements hidden." Dashed connector lines link corresponding elements across the three devices, making it visually explicit that responsive design is a systematic re-layout of the same content hierarchy rather than a distinct design for each screen size. The figure's instructional argument is embedded in what is absent rather than what is present: on the phone, the two detail charts and the filter sidebar have disappeared entirely rather than shrinking to thumbnail size, illustrating the key responsive-design principle that elements must be prioritized and progressively disclosed rather than uniformly scaled — uniform scaling produces layouts that are technically complete but practically unusable, while progressive disclosure produces layouts that surface the highest-value content on every device and require intentional interaction to reach lower-priority elements.
Figure 9.5.1
Title: The Data Storytelling Narrative Arc
Detailed Caption: Three large rounded-rectangle stages connected by curved arrows flow left to right along a subtle rising-then-resolving arc: a navy "Act 1: Context" box lists "Set the stage / Introduce the business problem / Provide background data"; a teal "Act 2: Conflict / Insight" box lists "Present the key finding / Highlight the surprising pattern / Show evidence with visuals" and carries a bar-chart icon to represent data evidence; and a warm-gold "Act 3: Resolution" box lists "State recommendation / Quantify expected impact / Call to action." Below the three stages, a full-width horizontal bar divided into matching color sections shows a "Narrative Tension" curve that rises to a peak at Act 2 and settles at Act 3. The three-act framework is not merely a presentation template but a diagnostic tool: when a data presentation fails to persuade, the figure's three categories let the analyst identify which act is broken — a missing Act 1 leaves audiences without the context to understand why the finding matters; a weak Act 2 presents data without isolating the single surprising or actionable insight that justifies the presentation; and a vague Act 3 produces an intellectually satisfying analysis that nonetheless fails to change any decision or behavior. By grounding a classical narrative structure in the specific content requirements of data communication — background data, statistical evidence, quantified impact — the figure helps students understand that storytelling in data analysis is not a stylistic embellishment but a structural discipline with testable criteria for completeness.
Figure 9.5.2
Title: Tailoring Data Presentations — Executive vs. Technical Audiences
Detailed Caption: Two columns separated by a thin vertical dashed line contrast the communication approach for executive audiences (left, navy header with briefcase icon) and technical audiences (right, teal header with gear icon) across five comparison rows labeled in warm gold: Opening, Detail Level, Visuals, Language, and Goal, with each cell in a rounded rectangle lightly tinted by its column color, and a shared full-width gray row at the bottom reading "Common Ground: Clear narrative, logical flow, key insights emphasized." The parallel structure of the table makes its central argument visible at a glance: the same underlying analysis should be entered, packaged, and exited differently depending on who is in the room — executives receive conclusions first and work backward to implications, while technical audiences receive hypotheses and methodology first and work forward to conclusions; executives see big-number KPIs and clean trend lines while technical audiences see residual plots and model diagnostics; and executives evaluate presentations against strategic and financial impact while technical audiences evaluate against methodological rigor and reproducibility. The shared "Common Ground" row at the bottom is a deliberate structural choice that prevents students from over-reading the contrast: the table is not arguing that executive presentations sacrifice rigor or that technical presentations sacrifice clarity, but that the sequencing, vocabulary, and level of detail should shift while the underlying commitment to a clear narrative and honest evidence remains constant across both audiences.


