4 ms·

>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 t

>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...
wruza 7y ago
That’s called “interface builder” and it falls short at edge (or just non-trivial) cases in all frameworks ever created. Qt, gtk, whatever-tk, any windows, mac, phone ui. If it’s different this time, then I would like to see that authors know about the shortcomings and problems that usually arise. E.g. restructuring of a container set without losing inner constraints; injecting two subitems where one was without resizing arounds; temporary places outside of main template; viewing full hierarchy with artifical borders to select an interested level; having auto-dummies in boxes to prevent a new subitem to fill all space, making it easy to reason on half-done design. I could go on. But all introduction videos just show us how they drop an item into an empty vbox. Thanks, but yawn.
- jcelerier 7y ago
  > That’s called “interface builder” and it falls short at edge (or just non-trivial) cases in all frameworks ever created. Qt, gtk, whatever-tk, any windows, mac, phone ui. That's interesting, I've used those a fair amount of time generally with success for e.g. config UIs, etc. e.g. look at the amount of Qt-based UI dialog merely on github : https://github.com/search?q=extension%3Aui+language%3AXML+QDialog&type=Code https://github.com/search?q=extension%3Aui+language%3AXML+QD...
chrisweekly 7y ago
Good points. These same challenges abound in other similar contexts [eg Storybook vs Sketch / Figma plugins for React component design and dev... or way way back in the day (late 1990s), WYSIWYG HTML editors (Dreamweaver was amazingly good at balancing usable generated markup with decent GUI controls, esp. compared to M$ FrontPage)... The designer:developer handoff remains a tricky challenge. The best solution (tho hardest to reach) is to find that rarest of breeds: the FE engineer w/ strong design skills or highly technical designer, one person who can competently design and prototype and code, all in the target paradigm. At the other extreme (sadly common, even in late 2019) is the chasm represented by a non-technical visual designer producing pixel-perfect [ie, print-oriented] mockups and layouts in Photoshop, paired with the web developer who's tasked with translating these raster inputs into responsive, interactive experiences. So few organizations are equipped to bridge that gap with anything like the requisite skillsets, workflows and tools. Bret Victor brilliantly highlighted this problem (the lack of immediate connection for a creator between their tools and their creations) -- and a stunning demonstration of what solutions could look like -- in his remarkable presentation way back in 2012. Absolutely required viewing for the uninitiated. https://hacks.mozilla.org/2012/04/bret-victors-inventing-on-principle-and-a-few-things-it-inspired/ https://hacks.mozilla.org/2012/04/bret-victors-inventing-on-...

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...

wruza 7y ago

That’s called “interface builder” and it falls short at edge (or just non-trivial) cases in all frameworks ever created. Qt, gtk, whatever-tk, any windows, mac, phone ui. If it’s different this time, then I would like to see that authors know about the shortcomings and problems that usually arise. E.g. restructuring of a container set without losing inner constraints; injecting two subitems where one was without resizing arounds; temporary places outside of main template; viewing full hierarchy with artifical borders to select an interested level; having auto-dummies in boxes to prevent a new subitem to fill all space, making it easy to reason on half-done design. I could go on. But all introduction videos just show us how they drop an item into an empty vbox. Thanks, but yawn.

jcelerier 7y ago
> That’s called “interface builder” and it falls short at edge (or just non-trivial) cases in all frameworks ever created. Qt, gtk, whatever-tk, any windows, mac, phone ui. That's interesting, I've used those a fair amount of time generally with success for e.g. config UIs, etc. e.g. look at the amount of Qt-based UI dialog merely on github : https://github.com/search?q=extension%3Aui+language%3AXML+QDialog&type=Code https://github.com/search?q=extension%3Aui+language%3AXML+QD...

chrisweekly 7y ago

Good points. These same challenges abound in other similar contexts [eg Storybook vs Sketch / Figma plugins for React component design and dev... or way way back in the day (late 1990s), WYSIWYG HTML editors (Dreamweaver was amazingly good at balancing usable generated markup with decent GUI controls, esp. compared to M$ FrontPage)... The designer:developer handoff remains a tricky challenge. The best solution (tho hardest to reach) is to find that rarest of breeds: the FE engineer w/ strong design skills or highly technical designer, one person who can competently design and prototype and code, all in the target paradigm. At the other extreme (sadly common, even in late 2019) is the chasm represented by a non-technical visual designer producing pixel-perfect [ie, print-oriented] mockups and layouts in Photoshop, paired with the web developer who's tasked with translating these raster inputs into responsive, interactive experiences. So few organizations are equipped to bridge that gap with anything like the requisite skillsets, workflows and tools. Bret Victor brilliantly highlighted this problem (the lack of immediate connection for a creator between their tools and their creations) -- and a stunning demonstration of what solutions could look like -- in his remarkable presentation way back in 2012. Absolutely required viewing for the uninitiated. https://hacks.mozilla.org/2012/04/bret-victors-inventing-on-principle-and-a-few-things-it-inspired/ https://hacks.mozilla.org/2012/04/bret-victors-inventing-on-...