# just can't quit very intermittently trying random over-ambitious stuff in d3 **URL:** \ **Category:** Help\ **Created:** [October 9, 2022, 2:28am UTC](https://talk.observablehq.com/t/just-cant-quit-very-intermittently-trying-random-over-ambitious-stuff-in-d3/7119 "2022-10-09T02:28:43Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![njcode](https://avatars.discourse-cdn.com/v4/letter/n/cdc98d/32.png) [@njcode](https://talk.observablehq.com/u/njcode)\ **Post date:** [October 9, 2022, 2:28am UTC](https://talk.observablehq.com/t/just-cant-quit-very-intermittently-trying-random-over-ambitious-stuff-in-d3/7119/1 "2022-10-09T02:28:43Z")
No question here, just some context for the notebook below. Happy to hear from others of all skill levels, backgrounds and preoccupations about whatever. I have played with d3 in fits and starts over the years and typically have a lot of fun with some quick concept or widget but always seem to get discouraged about using it more fluently, as Plan A. I have a lot of ideas that I can’t really implement, but I like these ideas and I want to talk about them with people interested in these types of things. I know that charting frameworks are not really built for this kind of experimentation. And often enough on Observable I find a better version of my half-formed idea already well-contextualized in some deep and comprehensive discussion, like: > **[Voronoi Stippling Experiments](https://observablehq.com/@jobleonard/untitled)** > > Stippled image of "The Tetons and the Snake River" by Ansel Adams, 1942 DRAFT VERSION A fork of Mike Bostock's notebook on Voronoi Stippling. It contains a few optimisations that should really improve performance. On top of that, we'll be... This time around, maybe I will make a few slightly-more-complex things than in past attempts, maybe I will actually get semi-decent at d3, maybe I will discover I am more interested in some other aspect of data visualization and stop banging my head against technical walls. Maybe stable diffusion for data visualization will make us all prompt engineers. Who knows. But for now I am going to try to make more notebooks like this one that just try to quickly get the ideas and references down, and maybe fill in some of the code here and there via conversation and community support. Maybe I will try sketching in some pseudocode or .py here and there, or dropping in actual sketches, as a way of moving projects along at least spiritually or meeting potential helpers halfway. I do not have a ton of time to devote to learning, and I continue to lose a tremendous chunk of that time to the soggy soil of things like not knowing the names of attributes or not knowing what parameters are required. Currently finding this resource very helpful: > **[Learn Just Enough JavaScript: Python Users](https://observablehq.com/@observablehq/learn-just-enough-javascript-python-users)** > > 🎉 If you're a Python user coming to Observable this notebook is for you! > We leverage the interactive powers of JavaScript to take your analysis from static charts to interactive, animated, and insightful visualizations. This notebook will help you... Also thinking about how to use nbdev to pull together more the skills I _do_ have into unified documents with very slender bit of d3 I can currently muster, but there are a lot of intermediary pieces I need there too (mainly quarto conventions and dunder-world stuff I am less familiar with). A lot of what I am interested in from nbdev is the ability to create integrated documentation and rich docstrings efficiently. I notice a fair bit of Observable code is uncommented, and wonder if docstrings are just part of a different ethos I should be trying not to rely on off in JS world. Interested in people’s thoughts on this. An unsolicited summary of my approach to programming: I am a slow reader and a poor typist. I struggle with JS but love the keyword ‘new.’ I am extremely interested in making code that is easy to _consume_ without a lot of context-switching, without hitting the docs too hard, without too much new vocab up front, and I mean easy not least for my future forgetful self. When I think about a literate programming paradigm, I think a lot about what is supposed to be legible, to whom, and when, and with what resources and investments. With all the work that goes into a visual-textual-multimodal communication–ultimately a kind of gambit not just for attention, but for a quality of attention–time taken to explore, persuading the reader-viewer to conspire in MacGyvering visual brainware into a heat-pump for new intuitions, new connections and the new emotion and action those might spark–hopefully around something fun or worthwhile, worth setting eyes upon for a while and maybe even closing eyes for stretches to rest and think. With all the effort that goes into something as contained a single chart, or as open-ended as an entire framework or online community, what persists, what actually gets remembered? Mostly what I seem to get out notebooking is a compulsive longing to make more stuff that helps me ‘see’ and is even potentially of interest to someone else. One thing I love about notebooks is they weave literacy and numeracy. Working in them has made me think about a lot of things I might never have considered. What are those anyway? Literacy and numeracy share a lot but have some different textures, they light up some different brain matter. _Reading_ code is a little different from reading prose, or poetry or a mathematic proof, reading in the sense of meandering through a landscape, seeing which paths are most well-worn, turning over object instances to see what methods and attributes are hiding under them and what they’re up to, what they’re eating. Occasionally there is salamander. _Reading_ code for me now largely means holding that code up to the light for a moment in a notebook. I will go to a fair bit of trouble to construct things around autocomplete-friendly ways of doing things. I struggle with declaratory schemes that make you remember and retype the names of keys in nested dicts. I think it’s great when an object can tell you all about itself. When the woods are full of quine-like [creatures](https://en.wikipedia.org/wiki/Quine_(computing)) singing thinly-veiled autobiographical ballads. This notebook of mine > **[Lightweight(-ish?) Particulate Mimicry with Voronoi Stippling](https://observablehq.com/@njcode/maybe-lightweight-ish-particulate-mimicry-voronoi-stippling)** > > I would like to experiment with using stippling implementations as an engine for a crude-but-compelling depiction of particulate behavior. Envisioned functionality: transition between a selection or shuffle of images each stippling is the starting... which currently merely breaks ground on some minor modifications to a fork of > **[Voronoi Stippling](https://observablehq.com/@mbostock/voronoi-stippling)** > > This notebook applies a weighted variant of Lloyd’s algorithm to implement stippling. Points are initially positioned randomly using rejection sampling, then at each iteration, the Voronoi cell centroids are weighted by the lightness of the contained... focuses on one aspect of a larger project idea I posted about here earlier > [@visualizing CR box / HEPA benefits](https://talk.observablehq.com/t/visualizing-cr-box-hepa-benefits/7116): > > I am thinking about simple ways to visualize the benefits of ventilation and filtration with a chart area that also represents a classroom seen in a simple silhouette or diorama-style view. Inspired by these dynamics: Core concept is: minimal code / maximal import reasonably easy for any viewer to quickly ascertain the role of all top-level notebook elements friendly to fork and reuse all or some elements without a lot of scrolling minimap looks crisp: stuff fits, graph not overly bushy … If you read all of this or any amount of this, thanks for your time!