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:
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:
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 singing thinly-veiled autobiographical ballads.
This notebook of mine
which currently merely breaks ground on some minor modifications to a fork of
focuses on one aspect of a larger project idea I posted about here earlier
If you read all of this or any amount of this, thanks for your time!