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.

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.

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

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.