I've been figuring out some improvements to the li...
# devlog-togetherk
Kartik Agaram
12/22/2023, 8:37 PM
I've been figuring out some improvements to the live programming environment for my apps. Some little videos in 🧵
Kartik Agaram
12/22/2023, 8:43 PM
Here's how things were for a year until a month ago. An infinite surface on which you could move definitions around independently.
The problem: sometimes definitions would overlap. And I was wary of going down the slippery slope of a complete overlapping window manager just to solve this one problem.
Kartik Agaram
12/22/2023, 8:46 PM
On Dec 10, after some prototyping on Lua Carousel, I gave my definitions some minimal physics so they could nudge other definitions aside.
The problem I quickly ran into was: it was very hard to move one definition to the other side of another. More broadly, my heretofore calm UI -- where things mostly stayed in place until you move them -- became much more chaotic.
Kartik Agaram
12/22/2023, 8:50 PM
Yesterday brought one more nice improvement. Now I only resolve collisions when I release the mouse. This gives an effect of picking up a definition above the surface when pressing down the mouse. I also started showing the "padding" I resolve collisions within to give more of a hint for what's going to happen when I let go of the mouse.
The final refinement is something you can see in the first half of the video: if I drop the definition back close to its original location, nothing moves. Acts like undo when I change my mind after picking up a definition.
g
guitarvydas
12/23/2023, 10:19 AMMy opinion: it is not up to tool designer to determine what the Architect should want. If the Architect wants overlapping boxes, so be it. The tool designer's job is to make the Architect's job of laying things out easier during the editing process, but, not overriding the Architect's intention for what the final (static) display should look like. The Architect gets the final say, not the automation. This is why I argue that Obsidian's graph view is useless - automation at the wrong time, when it's no longer wanted. There is no need to implement an "overlapping window manager". Let the Architect do what is wanted, just provide boosts during the process of editing.
guitarvydas
12/23/2023, 10:19 AMThis reminds me of Drakon Editor's "smart editing" feature. As a User, I found its UX to be simple and predictable. To the best of my recollection, the Drakon Editor constrains physics to work in only one direction at a time (X, primarily). The editor presents boxes in columns. If a box is too wide, the whole column, that the box is in, widens - and all boxes in other columns shift over. https://drakon-editor.sourceforge.net.
guitarvydas
12/23/2023, 10:20 AMIMO, the second half of the 3rd video contains a UX "surprise" - the thin box on the right moves over after the mouse is released, but, there is no indication (Raskin's word) that this will happen. Is it possible to show the potential effect of the move while the mouse is being dragged, but, not yet released? Phantom boxes, or something like that?
guitarvydas
12/23/2023, 10:20 AMGedanken exercise. My bugaboo is "coupling". In my view, "hidden coupling" hampers DX. The code in the boxes is decoupled on input, via function formal parameters, but, is not decoupled on output. I infer that code in one box can call code in another box. Is this correct? Q: What would it take to decouple outputs (aka return values)?
k
Kartik Agaram
12/23/2023, 6:54 PM
Thanks! Yeah I've been considering phantom boxes. The challenge is that collisions can cascade, and you might have 10 layers of phantom boxes. Which gets noisy. You start wondering which box is which. I'm still noodling on this.
The primary point of the 3rd video was to show the box on the right moving at the end. It overlaps with the shadow before the mouse is released. That's the intended indication that this will happen. So far that's the best I've been able to come up with that feels like an appropriate amount of noise.
> it is not up to tool designer to determine what the Architect should want.
>
The whole point of everything I do is to question categories like this. There are no externally imposed requirements, only internally conceived desires. If someone else uses my tools they're now both architect and tool designer. With me advising, for sure. But the goal should be to learn to fish.
g
guitarvydas
12/23/2023, 8:29 PM"Which gets noisy." Yeah, good point. Columns and rows are easily understood, and, people love spreadsheets. ... There seem to be 2 extremes in this problem space - totally manual vs. totally automated - and nothing in between. A dangling question in my mind is "how to map between the two extremes?". How to make it easy to program, yet give a good UX (my Bank (RBC) is a prime example of too much emphasis on totally automated - easy to program, but, bad UX).
4 Views