Thanks! Agreed, the protocol for both input/output is super important and our top priority right now. It's also the thing we're most excited about from a technical perspective, since we haven't seen anything quite like what we're doing before.
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.
Definitely! We have a first draft of a protocol for integrating any components/theme into Noya, but it still needs a little more work. Once it's ready, we (or anybody else) can add Bootstrap as a supported design system.
Right now it's not very good since that hasn't been a focus for us yet - but both David and I worked on fairly advanced design tools for accessibility while at Airbnb, so we have a lot of ideas here!
Right now the individual components are responsive, but the entire design as a whole isn't (i.e. top-level components are absolute positioned). This is definitely an area we want to improve a lot, and allow users to customize what happens at different resolutions.
At the moment, yes, since our MVP is still pretty limited. We have a first draft of a protocol for integrating any components/theme into Noya that should support the use case you're describing. It still needs some more iteration though before we ship it!
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?
We're currently searching unsplash for stock photos. I didn't find anything too weird when I tried that query, but they do sometimes feel random. We want to add multiple image providers, include generative AI-based providers.
Definitely agree on there being a lot of value in the napkin sketch on steroids approach, and that's where we're starting.
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.
Custom theming & design systems are coming! That's what we're focused on building now. We can definitely support a bootstrap-based design system with custom theming in the future.
That's a great point! For simplicity we've been referring to our current "design system" as Chakra, but it's definitely more nuanced than that. We think of a design system as "a library of components and tokens, and rules for how these are used in a design". Our current design system uses Chakra for the component library part of it, while we created the rules for using those components in a design.
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.