Finite state machines enabling “end
-user programming” of complex animations!
twitter.com/guidorosso/status/1578867593389096960?s=20&t=OvidFAOZ58B47JsiQHmcvA
🐦 Guido Rosso: Here's how the state machine is set up in @rive_app for this. Without a state machine, all these interactions and logic would need to be written in code.
Btw this is all designed and animated in Rive too.
I wonder how much Stable Diffusion, NeRF, and similar techniques will change this?
Today, I’ve discovered this year-old but brilliant website and youtube channel by @Emil H: emilprogviz.com
It’s a series of videos about ideas for improving programming tools. The ones that especially spoke to me were the stretchy code map (episode 2), call graph navigator (episode 4). I’m personally looking forward to the next episodes, when Emil has the time to record them.
Programming a Problem-Oriented Language (1970) [pdf] - forth.org/POL.pdf
tylr, a tiny tile-based structure editor
Abstract: Structure editors designed for keyboard input often struggle to resolve the tension between maintaining hierarchical term structure and offering efficient linear editing affordances. Contemporary designs either compromise structure by deferring to text near the leaves or else maintain structure by permitting only edits that transform the selected term.
However, visually adjacent sequences (e.g. of operators, operands, and individual delimiters) do not always cleave cleanly to term boundaries, so even experienced users report difficulties with selection and code restructuring tasks. We propose a novel approach to structure editing, tile-based editing, that maintains term structure while offering linear selection and modification affordances.
The idea is to allow disassembly of terms into linearly sequenced tiles and shards around user selections, while guiding the user through restructuring actions and automatically inserting holes in a manner that ensures reassembly into a term. This paper introduces tylr, a tiny tile-based editor designed primarily to highlight this uniquely flexible set of affordances.
We evaluated tylr with a lab study where participants performed simple code transcription and modification tasks using tylr as well as a text editor and a structure editor built on JetBrains MPS, a state-of-the-art keyboard-driven structure editor generator.
Our results indicate that participants frequently made use of tylr's selection expressivity, and that this flexibility helped them complete some modification tasks significantly more quickly than with the MPS editor.
We further observed that a few participants completed some tasks more quickly using tylr than with text, but were in general slowed by a number of limitations in our current design and implementation. We discuss these limitations and suggest future research and design directions aiming toward more flexible structure editing interfaces.
Super interesting! Been following the progress of Tylr and this couldn't be more timely as I've been working on very much the same challenge of assembling term structures from linear parts and disassembling them back for editing. Was there someone from the Tylr team in here?
Ashamed to say that I've done almost no hands on or under the hood research of the existing structure editors before starting to write my own, but I would imagine that, unless the child kinds of all terms are known (or the user selects the kind themselves), basically all of the editors have to do assembling from linear parts to some extent and the innovation in Tylr is being able to disassemble as well?
As for the demo, shouldn't it be possible for a structure editor to just allow pushing the argument(s) to their next possible position up/down the term tree without disassembling. Just need to know the linear order of the leaves? I feel like my editor should be able to and I wonder if I'm not seeing something.. Of course there's the question of how to expose it to the user..
Another thing that I've been thinking regards this is whether disassembling the whole expression/body is prefereable in all cases or would you still want keep parts of it as terms and therefore be able to render term specific UI in between the linear parts. Like, what if there's a multi dimensional array in your expression that is always rendered with a specific UI and can't reasonably be disassembled to linear parts..
Lastly, I wonder how much of the cases where it feels that disassembling is beneficial are due to the pro-code like syntax and because the editing patterns that people are used to. Btw, did the users in Tylr's study have programming experience? What if the braces wouldn't exist (or were just decorators) and user would just select the two arguments and press/click right twice to move them to be the last arguments of the first function?
Is the criticism demonstrated in MPS also valid for block-based editors? The same task, in a block-based editor, would just be drag and drop twice, which seems exactly what the person wants to do. You would need something more like a statement stack than an array block to be able to do function calls with an arbitrary number of arguments, easily. And that list-of-arbitrary-length hasn't been implemented in Blockly, yet, AFAIK. But it seems feasible. In which case the task you describe would amount to dragging and dropping the two terms where you want them.
I know there are criticisms of drag and drop as an interface on other grounds, but it feels like TYLR only really solves the problem of letting people who want to use linear text continue to select text the way they are used to, while maintaining a structure-aware interface. Which isn't a problem in things like Scratch. Is that fair? Or am I missing some other way the same problem arises in block-based editors?
the target audience of tylr is not going to use block-based editors
Arguably, "tiles" are trying to be a text interface and a block interface at the same time, so I'm not sure that is strictly true. It just seems to let you choose an arbitrary string of text, turn that into a block, and then let you insert it only the places that block will fit.
Perhaps the example is bad, and the better example in the context of block-based editors is that there is no ability to select an arbitrary sub-portion of the serialized representation of a term. Like in TYLR you can select and cut and paste *4 omitting the first operand, but in a block based editor you cannot, you can only drag _*4 . I'm just not sure that is a valid criticism of block-based editors, either, because it presumes that being able to deal with the serialization directly is good, and block based editors reject that assertion. But I'm also not sure it isn't, because maybe people who use structural editors would like to be able to wrap *4 around any term that could serve as the first operand. Maybe the criticism is that block based editors allow you to insert something inside a term, before a term, after a term, but do not allow you to wrap one, and this does?
Jason Morris that's actually a much more convincing case for being able to disassemble terms! I felt that there is value in what Tylr is demoing, but that their example is not the most convincing one. Now the question is, how often do you actually need to move root and one child, leaving the other behind..
Of course, it could be that being able to disassemble improves interactions a bit here and there, although there's no killer case for it.
Yes. More than that, I'm not sure you couldn't make a block-based editor work that way. If CTRL+drag allowed you to place a term outside another term instead of inside it, changing what qualifies as a place you can drop it, you could drop *4 on top of whatever you like. You could even have three modes, one for matching external only (the default now), one for matching internal only, and one for matching both. But again... who needs it? Anyone? I don't know.
