I'm building a new prototype, working title: GLUI It's an attempt to enable creating complex configurations and scripts while avoiding the problems and limitations of configuration languages, scripting languages and UIs Here's the introduction video: If you find it too long you may want to use the Chapters feature to jump to sections that interest you. The introduction and motivation may be useful to get an overview. For a quick take on the powerful aspects of the prototype you may want to jump to 14:34 where I reuse a connection config in 3 places by linking to it and the derive a new configuration from it by using the derive feature. You want to try it? here it is, just remember it's the first version: https://instadeq.com/experiments/glui/v1/ Please let me know what you think, if you would like to know more, contact me and we can get into the details and/or long term objectives.

fwiw, I use CUE (cuelang) for config now. It is a brainchild from a Google engineer who was involved in writing both of the internal config languages there. Many lessons learned are incorporated. It's a logical language and uses unification to prove the input is correct. It also has a DAG engine (cue/flow) which can be used for scripting. ( https://cuelang.org | https://cuetorials.com ) --- Looking at your project, a few of questions come to mind • Do you have a written introduction or documentation? • Can this work with version control like git? What are "code" reviews like? • Who is this targeted at? Professional developers or more of the "low/no-code" crowd?

1. No documentation yet, this is the first thing I share, I've been working on it on an off for some weeks 2. It has a serialization format, that could be version controlled, snapshots could be versioned in the tool itself, it's pretty easy to make diffs of different versions 3. Not decided yet, I don't think I will target professional developers, or if I do it will be for the glue/scripting part

Congrats on the launch! I'm more of the prof dev, so I'm not sure how valuable my feedback / opinions will be... I prefer text based systems, UIs are too clunky for creating scripts. (though I have to admit, I have a plan for a "ui" like system for devs like me) • I didn't like the way adding options created inputs below, they would probably be easier to relate / understand if they were inline. For example, when I click "header", just add a row with two inputs for key/value. • The dots look like a drag-n-drop reorder indicator, the vertical three dots typically used for menus would probably be better. Reordering would also be a good feature • I think tooltips would be helpful, especially on icons • lifting the remove button up (as an "X") would make it easy to remove entries added by misclicks / exploration. Docs will definitely help uptake, anecdotally from my own projects

1. I have to find the right balance of nesting and flatness, I still think headers should be nested to give them meaning, make it easier to collapse and avoid them layin around at the top level 2. I kind of copied notion, I changed to the 3 dots as you mention, still have to decide how to support reordering in a way that works well on mobile, I'm trying to avoid features that depend only on precise drag and drop (I have stories to share from instadeq 😄) 3. there will be tooltips and contextual help (I can always nest help inside each node 🙂) 4. I'm trying to avoid clutter by default, my objective is that if nothing has focus it should almost look like text, adding remove outside also makes it more error prone if close to other things 😕

Is mobile something you expect to have a meaningful amount of usage? I would think that the screen space is too small to support a good DX/UX

I plan to use the horizontal space to create different columns, so I want to keep each column slim. In terms of avoiding drag and drop, I want to support touch devices but also I've seen people get frustrated with missed drops after long drags

Cool demo! I have been thinking about a better version of Zapier's Oauth configurer (and in general most of Zapier interface). This seems quite close and has some very nice features like reuse and minimizing the clutter to jsut what is non-default. I really like it! One thing I often need to do is bind a part of one thing to another thing, like set the AUTH token to a secret value for instance. I don't get a sense that interpolation is possible, it's close to what you described as a link but I don't think its the same thing. (I like that derive thing too). The thing reminds me a little of JSONEditor https://json-editor.github.io/json-editor/ if you have not seen it.

I used to do that kind of thing a long long time ago 😄 https://github.com/marianoguerra/json-edit

I love seeing a Notion-like interface! From the presentation perspective: it would be easier to understand if you framed it in a more story-like structure. For example: "If you need to get some data from Google Maps API, and store it in a CSV, this is how you would do that...", and show it end-to end. Even after watching the video and playing with it I'm still unclear if this is supposed to be executed, deployed, or if it will generate code or just a yaml config file. My opinions on the UI: • it would be nice to have the cards be either pop-ups (be on top of content), or be on the side of the active column, that way it wouldn't move the content up and down. • It's a bit hard to visually parse the indentation level, maybe increase the horizontal space added with each level, and/or reduce the blank space between the item (icon + text) and the parent line

This is really interesting. I could definitely see using something like this as an alternative to Blockly for a visual input interface, if it was open source. My only critique is that it's not obvious when parameters are alternative to one another, or what is making the box for selecting sub-elements disappear. That may be because I'm on a phone atm. Is there a facility for making declarations inside the editor and then using them later, and maintaining the connections between them so if they change the name in the declaration it changes everywhere? Those are some of the challenges I have run into with the tools I'm using.