3 ms·

You are approaching this from a developer's perspective, which is fine, but you fail to consider other skillsets. For example, if I have a team with designers,

You are approaching this from a developer's perspective, which is fine, but you fail to consider other skillsets. For example, if I have a team with designers, they likely know their way around Sketch and Figma and onboarding them onto something like this wouldn't be too difficult. At this point they can start contributing real, demonstrative code that compiles out of the box. Sure it lacks actual functionality and maybe it's a little rough around the edges, but that's not the point. The point is that I, as one of the few developers on the team (or maybe even the only one) have a greatly reduced workload because now everyone can contribute to building the UI. With frontend out of the way, I can work on backend functionality exclusively and marry the two later on. From the year that I've worked with Flutter, the framework makes it easy to separate those two which further adds to the efficiency gains. Rough edges can be cleaned up relatively easily and the time sunk into cleanup probably adds up to less time than starting from scratch. As a real world example, I have been building a mobile app for my startup since this summer. My girlfriend, who wanted to get into UI/UX design, is learning the ropes with the material widgets and making demo UIs by herself. With a few more weeks of practice, she will be equipped to start building some of the views in my app without further guidance. This takes a huge load off of my shoulders, and it's really where Flutter shines.

latchkey 7y ago
I am thinking from the perspective of a user of a product like this. I personally do both development and design work. Your example does not convince me that it would save time ('probably' isn't enough) or be generally useful enough that a designer could be convinced to drop Sketch for it. As a designer, I want to use Sketch. As a developer, I want a Sketch design over generated code. For sure, it is a neat experiment to create something like this, but time and time again, people always resort back to tools like Sketch. I think this developer would be better off spending their time building out a super epic component widget library than trying to build a visual designer.
- nexuist 7y ago
  >For sure, it is a neat experiment to create something like this, but time and time again, people always resort back to tools like Sketch The difference this time around is that the visual designer language...is the real development language. I've also tried using these visual designers before. They all seemed half assed and had glaring limitations. This one may end up being no exception. But I think, combined with Flutter, there may be something gold here. The key being that this visual editor is really a glorified text editor rather than a glorified art program. Sketch, for example, outputs PNGs at the end of the day. You can't throw those into your app and call it production ready. This "widget maker" outputs dart files. That's real, executable code. If the overhead visual designer is flexible enough, the only walls you may end up hitting are the ones set up by the widget implementations themselves. At that point you'd have to deal with those walls manually anyways, so you haven't lost any time really. One of my fever dreams over the summer was to build a voice controlled Flutter widget builder, such that I could sit in front of my TV and simply transcribe a UI from my head directly into the emulator. OP's project is a good first step towards that goal. Just imagine: "Give me a scaffold with a column layout..." "Add a raised button to this container's body" "Set its color to sky blue" "Show me this widget's properties" "Make this a stateless widget called SpecialButtonBar and have it take three arguments..." Again, it doesn't have to do all of it. But having written code to play with is a much better starting point than having nothing. Flutter's composability means that there aren't many different approaches you or a machine can take to arrive at the same result - you will end up with very similar widget trees which means this is a task ripe for automation.
  - latchkey 7y ago
    > The difference this time around is that the visual designer language...is the real development language. Really? What is this then... https://reactstudio.com/ https://reactstudio.com/ ... (just one of many many examples). > The rest... I admire your ability to dream. =)
  - Const-me 7y ago
    > the visual designer language... is the real development language. Microsoft tried that before. Designers prefer Adobe tools. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/creating-a-ui-by-using-blend-for-visual-studio?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/xaml-tools/cre...
- norbert515 7y ago
  Original Author here, thanks for the feedback. I totally agree with most of the points made. Right now, I wouldn't call it production-ready. It is too complex for non-coders and too trivial for actual developers. I've been working on this for quite a while and I wanted to get something released so I wouldn't keep coding in my basement without feedback. Right now, I'd say this tool is handy for Flutter beginners getting to know the layout system. Addressing the problem regarding this being just a "Klickibunti" application. I feel strongly about having this tool produce actual code a human developer would have written, therefore this could be considered the "groundwork" for future actually useful features. Such features could include a full sketch integration that strongly connects to the actual widgets which work with different screen sizes and gesture behaviors. One big feature which I've been planning for a while is a full 2-way code integration, meaning you'd be able to open up a random Flutter project in the widget-maker, tweak something and proceed with writing code. Again, the points mentioned are very valid and I'm trying my best to build something which doesn't fall into the category of being a "nice idea that just doesn't work".

latchkey 7y ago

I am thinking from the perspective of a user of a product like this. I personally do both development and design work. Your example does not convince me that it would save time ('probably' isn't enough) or be generally useful enough that a designer could be convinced to drop Sketch for it. As a designer, I want to use Sketch. As a developer, I want a Sketch design over generated code. For sure, it is a neat experiment to create something like this, but time and time again, people always resort back to tools like Sketch. I think this developer would be better off spending their time building out a super epic component widget library than trying to build a visual designer.

nexuist 7y ago
>For sure, it is a neat experiment to create something like this, but time and time again, people always resort back to tools like Sketch The difference this time around is that the visual designer language...is the real development language. I've also tried using these visual designers before. They all seemed half assed and had glaring limitations. This one may end up being no exception. But I think, combined with Flutter, there may be something gold here. The key being that this visual editor is really a glorified text editor rather than a glorified art program. Sketch, for example, outputs PNGs at the end of the day. You can't throw those into your app and call it production ready. This "widget maker" outputs dart files. That's real, executable code. If the overhead visual designer is flexible enough, the only walls you may end up hitting are the ones set up by the widget implementations themselves. At that point you'd have to deal with those walls manually anyways, so you haven't lost any time really. One of my fever dreams over the summer was to build a voice controlled Flutter widget builder, such that I could sit in front of my TV and simply transcribe a UI from my head directly into the emulator. OP's project is a good first step towards that goal. Just imagine: "Give me a scaffold with a column layout..." "Add a raised button to this container's body" "Set its color to sky blue" "Show me this widget's properties" "Make this a stateless widget called SpecialButtonBar and have it take three arguments..." Again, it doesn't have to do all of it. But having written code to play with is a much better starting point than having nothing. Flutter's composability means that there aren't many different approaches you or a machine can take to arrive at the same result - you will end up with very similar widget trees which means this is a task ripe for automation.
- latchkey 7y ago
  > The difference this time around is that the visual designer language...is the real development language. Really? What is this then... https://reactstudio.com/ https://reactstudio.com/ ... (just one of many many examples). > The rest... I admire your ability to dream. =)
- Const-me 7y ago
  > the visual designer language... is the real development language. Microsoft tried that before. Designers prefer Adobe tools. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/creating-a-ui-by-using-blend-for-visual-studio?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/xaml-tools/cre...
norbert515 7y ago
Original Author here, thanks for the feedback. I totally agree with most of the points made. Right now, I wouldn't call it production-ready. It is too complex for non-coders and too trivial for actual developers. I've been working on this for quite a while and I wanted to get something released so I wouldn't keep coding in my basement without feedback. Right now, I'd say this tool is handy for Flutter beginners getting to know the layout system. Addressing the problem regarding this being just a "Klickibunti" application. I feel strongly about having this tool produce actual code a human developer would have written, therefore this could be considered the "groundwork" for future actually useful features. Such features could include a full sketch integration that strongly connects to the actual widgets which work with different screen sizes and gesture behaviors. One big feature which I've been planning for a while is a full 2-way code integration, meaning you'd be able to open up a random Flutter project in the widget-maker, tweak something and proceed with writing code. Again, the points mentioned are very valid and I'm trying my best to build something which doesn't fall into the category of being a "nice idea that just doesn't work".