Curious about what this group thinks of the approa...
# share-your-work
Curious about what this group thinks of the approach we're taking with 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?
I wanted to do a similar-ish thing to do with creating diagrams in Svelte, where you could drag boxes to reposition them - with some way of doing the drag within the browser and having it talk to your editor somehow, so no dedicated design tool involved - but the thing of mapping the drag action to a change to a particular syntax node seemed a bit too complex to just "knock together" something like that
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.
Currently we support React projects written with TypeScript.
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.
On fast prototyping, one of the strengths we have there is to allow the use of production components right next to whatever new the designer is working on (e.g using a combination of Box and Text). So you can get a much better sense of the real product, while also allowing for creative freedom (which then needs to be turned into production components with tests being written by devs).
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.
🤔 1
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). 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.
By "explain" I don't mean syntax specifics or technical jargon, more like data flow, i.e. "this todo list component repeats a todo item component for each todo in the list it is displaying. To each todo item component we pass in the todo data which includes the todo title and whether the todo is completed".