From a gradual enrichment standpoint I understand but from a data entry standpoint this seems like more work.

See also; plugging these: * A new publishing discipline * plain.txt.htm (An assembler)

See also An app can be a home-cooked meal along with this comment containing RMS's remarks with his code-as-recipe metaphor in the HN thread about Sloan's post:

some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.

Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.

Interesting that this is written by a BSD guy.

Accessibility is more important, after all, than Kartik says it is (elsewhere; cf recent Mastodon posts).

How to get remote control over the Hypothesis sidebar (one way, at least):

1. Use the bookmarklet to open the sidebar
2. Click the sidebar's "Help" icon in the top right
3. Right click the "Help topics" link and select "Inspect" in the context menu to open the element in the browser devtools
4. Remove "noopener" from the link (easiest way is to just delete the element's "rel" attribute)
5. Change the link target to something other than "_blank" (e.g. "foobar")
6. In the sidebar, click the now-modified "Help topics" link
7. For good measure, in the new tab that opens, navigate to the same URL loaded in the sidebar (should be something like https://hypothes.is/app.html with a site-specific URL fragment; you can get the actual URL from the devtools JS console with document.documentURI, or right-clicking the sidebar and selecting "View Frame Info")

From the secondary tab ("foobar" opened by click in step #6) you should now have unrestricted, scriptable access to the DOM of the original sidebar iframe, using e.g. the JS console in devtools instance or a bookmarklet applied to the secondary tab—access it as window.opener.

Ungar, around @1:00:00:

I try to explain to people that the notion of compiler is broken. Of course I learned this from Smalltalk, but what we want to build is experiences--artificial realities that convince you that your source code is real. It's directly executed. There's no lag between editing and running[...] The environment stresses things in your program, not tools--which is another rant I have. It's this whole idea that we want to put you in an artificial reality--I got that from Randy [Smith]--in which it's easy and natural and low-cognitive-burden to get the computer to do what you want it to do, rather than running language translators that turn weird strings of text into bits the machine can run

Good. Don't. The number of people who think this is a virtue is frightening. The rationale is usually not well-reasoned and whatever values they pretend to hold can almost always be shown to be hollow.

The world could benefit from a curated set of bookmarklets in the style of Smalltalk ("doIt", "printIt", etc buttons) that you can place in your bookmarks bar (or copy into a bookmarks document and open in it in your browser), where the purpose would be to allow you to:

1. access a new scratch area (about:blank) for experimentation
2. make it editable, or make any given element on a page editable
3. let you evaluate any code written into the scratch space

scratch.js aims for something something similar, and though laudable it falls short of what I actually crave (and what I imagine would be be most beneficial/appreciated by the public).

This is what I'm aiming for with triplescripts.org. Initially, I'm mostly focused on the reproducibility the build process for software. In principle, it can encompass all kinds of use, and I actually want it to, but for practical reasons I'm trying to go for manageable sized bites instead of very large ones.

"A multi-dimensional erector set that will go on forever..."

No, unfortunately not forever.

my personal hope is that we can build a more sensible coherent web, that exudes the machines inside of it, by better harkening towards custom elements ("webcomponents"). move the page from being a bunch of machines in javascript, to a bunch of machines in hypertext.

and then build pages that start to expose & let the user play with the dom. start to build experiences that bridge the gap into the machine/page.

and keep going. keep going. build wilder web experiences. build more machines. and keep building battlesuits for the user, out of more componenets, out of more web, to let them wrestle & tangle with & manipulate & experiment & hack on & see & observe & learn about the truthful, honest, direct hypertext that we all navigate.

The importance of learning to design, and interpreting/translating real-world needs.

A mental map (or cognitive map) is our mental representation of a place. It includes features we consider important, and is likely to exclude features we consider unimportant.

(Urban planner Kevin Lynch, early 1960s)<br> Elements of mental maps

• paths
• edges - boundaries and endings
• nodes - focal points like squares and junctions
• districts
• landmarks

Modern maps could use augmented and virtual reality to help clarify those elements, making a place easier to navigate and use. But they can also add useless noise that makes the place seem more confusing than it actually is.