Curious about what this group thinks of the approach we're taking with https://www.henosia.com/ We provide direct manipulation of the visual output of a running program, and think this is a great fit for UX Designers where their intent is "move that", "adjust this whitespace" and "insert a button below". It's visual TypeScript code editing in real time for designers. Oh, and we have multiplayer in the mix, which has been, let's call it interesting, so far 😂

Interesting! So if you wanted to integrate it with your own custom design system (components & CSS), could you define a bunch of mappings somewhere between visual actions (dragging edges to resize etc) and corresponding changes to the elements/attributes in the code? Also - what frontend frameworks does/will it work with?

We're still working out how to support the early stage ideation design work where free flow layout is likely the best interaction. Our initial focus is on using design systems with a well built set of foundational primitives and layout components that you can use like Lego blocks. Both Chakra UI and Braid DS support this way of working quite nicely.

ux designer might perceive this is for developer, developer might perceive this is for ux designer. Design should be cheaper to change than real frontend code, because it is under-specified, with lots of details omitted. If the design is the frontend code, can we still sit beside the designers desk to iterate prototype fast?

There is a wide spectrum of types of design work, spanning for very early ideation + visual design and all the way to interaction design with pre-existing design system components. We're currently adding most value later in the process, but we are also looking at supporting earlier stages with freeform layout (e.g. absolute position and dragging to reposition) to allow designers to just "throw something on the canvas in an unstructured way until it feels right". That "something" can be quite low level primitives like Box and Text components, that can provide some of the same freedoms that rect and text does today in Figma for example.

Can you design components that vary their visual appearance depending on the state or the input data with Henosia?

@Paul Sonnentag We've done early explorations in this area, but nothing that we can share widely yet. Since our source of truth is TypeScript code (as an AST) we can reason about the flow of React props and conditional rendering of elements/class names. The challenge is to provide a meaningful UI for a designer based on what's essentially open-ended TypeScript code. Same as the TypeScript compiler does flow analysis, there may be cases where code is too difficult to follow for the tool (which we would then tell the user), but there may be an 80/20 rule in there where just giving designers a bit of conditionals would add a lot of value.

The 80/20 rule will get you a long way. When code is too difficult for a good tool to follow, either (1) the code is bad, or (2) it's implementing some higher order pattern that uses a different mental model than the flow that the abstraction layer ends up producing. Rails filters come immediately to mind as an example of (2). https://guides.rubyonrails.org/action_controller_overview.html#filters The mental model is pretty simple, but the control flow that leads to their execution is pretty much inscrutable.

Good points. I've been thinking lately that high quality UI component code should be easy to explain to a non-technical designer if they asked how a component works. If code meets that quality bar, a tool has a chance at visualizing it in a way where the designer can feel safe enough to edit the visual parts.