https://player.vimeo.com/video/797476910

I think membrane is well positioned to build tools like these (or even better).

I like this direction! This product looks initially focused on constraining the editor to median web2.0 ui, and can generate react code. It will be interesting to see how a tool like this can work as a nexus between languages: different design systems, different front end frameworks/runtimes. I think I am interested in a design space where I can layer on dynamic design constraints as the design proceeds. When I am designing in photoshop, most things are mutable, and there is a lot of manual updating of elements to maintain proportional relationships between elements when something changes. My visceral frustration with that mode has led me be to believe in and seek functional programming broadly, and this visual-tools space as fertile ground. There is a powerfully engaging playful feeling when you can get real-time direct manipulation of parameter changes, let alone higher-order objects (and their reactive relationships). Simple examples: Changing parameter: scrolling a slider to change the color realtime in a design. Manipulating object: “grouping” a set of elements, and then dragging around the group like it is one element. I guess i’m talking about direct manipulation in general, which in some sense is UI in general. This Noya product is to me “direct manipulation” of a “design object” that is coded with reactive rules to observe a design system (set of design constraints). But of course I don’t want to be hemmed in by a monolithic framework (hence I look towards a clojure implementation). They say this product is not designed for visual exploration. But I am interested in that. And I believe these kinds of embodied rule systems can greatly accelerate and empower exploration. Ex. At some point I might decide I want my design to be low luminance contrast . All the elements should recognize the new constraint and display appropriately. Bt the constraints should be easy to layer and customize. A rule for fonts: I want serif titles and sans serif body font; then can reverse it when it doesn’t look right. As you build the design, you are in fact not building a discrete object or artifact, you are building a design system; and have access to a reactive “design app” UI that is constrained to this design system. So you can push and pull your design, within this arbitrary design space, and visually explore the nature and contours of that space with realtime wysiwyg UI. And once you get to a terminal point in the current design space, you can add new rules and further explore (and refine the design) in the newly constrained design space. Forgive me if this ramble pertains more generally to state machines, rule engines and reactive systems than the specifics of Membrane. Just trying to crystalize the thought. I think the points I’m trying to emphasize are: • Realtime reactive wysiwyg feedback is a must. It should be supported when manipulating higher-level objects/relationships • the visual rule system should be customizable and arbitrary (not some monolithically baked design system, that might be overly constrained by the web, like Bootstrap, etc). • I want to explore a design space and feel it out. I often don’t know what I want until I see it in context. • I REALLY want to avoid the tedium of managing these contextual relationships manually when a design takes a left turn.

I feel the same way. I've been working on a tool in the space for quite a while and I feel like I'm making some progress. I'll hopefully have something to share in the next few weeks!

Cool! I still haven’t had a chance to play with your spreadsheet demo. But greatly looking forward to it. I believe your choice to embed the code editor is important. Because if that level of “editor” ui is already functional (and its implementation accessible), then a spectrum of alternative “editor” ui’s should be accessible on the same stack. Everything from a drag and drop scratch-like code builder, to some way more stripped down abstracted “toy” UI for a more limited dynamic. And then we may have the potential to move in and out of, and evolve, “editor” mode, at will, within a single project, or even single session.

All this reminds me of https://en.wikipedia.org/wiki/OpenDoc :thinking_face: I was inspired by it’s vision when it was first pitched. But apple was in flux and it was quickly abandoned. It could have been an early open standard for this kind of stuff. I guess was swallowed by “worse is better” kind of dynamics, considering the complexity involved.

> The core idea of OpenDoc is to create small, reusable components, responsible for a specific task, such as text editing, bitmap editing, or browsing an FTP server. OpenDoc is a framework in which these components can run together, and a compound document format for storing the data created by each component. > users can “build up” their documents from parts. Since there is no main application and the only visible interface is the document itself, the system is known as document-centered.[3] > “OpenDoc” was a terrible name for an interesting technology. Instead of requiring developers to write huge applications that had to do many things (for instance, any credible word processor needs not just editing features but spell checking, tables, embeddable photos, etc.) the OpenDoc concept was that developers could just write the one piece they were best at, then let end-users mix and match all of the little pieces of functionality together as they wished. > OpenDoc had several hundred developers signed up. Apple was rapidly losing money at the time and many in the industry expected the company to fail. > In March 1997, OpenDoc was discontinued with the return of Steve Jobs to Apple, who had been at NeXT during its development. He said Apple’s management “put a bullet through [OpenDoc’s] head”, and most of the Apple Advanced Technology Group was laid off in a big reduction in force.[12][13]