I've posted this to Twitter as well:

twitter.com/Duncan__Cragg/status/1736695163727057219

In case you like to do your threads in public!

(I've moved my techie Twitter to that account, by the way - feel free to follow me there! 🤗)

Reminds me of the work that Jef Raskin was doing when Jobs kicked him out of Apple, and that he picked up again later at a few places -- the demos I've seen/read about were compelling.

Hmm interesting, I looked Raskin up, but do you have a specific link for me/us showing what you found compelling?

I've always found your framing of "not apps!" distracting. You want better programs, and you want an OS that permits better programs. I don't really care whether you call those better things apps or something else[1].

I think your argument would be improved by trying to strengthen the position you're opposing. Decompose the word "app" into what you think apps provide that is good. Off the top of my head:

• Apps are units of behavior. They let you do new things.
• They are units of namespacing. App A and App B might both have a button called 'foo' and it can mean different things.
• They are units of software delivery. I give you some bits in a box, and you expect that the bits you got are exactly the bits I sent.
• They are units of commerce. You give me some bits in a box, and I pay you some escudos.
• ... What else?

Now talk about what's wrong with the way people currently obtain these features , and how we can make things better. That would help me understand better what you're up to.

[1] I also think "app" is prime memetic real estate that we should fight for and not just give up on. But that's a less important argument.

but do you have a specific link for me/us showing what you found compelling?

My main exposure was his book "The Humane Interface", the wikipedia coverage gives the flavor, especially "An end to stand-alone applications – every software package should be structured as a set of tools available to users on any document. For example, in the middle of writing a text document, a user should be able to do a mathematical computation by writing out the computation in the document, then hitting some "calculate" function"

This inspired me to write up a fairly off-the-cuff “gut reaction” type blog post. As I note in the conclusion there:

I do not think we are at a global maximum in software design.

I do think that it is easy for folks dissatisfied with the limitations of apps to overlook the many powerful affordances they offer, though, and for computing aficionados to overestimate the degree to which regular users even > want > to”compose together components”; the simplicity of the “app” model is one of its great strengths, even as it also (at least in its current form) also hobbles”power usage” even for those regular users.

(Note: very much “off the cuff”.)

For example, in the middle of writing a text document, a user should be able to do a mathematical computation by writing out the computation in the document, then hitting some "calculate" function

Without having much familiarity, this reminds me of Oberon?

@Chris Krycho I agree that most users don't want to tinker with their app, and that providing a set of features for them is valuable. I think what most people in this space want to do is create an environment where it's /possible/ to tinker with your app, without having to download the source, edit it, recompile it, submit a patch, etc. Just like a lot of people in e.g. accounting will re-use Excel sheets templates made by other people (or their past selves), I imagine that a sufficiently advanced tool would let you make a "music notation" template (kinda like a DSL in the end) that people can use out of the box, but still tinker with if the need arises. Whether this is possible in a user-friendly way remains an open question IMO.

To be sure, I am in favor of increasing tinkering, scriptability, etc. To pick up the example from the app I use as an example there, one of Dorico’s gaps compared to one of its competitors (Sibelius) is robust scriptability—though it is a long-standing plan of theirs, because it makes it possible to extend the capabilities of the app so much. (Dorico can be scripted, with Lua, but it isn’t a public/stable API yet.)

I think the question is whether this is actually viable:

I imagine that a sufficiently advanced tool would let you make a “music notation” template (kinda like a DSL in the end) that people can use out of the box, but still tinker with if the need arises.

The domain complexities in any area I have tackled personally or have just followed closely are just astonishingly deep. It took four years for the team that built Dorico to get it to its 1.0 release with what was basically a blank check from the parent company, Steinberg… and it was probably the 3.0 release a couple years later before it was earnestly competitive with its major competitors. That’s the thing that makes me very 🤔 about any proposed “document-centric” model I have seen (as well as skeptical of general app skepticism). I notice, for example, that even in the Excel example, “much more extensible” or even “much more user-programmable” application ≠ “inverted model where applications are not primary but documents are”.

To me, then, the more interesting framing is not “document-centric” but rather “what would be the affordances of a host-environment that would make it easier for applications to surface embeddable components/elements/script hooks/etc.?”

It took four years for the team that built Dorico to get it to its 1.0 release with what was basically a blank check from the parent company, Steinberg… and it was probably the 3.0 release a couple years later before it was earnestly competitive with its major competitors.

...and an important detail that's elided here: the Dorico team wasn't starting from scratch building domain expertise. They had built the industry-leading notation package and were fired en masse. They started the blank page redesign as the leading experts in the field already. The workflow and mental model they developed with an opportunity to start over are different enough that it's difficult to interoperate either as a user or from a document/file format POV that it's hard to imagine it working in a document-centric world without a huge loss of fidelity (and it's interesting to me that Raskin specifically calls out music notation as a great use case for that vision)

Kartik Agaram makes some very good points that feel familiar, as I am also working in the "anti-app" space, though not at the extremist (OS) level.

I think it is important to pursue a positively formulated goal. "No apps" is a motivation, not a goal. You cannot move towards it.

I have settled on "computational media" as my goal. I see that as a space of directly manipulable data to which computations are attached - a bit like a spreadsheet or a word processor, but for more diverse types of data and computation. I have no generalist intentions in this endeavor: my domain is computational science.

Once you take the "computational media" perspective, all the points that Kartik Agaram became very real issues. Namespacing is the easiest one, because it's just a matter of conventions, possibly enforced by a very transparent framework. It's less obvious how you can let people add behavior to a computational document while maintaining the good features of apps.

Finally, a note on why I didn't choose the extremist perspective on "no apps": I actually like them for some purposes. There's a tensions between agency and convenience: the more agency you have over your computations, the more you need to engage with the technology, and that has a cost (in terms of effort). For many use cases, the convenience of apps is just fine with me. Weather apps? Great! E-mail apps? Horrible! For other people, it may be just the opposite of course.

re namespacing in documents:

• Boxer had a very inspiring take on this, distilling wide range of functionality to single structure — nesting (spatial ⇔ functional) of boxes. With lookup working inside->out, again ranging from variables and kinda-closures to "apps" by way of localized UI customizations, e.g. what do mouse-click or key-F1 do is scoped to nearest box defining those names. I'd say their Principled Design paper remains the best entry point.

Use of the spatial metaphor is dependent on the fact that spatial structure

can be extremely compatible with essential computational structures. In par-

ticular, it will become apparent how two-dimensional configurations with

containment representing hierarchy can subsume an important core structure

to things like program and calling structure, hierarchical data, and file

systems.

• I found it interesting that Embark picked similar scoping model, only instead of nested boxes they present a more traditional outline. (Specifically in their demo, icons were assigned to particular waypoints, but colors were only assigned at higher level of the outline, to days. The map view looked for icons & colors starting from each waypoint/route and going up the outline, thus adding a "color: ..." child to a day affected all points & routes nested under it.)

Apparently Alexander Obenauer was involved and seemed happy to try a less structured approach to data than his "items". I don't know what AO has to say about namespacing or structure. Perhaps others do? It seems transclusion of item inside item would be a key aspect in the UI anyway. CSS is an interesting model to plumb for this as well.