3 ms·

I have been waiting what feels like 10 years for a toolkit like this. Just signed up and will dig in more, but initially this is solving a lot of problems for m

I have been waiting what feels like 10 years for a toolkit like this. Just signed up and will dig in more, but initially this is solving a lot of problems for me as an entrepreneur. I manage the product and set the direction, but I don’t touch the actual backend code. Everything else though (design, website, marketing, sales, creative direction, product) falls to me. I think a lot of folks are in this position. -keeping design consistent from wireframe to mock-up to finished product is a challenge. Esp with small, bootstrapped teams without a dedicated design person (let alone department) consistent, professional design is a challenge. This will allow me to mock-up exactly what I want and pass it off to dev in one process. -I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there. None of them actually solve this problem because they can’t generate the actual code. That is a crucial part. -This bridges the gap between having a designer create a design system and deliver mood boards, fonts etc. and actually putting those things into practice technically and consistently. Getting a design made isn’t the problem, there are a million designers out there - actually using it consistently in a way that’s practical is another challenge entirely. Thanks for this product, can’t wait to actually use it more.

dabbott 4y ago
I really appreciate the thoughtful feedback. You described the problem extremely well - I might have to use some of those points when I talk about Noya! Honestly the current version is an MVP and probably won't deliver on the promise just yet. But I'm confident we can make it good enough to fill that gap in tooling. If you get stuck or don't like how things work, feel free to throw feedback at us. We've added/updated a lot of stuff based on what the first few people have suggested already.
phphphphp 4y ago
Noya looks great, so this isn't a criticism of them, that said: > keeping design consistent from wireframe to mock-up to finished product is a challenge [...] this will allow me to mock-up exactly what I want and pass it off to dev in one process [...] I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there. If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Code generation does not replace developers, it's an augmentation at best, and so if you're running into these challenges with your current tooling then you're going to run into them with Noya (or any other tool that does not replace your developers). You should either replace your developers with developers who can deliver to a specification, or change your approach to business (by not building software any more). I'll bet that the problem you've described here is not your only problem with the developers, rather it's one symptom of the problem. Code is the easy part of software engineering, any competent developer can churn out code faster than it can be specified. The hard part of building software is translating a business need into a specification. Prototyping tools (like Figma) are very helpful upstream because they help the business provide a much more robust specification -- if you're building a prototype in Figma of how a user interacts with a page, you won't forget to explain what a specific button does. If you're already doing all of that work to provide developers with a pixel-perfect rendition of what you want, and they're still not delivering it, just giving them a bunch of code instead to represent that design is not going to solve the problem. A helpful model for evaluating the development work of developers is to think of it like construction workers: if a construction worker is given a plan for a square 250 sqft bedroom, and they build a 100 sqft shed instead, and you had clearly communicated that you wanted a 250 sqft bedroom, you would not think the input was the problem. You'd start to question the workers. Just because you can't write code, does not mean you need to allow developers to get away with churning out things that aren't what you've asked for.
- MrJohz 4y ago
  I broadly that this sounds like a people problem rather than a tooling problem, but I would add: >If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Or the problem lies in the designers providing the specification, which is also a situation I've seen a few times. A good design specification isn't just providing a view of the overall layout, it's also providing the pieces that went into that design: the visual components, the guidelines used for layouts, a list of colours and distances used, etc. Simply providing a "pixel perfect" version will not get you good results, because that's essentially a lossy translation of the designer's intent. To implement that intent, you need information then just, for example, how big each button needs to be, you need to know how big a button can be, how small it can shrink to, what should happen with oversized or undersized text, how it will be positioned in its containers etc. Partly that's because intent is often a clearer way to communicate things than results, but mainly it's because there's no such thing as a pixel-perfect render target. Browser sizes can change, phones can be rotated, and people will insist on all sorts of different resolutions. It's only by describing intent (this element should fill the space, this point should be equidistant between these two points, etc) that you can adequately support all these situations. That said, I broadly agree with you that this sounds more like a people problem than a technology problem.
dmitriid 4y ago
> None of them actually solve this problem because they can’t generate the actual code. That is a crucial part. Because there are a million ways to generate that code (if we're talking about the browser), and they will all break when coming into contact with reality. - your sizes are in em/rem, and your root font size is off? Goodbye design - you absolutely need something at the bottom of the screen (think media controls), and you have absolute positioning? Goodbye design for large combinations combination of screen/positioning - you need something centered on, say, third element from the right? And then another element is added on the left? Goodbye design - you need something animated? Goodbye design - etc. etc. etc. However, for some established patterns you might get away with some standard design choices and some generated code
wx196 4y ago
If you are targeting code generation, try Framer.

dabbott 4y ago

I really appreciate the thoughtful feedback. You described the problem extremely well - I might have to use some of those points when I talk about Noya! Honestly the current version is an MVP and probably won't deliver on the promise just yet. But I'm confident we can make it good enough to fill that gap in tooling. If you get stuck or don't like how things work, feel free to throw feedback at us. We've added/updated a lot of stuff based on what the first few people have suggested already.

phphphphp 4y ago

Noya looks great, so this isn't a criticism of them, that said: > keeping design consistent from wireframe to mock-up to finished product is a challenge [...] this will allow me to mock-up exactly what I want and pass it off to dev in one process [...] I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there. If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Code generation does not replace developers, it's an augmentation at best, and so if you're running into these challenges with your current tooling then you're going to run into them with Noya (or any other tool that does not replace your developers). You should either replace your developers with developers who can deliver to a specification, or change your approach to business (by not building software any more). I'll bet that the problem you've described here is not your only problem with the developers, rather it's one symptom of the problem. Code is the easy part of software engineering, any competent developer can churn out code faster than it can be specified. The hard part of building software is translating a business need into a specification. Prototyping tools (like Figma) are very helpful upstream because they help the business provide a much more robust specification -- if you're building a prototype in Figma of how a user interacts with a page, you won't forget to explain what a specific button does. If you're already doing all of that work to provide developers with a pixel-perfect rendition of what you want, and they're still not delivering it, just giving them a bunch of code instead to represent that design is not going to solve the problem. A helpful model for evaluating the development work of developers is to think of it like construction workers: if a construction worker is given a plan for a square 250 sqft bedroom, and they build a 100 sqft shed instead, and you had clearly communicated that you wanted a 250 sqft bedroom, you would not think the input was the problem. You'd start to question the workers. Just because you can't write code, does not mean you need to allow developers to get away with churning out things that aren't what you've asked for.

MrJohz 4y ago
I broadly that this sounds like a people problem rather than a tooling problem, but I would add: >If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Or the problem lies in the designers providing the specification, which is also a situation I've seen a few times. A good design specification isn't just providing a view of the overall layout, it's also providing the pieces that went into that design: the visual components, the guidelines used for layouts, a list of colours and distances used, etc. Simply providing a "pixel perfect" version will not get you good results, because that's essentially a lossy translation of the designer's intent. To implement that intent, you need information then just, for example, how big each button needs to be, you need to know how big a button can be, how small it can shrink to, what should happen with oversized or undersized text, how it will be positioned in its containers etc. Partly that's because intent is often a clearer way to communicate things than results, but mainly it's because there's no such thing as a pixel-perfect render target. Browser sizes can change, phones can be rotated, and people will insist on all sorts of different resolutions. It's only by describing intent (this element should fill the space, this point should be equidistant between these two points, etc) that you can adequately support all these situations. That said, I broadly agree with you that this sounds more like a people problem than a technology problem.

dmitriid 4y ago

> None of them actually solve this problem because they can’t generate the actual code. That is a crucial part. Because there are a million ways to generate that code (if we're talking about the browser), and they will all break when coming into contact with reality. - your sizes are in em/rem, and your root font size is off? Goodbye design - you absolutely need something at the bottom of the screen (think media controls), and you have absolute positioning? Goodbye design for large combinations combination of screen/positioning - you need something centered on, say, third element from the right? And then another element is added on the left? Goodbye design - you need something animated? Goodbye design - etc. etc. etc. However, for some established patterns you might get away with some standard design choices and some generated code

wx196 4y ago

If you are targeting code generation, try Framer.