Bostock / D3 lineage — full legal readings

Sources obtained only from author/lab OA PDFs and live (or Wayback-archived) pages. No Sci-Hub / LibGen. Extracted text copies live under _extracted_text/.

PDFs saved to this folder and mirrored to project Literature/.

---

1. Bostock, Ogievetsky, & Heer (2011). D³: Data-Driven Documents

Design principles / claims stated in the paper

• - Representation transparency / native scenegraph. Do not hide the underlying scenegraph in a toolkit-specific abstraction; operate on the browser DOM. “The document is the scenegraph.”
• - Three refined goals (from Protovis experience): expressiveness, efficiency, accessibility — sharpened into:

- Compatibility with the web ecosystem (reuse standards, CSS, developer tools).

- Debugging via poking/prodding and immediate side-effects (avoid “impedance mismatch” when internal state violates the user’s mental model).

- Performance via focusing on transformation rather than regenerating an intermediate representation.

• - Kernel, not a full graphical grammar. D3’s core problem is “efficient manipulation of documents based on data”; closest analogues are document transformers (jQuery, CSS, XSLT), not Infovis frameworks.
• - Selection → operators → data join. Atomic operand is a selection. Data joins bind data to elements and produce enter / update / exit subselections (relational left/inner/right analogues). Key functions preserve object constancy across transitions. Data is “sticky” on nodes.
• - Immediate evaluation. Operators (e.g. attr) apply immediately, unlike Protovis’s deferred property evaluation — reduces hidden control flow, eases debugging, allows recursive/each-driven hierarchies.
• - Explicit transforms for dynamics. Designers specify scene changes (what to mutate/add/remove), not only scene descriptions — enables animation/interaction with less redundant work.
• - Modules without encapsulating the form. Optional helpers (scales, layouts, d3.svg shapes, behaviors) raise efficiency while still exposing native SVG/HTML. Quotes Tufte: “Don’t get it original, get it right.”
• - Trade-offs acknowledged. Abandoning specialized marks loses Protovis-style prototypal inheritance / homogeneous properties; CSS and native tools compensate; slight loss of notational efficiency possible.
• - Empirical claim. Benchmarks: D3 ≥ ~2× Protovis on load/frame rate in their tests; Flash still faster on FPS at large n; browser SVG still has room to improve.

Not found in this text: the slogan “document as document,” or any rule that “interaction should not hide the number if print matters.”

---

2. Heer & Shneiderman (2012). Interactive Dynamics for Visual Analysis

Design principles / taxonomy stated in the paper

Tools must support fluent and flexible use of visualizations “at rates resonant with the pace of human thought.” Taxonomy of 12 task types in three categories:

Data and view specification

1. 1. Visualize — choose encodings / chart type / grammar / shelves (Tableau).
2. 2. Filter — dynamic query widgets; rapid and reversible subsetting with real-time updates.
3. 3. Sort — expose patterns; seriation for matrices/networks.
4. 4. Derive — normalize, aggregate, model-fit, calculation languages.

View manipulation

1. 5. Select — hover/click/lasso; selections as queries over data when possible.
2. 6. Navigate — cites Shneiderman mantra: “Overview first, zoom and filter, then details-on-demand”; also “Search, show context, expand on demand”; geometric vs semantic zoom; overview+detail; focus+context / DOI; caution that complex fisheye distortion often fails to beat simple zoom.
3. 7. Coordinate — brushing & linking; linked navigation; small multiples (citing Tufte).
4. 8. Organize — tiled layouts, tabs, trellis, automatic layout of multi-view workspaces.

Process and provenance

1. 9. Record — undo/redo and visual histories (timeline / comic-strip).
2. 10. Annotate — prefer data-aware annotations (selections/queries) over freeform graphics that break under filter/aggregate.
3. 11. Share — application bookmarking / URLs; publish interactive views; social discussion.
4. 12. Guide — guided analytics workflows; narrative visualization that leads then opens for exploration (news graphics).

Also: confusing widgets / slow response curtail thorough deliberation and introduce errors.

---

3. Heer, Card, & Landay (2005). prefuse: a toolkit for interactive information visualization

Design principles stated

• - Infovis apps are hard to author and need domain-specific customization → toolkit of finer-grained building blocks, not only ready-made chart widgets.
• - Based on the information visualization reference model / data state model (Card/Mackinlay/Shneiderman; Chi): abstract data → filter to visualizable form → process visual analogues → interactive display.
• - Filtering maps abstract data to VisualItems (location, color, size, …); supports scalability (working set / DOI / garbage collection) and multiple views of shared data.
• - Actions (filter, assignment, animator) composed into ActionLists / scheduled Activities — batch processing pipelines for layout, color, animation.
• - Renderer / RendererFactory / Display separate appearance from data; supports semantic zoom and overview+detail.
• - Library of layouts, distortion, force simulation, interactive controls, color maps, integrated search, event logging for studies.
• - Evaluation: coverage of classic techniques; DOITrees and Vizster; API usability study (filtering is the learning threshold; sample code is the real “UI” of a toolkit).

---

4. Bostock & Heer (2009). Protovis: A Graphical Toolkit for Visualization

Design principles stated

• - Gap between high-level chart systems (efficient but restrictive) and low-level graphics (expressive but tedious).
• - Balance expressiveness / efficiency / accessibility; tools bias designers toward what is easy (Maslow “hammer/nail”).
• - Prefer marks designers can think about concretely (bars, lines, labels) over foreign operator stacks — reduce gulf of execution.
• - Visualization = hierarchy of marks with properties as functions of data; inheritance/cascading for related marks; panels for small multiples; anchors for labels.
• - Marks know nothing about “charts”; charts emerge from composition.
• - Dot size “proportional to the area of the rendered glyph to encourage meaningful visual encodings.”
• - Data munging should be easy so users make the right visualization rather than compromise design to fit data format.
• - Critiques closed chart typologies (Wilkinson, Tufte cited on shortcomings / defaults).

---

5. Heer & Bostock (2010). Declarative Language Design for Interactive Visualization

Design principles stated

• - Declarative DSLs: specify what, separate from how — simplify development, allow optimization, retarget platforms.
• - Goals: declarative language design; cross-platform rendering/event abstraction (desktop → mobile); format-agnostic processing (no forced toolkit data model; bind via functions over arbitrary iterables); optimizations (compilation, parallelism, GPU).
• - Extends Protovis with declarative animated transitions; key values for object constancy.
• - Claim: order-of-magnitude scalability gains vs prefuse in their Java benchmarks.

---

6. Bostock essays on bost.ocks.org (legal full texts)

6a. Thinking with Joins (2012-02-05)

Stated principles

• - Tell D3 what you want (elements ↔ data), not how to loop-create nodes.
• - Data join yields enter / update / exit; declare the relationship, handle three states without branching/for.
• - Same pattern scales from static charts to realtime / transitions.
• - Target constant attrs on enter; minimize DOM work; animate enter/exit separately.
• - Key functions control data↔element assignment.

6b. Towards Reusable Charts (2012-02-27)

Stated principles

• - Reusable unit = configurable closure with getter-setter methods (same pattern as D3 scales/axes).
• - Charts take a selection (via selection.call) — rubber-stamp rendering; multi-element, moveable, transition-controllable.
• - Configuration ≠ data/DOM; those come from the selection.
• - Open questions left to authors: Grammar of Graphics modularity; whether to expose scales/axes; auto interaction/animation; how much users may “reach into” the chart.

6c. How To Scroll (2014-11-03)

Five rules stated

1. 1. Prefer scrolling to clicking — linear, low deliberation; don’t hide content behind clicks if scrolling can reveal it; avoid full-screen designs with no scroll affordance.
2. 2. Allow rapid, incremental, reversible scrolling — oppose scrolljacked swipe-paging; prefer adapting content (position-fixed “screens”) while preserving native scroll.
3. 3. Provide instantaneous, consistent feedback — keep some content scrolling normally (proportionally) at all times; don’t fix everything.
4. 4. Avoid unwanted disruptions — don’t autoplay video/audio as soon as it enters the large viewport; isolate fullscreen video if autoplay.
5. 5. Support standard keyboard controls — don’t break history navigation (cmd-left/right, delete), etc.

6d. Let’s Make a Bar Chart, I–III (2013)

Live bost.ocks.org/mike/bar/ now redirects to Observable shells with little readable body. Full tutorial text recovered via Wayback (id_ snapshots) and saved under _extracted_text/bostock_bar_part{1,2,3}.txt.

Principles stated in I–III

• - Selections + method chaining; indent convention (4 spaces preserve selection, 2 spaces change selection).
• - Data join as the single pattern for create/update/destroy; initial selection declares elements you want to exist (points to Thinking with Joins / object constancy).
• - Prefer scales over magic multipliers (domain → range).
• - HTML padding can distort bar accuracy — fix with box-sizing or move to SVG.
• - SVG: geometry as attributes, aesthetics preferably as styles (play nice with CSS).
• - Prefer styles for aesthetics; set chart size early so page doesn’t reflow after async data.
• - Async data: initialize before download finishes; coerce types (+d.value) — strings sort/add wrongly.
• - SVG y-axis inverted (range([height,0])); ordinal rangeRoundBands + padding for crisp bars.
• - Margin convention ({top,right,bottom,left}); axes via selection.call.
• - Communicating: “It doesn’t matter how good a chart looks if it doesn’t communicate anything!” Labels, captions, legends, titles, unit-appropriate formats are essential — don’t assume the reader shares your internalized context.

Not found: “interaction should not hide the number if print matters.”

---

7. Observable / d3js.org documentation Bostock still maintains

What is D3? (d3js.org)

Stated principles

• - D3 is a low-level toolbox, not a chart library with a “chart” concept — compose primitives (scales, shapes, layouts, selections).
• - Flexible / no default presentation — you write (or copy) the code.
• - Works with the web — no new graphical representation; name = data-driven documents (DOM). Immediate selection.attr mutates DOM → easier debugging.
• - For bespoke visualization — Cox paraphrase: use D3 if writing ~100 lines for a bar chart seems normal; otherwise prefer Observable Plot.
• - For dynamic visualization — data join (enter/update/exit) exists so you control exact updates and transitions; less needed for purely static charts.

D3 Workshop slides (VIZBI 2012)

Stated tenets (Preface)

• - “D3 provides transformation; no new representation.” Uses HTML/SVG standards → expressiveness, future-proofing, CSS/debugger compatibility.
• - Visualization = visual encoding: mapping data to elements; D3 maintains that mapping as data changes.
• - Learning D3 is largely learning web standards; prefer CSS classes for aesthetics over hard-coded JS colors.

---

8. Related OA pointer (not required, noted)

Heer, Bostock, & Ogievetsky, “A Tour through the Visualization Zoo,” ACM Queue — linked from the Interactive Dynamics article: https://queue.acm.org/detail.cfm?id=1805128. Not treated as a primary read for this note.

---

Coverage checklist

Phrases checked and not found as stated slogans in these texts

• - “document as document” — not used; closest: “the document is the scenegraph” (D3 2011) and “data-driven documents” / DOM (What is D3?).
• - “interaction should not hide the number if print matters” — not found in any document above.