These designs are not new and exciting, quite the opposite.
I'm happy to be proven wrong!
11–20 of 120 posts
These designs are not new and exciting, quite the opposite.
I'm happy to be proven wrong!
FWIW it's not obvious that you can pay monthly on your pricing page, it seems like the only option is $120/year until you scroll down on mobile. Also it doesn't mention how many users can use a subscription?
Thanks for the feedback! I'll take another look at the pricing flow on mobile, I'm sure it could use another UX pass to be more clear. It's one user per subscription, though you can have unlimited shares/viewers - what would you want it to be/say?
The video is pretty slick, however i can't help but be reminded of the other story that hit the HN frontpage earlier today: "The age of average" https://www.alexmurrell.co.uk/articles/the-age-of-average These designs are not new and exciting, quite the opposite. I'm happy to be proven wrong!
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!
Earlier quoted context omitted.
Thanks for the feedback! I'll take another look at the pricing flow on mobile, I'm sure it could use another UX pass to be more clear. It's one user per subscription, though you can have unlimited shares/viewers - what would you want it to be/say?
Probably some kind of "/per user" near the per month part.
1. How are you going to get over the layout logic hump? Converting from elements on an x/y canvas to actually good frontend code (Properly nested dom elements, responsive etc) is really hard. I'm pretty sure it's why no 'design to code' tools are actually used in production.
2. Would you consider making this as a figma plugin, as opposed to a seperate tool?
Super interesting. 1. How are you going to get over the layout logic hump? Converting from elements on an x/y canvas to actually good frontend code (Properly nested dom elements, responsive etc) is really hard. I'm pretty sure it's why no 'design to code' tools are actually used in production. 2. Would you consider making this as a figma plugin, as opposed to a seperate tool?
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!
This looks really interesting. I'd be very interested to see how you guys iterate to accommodate other frameworks or actual design systems. IMO Chakra isn't so much a design system as it is a framework (like Tailwind) - it's an abstraction to make common tasks easier. Would love to see something a little more "ui-kit-agnostic".
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!
Super interesting. 1. How are you going to get over the layout logic hump? Converting from elements on an x/y canvas to actually good frontend code (Properly nested dom elements, responsive etc) is really hard. I'm pretty sure it's why no 'design to code' tools are actually used in production. 2. Would you consider making this as a figma plugin, as opposed to a seperate tool?
These are great questions: 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 d…
What webflow doesn't have to deal with compared to a tool for webapps, is that most websites are just static. Web apps have all this extra code mixed into the frontend for functionality - providers, routers, state management methods, api calls ets, all this extra stuff in your components that isn't just "view". Taking some generated static react and adding functionality is easy. But then coming back to a page 5 months later, and refactoring the design in Noya, and merging that new code with what's actually been built? Kinda tough.
It really depends if code export is a core goal, or more a side effect. There's a lot of value imo in a tool for designers, devs, business owners, whoever at a company to mock up an idea really quickly, with something that looks like their companies actual design system. Like the napkin sketch on steriods - but then still implementing it traditionally.