You are viewing archived messages.
Go here to search the history.

Duncan Cragg 2023-12-18 10:42:20

"Apps considered harmful"

(or "I can't believe how you all tolerate apps")

My latest:

open.substack.com/pub/duncancragg/p/apps-considered-harmful?r=1sq2dz&utm_campaign=post&utm_medium=web

Duncan Cragg 2023-12-18 10:45:10

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! 🤗)

🐦 Duncan Cragg (@Duncan__Cragg) on X: "Apps considered harmful"

(or "I can't believe how you all tolerate apps")

My latest:

https://t.co/gpGxU9k3A9

brett g porter 2023-12-18 13:49:39

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.

Duncan Cragg 2023-12-18 16:04:47

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

Kartik Agaram 2023-12-18 16:23:58

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.

brett g porter 2023-12-18 16:26:43

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"

Chris Krycho 2023-12-18 22:18:22

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.

📝 Why Not OpenDoc-Alikes? — Sympolymathesy, by Chris Krycho

Maybe apps, for all their limitations, actually have some things going for them.

Chris Krycho 2023-12-18 22:18:34

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

Daniel Buckmaster 2023-12-18 23:01:00

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?

Xavier Lambein 2023-12-19 08:54:32

@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.

Chris Krycho 2023-12-19 17:04:25

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.?”

brett g porter 2023-12-19 17:27:06

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)

Konrad Hinsen 2023-12-21 07:36:12

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.

Beni Cherniavsky-Paskin 2023-12-24 10:51:57

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.)
Duncan Cragg 2023-12-24 13:53:42

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.

FreeMasen 2023-12-19 18:11:28

Wrote up a little post about learning LLVM's Intermediate Representation: freemasen.com/blog/llvm-ir

Kartik Agaram 2023-12-20 05:12:48

4 primitives that can be composed into little productivity apps for yourself, particularly on a phone or tablet.

akkartik.itch.io/carousel/devlog/653245/the-lua-carousel-productivity-suite

I think the next major piece I'm missing is images 🤔

Vardnan Sivarajah 2023-12-21 14:00:06

Hey everyone! 👋 I’m a student who’s been working on a side project to explore how LLMs may augment creative problem solving.

I’ve synthesised everything into a rough concept I would love to hear your perspectives on:

~Here is a quick demo:~ youtube.com/watch?v=eDRg5WgSrm0

Initial inspirations include Jef Raskin’s “Archy”, Mozilla’s old “Ubiquity” project, the thinking of Vannevar Bush, and recent tools like “mymind”. There are still many ideas and user experience concerns to be properly fleshed out, but hopefully it’s an interesting direction.

Nilesh Trivedi 2023-12-22 07:49:29

I had helped build this tool to create civilizational tech trees so that resources (like talent and funds) can be directed where they are most impactful.

Foresight institute has used it to map the tech tree in 5 domains: Intelligent Cooperation, Spacetech, Neurotech, Molecular Machines, and Longevity: foresight.org/tech-tree

📝 grapher

SVG-based interactive graph dataset editor with live real-time collaboration. Powers Foresight Institute's civilizational tech trees: https://foresight.org/tech-tree/ and http://LearnAwesome.org|LearnAwesome.org's learning roadmaps: https://learnawesome.org/#/roadmaps