On UI as Code

General
5

Thanks so much for your kind words! I’ve always appreciated your work, so they mean more coming from you.

I just wanted to unpack this point a bit to make sure I grasp what you’re saying.

Yeah, I should be more clear. I didn’t fully follow your 2 models, but I don’t mean to say, “oh removing an underline is such a trivial task, you have to do more complex things to be taken seriously.”

What I mean instead is, when I talk to people and try to ask them what they would like to change in the programs they use, somehow it is simultaneously true that everything is broken and nothing is broken. So much is not how they would want it, that a) they learn a form of helplessness in terms of growing accustomed to things not working as they want, and b) in this mode of learned helplessness, small pain points like a confusing bit of design disappear, and what eventually tends to rise up is bigger things like, “I want an app that does ____,” which often boils down to “do what I mean.”

So it becomes hard to do science. You can’t run experiments about, “how do people use functionality to make small changes?” independently of “how well does the infrastructure supports large changes?” The perceived size of a program affects people’s sense of freedom. Even if they could easily accomplish some task, it’s very easy for them to get intimidated and think they can’t do anything. And paradoxically when they think they can’t do anything, small things disappear because they’re subconsciously excluded from consideration. And big things that manage to get past the intimidation are ill-posed and impossible to act on.

This is all hypothesis. I observe the intimidation, but I’m guessing at reasons. I haven’t actually been able to create that sense of freedom either yet.

if there was anything malleable within it along the lines of a document model such as the DOM or any means of seeing substructure other than source code in running applications. If my page had been written in LÖVE rather than Quarto+Typescript, would I have been able to follow a means like Method 2 above or would I have had to find a way to edit the original source and rebuild the app?

Short answer: yes they would be left at the level of editing the source code. There’s certainly no X-ray vision yet on the level of a browser’s wonderful inspect operation.

That said, I have some partial answers to this gap:

  1. I spent a while looking at Quarto after my previous comment and it does look quite nice in many ways. I think on one level I’m asking if they’re undoing all their nice work of keeping the markup open by just trying to do too much, polish too much, and so having a quantity of code that intimidates.

  2. On another level, I think I’m questioning declarative vs imperative representation. Mutating a declarative representation is wonderful once you gain some fluency with it, but gaining that fluency becomes a hurdle. And a lot of declarative representation is very hard to wrap your head around. For example nobody it seems can guess ahead of time what any non-trivial CSS will do. With simple imperative programs I feel like I can always understand things to arbitrary levels of detail. Whereas with CSS I’m stuck cargo-culting black boxes. And (here I’m projecting) that might be adding to the intimidation factor. Declarative representation is nice if you consider just the declarative code in isolation, but realistically I think it can still be intimidating proportional to the size of the implementation. At that point, is it maybe better to just write imperative code in a very simple way?

  3. While you have to edit the original source, you don’t need to have a heavyweight step of rebuilding the app. I have been live-editing my apps for a while now, and the kernel of code to accomplish this (documented here) is tiny thanks to Lua being just as dynamic as Javascript. The key thing I do is maintain source code separately for each top-level definition (rather than some larger file or module). Now I can request from an app the source code of any definition, and then mutate that definition while the app is running. None of this is at the maturity of the web of course, which is why I’m constantly wishing for the world to exercise it more often.

  4. As it happens, I’ve actually been working on a markup language built entirely out of Lua literals. Version 1 is a couple of years old, but I hope to share the current version in the next day or two. It’s extremely bare-bones:

    • Markup can consist of graphic shapes, or rows or columns or text.
    • Rows can contain columns or text.
    • Columns can contain rows or text.
    • Text consists of lines that can wrap.
    • (the new bit) Lines can contain some very basic inline styling: color, bold/italic and link targets.

    I want this markup for a mobile-friendly in-app browser for browsing source code, while providing some level of graphic affordance so I can describe source code using box-and-arrow diagrams. That previous link above shows the desired behavior, but only mocks up the markup. I’m working on a real implementation.

Sorry about the wall of text!

2 Likes