A useful story telling device like an aside, especially given it can point to things in data space on a chart. The contents of an annotation is a normal cell, so you can embed drawings or programs in them, but by default its markdown. Also useful for collaboration, so people can accurately identify content that needs revision without affecting the primary content. (works on Notebook 2.0 too).
This unblocks a really great workflow where you can annotate a draft in place without have to switch around apps or scroll and lose focus on proof-reading. The fact it is a pointer saves a lot of typing and mental alignment to describe where you are in the doc, and because it is out-of-band from the main content it leaves the corpus in it original state. Really productive for proof-reading
Is the notebook published?
Annotate yes, the optical localization no but its the next in this series realtime optical positioning / Tom Larkworthy | Observable
Oh the annotate notebook was not published, doh, its public now.
When I opened this I said “oh my God” in such a startling manner that my wife ran into the room to check if I was OK.
I was just thinking about the difficulty of annotating by pointing (/ direct manipulation / indexicality / …) in a notebook paradigm…
The data one is especially cool. But you can’t make that annotation just by clicking on a point, can you? It requires specifying the datum in code? Probably doable but hacky. That one’s been a longtime feature request. People look at notebooks and see charts and think “a chart” is a primitive of a notebook, as if a notebook knows how many charts it has, when it’s can’t, it’s not a primitive, it’s just more DOM elements, so the notebook doesn’t “know about” data points, for better and for worse, and so it’s hard to do a nice data annotation UI…
the “retarget” button
its easer to start a annotation from text span, and then click on the Plot and it attaches in data space. Then it works! But it does treat Plot as a special case. If you target a d3 diagram it attaches relative to a DOM node, which seems to work pretty well but I am sure there will be situations it does not work so well, but thats why it has a stack of fallbacks, falling back to cell then notebook CSS anchors, if it can’t find its primary target.
Internally it is rewriting the code. So the annotation is always expressed as cell definition code, so the act of creating an annotation through the UI is coding, just not through an ASCII interface => i.e. cell definitions for annotations are synthesized and placed in the Runtime, using the low-level compiled representation. If you had exporter-3 active you can fork the runtime and keep your annotations, on my personal website it works like that, link. On my site, edit the annotations and click “fork” on the top left burger menu, the annotations are remembered, because the runtime is serialized via reflection. Same story with Inline editable md / Tom Larkworthy | Observable which is the default annotation cell, its the normal markdown template string, but it reprograms itself via a notion-style UI.