Thanks so much! I like that idea of embracing the mess and letting AI handle the busywork. Making messes is more fun :)
538 karma · joined February 10, 2016
For getting components into the system: we're working on a protocol (more specifically a TypeScript interface) that defines a mapping from component types that the tool understands (sidebar, navigation header, etc) to component implementations. You can add component types that the tool doesn't understand too, but like you point out, then it's more work to define the rules they use. Anyway, you can bring your company's design system into the tool by implementing this protocol - the tool loads your implementation (currently from npm, but could be anywhere) at runtime.
Right now the default rules are based on component type, so when you add a new design system implementation, you start with the default rules for known components. These can be customized on a per-design-system basis via the protocol, but again it's a bit tedious to do. We've explored using generative AI for determining component rules which seems promising so far. This could potentially be less tedious and more flexible for custom design systems, and is one area we hope to explore more.
1. There isn't anything fundamental about that tool that requires React. We have a lot of React experience and it's a very popular framework, so it made sense for us as a place to start, but we can definitely consider supporting other options.
2. Absolutely! We have a first draft of our mapping protocol already that works reasonably well, but still needs more iteration before we open things up. It supports a custom hook for attaching things to the DOM, so shouldn't require React specifically either.
Can you share a little about how you use web components, so we can better understand what an integration should look like? Do you use any kind of JS framework (at build time or runtime)? Do you use JSX, or is it all vanilla HTML?
Creating real designs and shipping to production within a constrained environment (e.g. https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...) can be super high leverage, so that's ultimately where we want to go. Right now every company that wants to do this has to build it themselves. We didn't use an off-the-shelf solution like Webflow at Airbnb (afaik) because there was no realistic way to integrate it into our stack. I'm not sure if Noya's code export will be what people end up using for this - maybe some kind of JSON-config or something else will be the more useful artifact.
As an analogy, Retool makes it easy to create internal tools, and is usable by more than just eng. But somebody on the eng team needs to first configure it a bit (e.g. plug in the company's data sources) before making real tools becomes possible/efficient. Noya will require a similar level of configuration to become usable in these more advanced scenarios, but we think the value it delivers will be worth the effort.
We're currently working on a protocol for adding new design systems, which will support integrations at different levels, from component libraries like Chakra to more complete design systems like Airbnb's DLS. We'll have more to share on this soon!
1. The way I've been thinking about it now is similar to how I use autolayout in Figma. Simple x/y is convenient for a very first rough draft. Then I'll refine my design by making components and adding autolayout as needed once the project grows or I want to collab with somebody. Similarly, Noya will support putting components in "stacks" and other layouts (some of the built-in components do this already) that translate cleanly to e.g. flexbox. The hump is definitely there, but I think we can make it relatively pain-free. Since code export is configurable on a per-design-system basis, a company can also adjust the code/config export to match what they do in production.
2. We'd definitely be open to it, but it might be difficult/impossible to make it a good UX. We render actual React components from a company's component library in the browser DOM, whereas Figma renders shapes on a webgl canvas. It might be possible to mix and match with Figma widgets in some way, but would probably be janky. Could still be worth trying though!
By guiding people down the "happy path" with "guardrails", we may end up in mediocrity land. Additionally, Noya is optimized for solving user/business problems and not visual exploration.
At Airbnb we had a really strong set of design guidelines, patterns, and components that (I think) both looked beautiful AND solved user needs. I think as the tool evolves and companies integrate their own opinionated design systems (vs. just Chakra UI, which is very neutral), the output will start feeling more polished & unique. But perhaps there's more we can do here.
Definitely something we'll need to think through!
It's one user per subscription, though you can have unlimited shares/viewers - what would you want it to be/say?
As the tool grows, we definitely hope it becomes powerful enough for designers to use too.
As for the license, I still need to sort that out. It will very likely all be Apache 2.0, but perhaps dual licensed MIT or something else. Licensing/docs/contribution guidelines/etc are lacking right now, so I don't recommend using the source code for anything yet - but may be interesting to poke around on GitHub.
- I think showing the code in the UI makes sense!
- We definitely want to allow theme customization. I'm not sure exactly what that'll look like, but right now it feels pretty limiting without it. I think primary/secondary could make sense as a place to start.
Since Noya is web-based, there's a lot of options to avoid getting completely stuck, though some things are certainly more difficult than others.