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?
Pretty much vanilla, but it depends on the component.
For components that need reactivity and have frequent renders, I use lit-html for rendering on a property setter change.
I mix and match components from different frameworks, I use vaadin-router, but sometimes include lightweight components from other systems too (ionic, shoelace, mwc, etc...).
Mostly though, it's just light-dom vanilla Web components with bootstrap (or similar) for base styles.
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.
