Widget-Maker – A Flutter UI Builder(widgetmaker.dev)
widgetmaker.dev
Widget-Maker – A Flutter UI Builder
https://www.widgetmaker.dev/
4 comments
I do a lot of flutter development and I never really have understood widget makers like this because they always end up falling flat on edge cases. Does it really speed up development time to drag/drop some boxes around? Doing this is already just a few lines of code in flutter and the hot reload is pretty amazing fast.
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.
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.
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.
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.
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".
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".
>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.
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.
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.
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.
> 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+QD...
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+QD...
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-...
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-...
> 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/cre...
Microsoft tried that before. Designers prefer Adobe tools. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/cre...
> The difference this time around is that the visual designer language...is the real development language.
Really? What is this then... https://reactstudio.com/ ... (just one of many many examples).
> The rest...
I admire your ability to dream. =)
Really? What is this then... https://reactstudio.com/ ... (just one of many many examples).
> The rest...
I admire your ability to dream. =)
How has been your experience with flutter? Are you a native developer? How does it compare?
I'm pretty happy with it. I haven't done any android or ios dev, but I did build an app on the danger hiptop a very long time ago! i've done a huge amount of web front/back for a long time. I picked up Flutter to feel pretty solid on it, on my own, in about 2-3 weeks of effort.
It really depends on the application though. In my case, I wanted both android and ios. Building for both platforms is pretty easy (once you setup all the keys and such).
I also quite like the material-ui components... especially for something greenfield... it is twitter bootstrap... it takes all the questions out for early design so you can focus on features. This is probably my main reason for going with it over react native. i'm also a huge fan of material-ui.com for web stuff... but i think flutter nails a more 'native' experience for mobile.
I also like Dart as a language quite a bit. The flutter_graphql library works well. Integrated with firebase_auth for login. I'm using a qr scanner library that wraps the native stuff. Intellij support is quite good. Being able to hot reload on the device is awesome. No real complaints. =)
pro-tip... one wart is their default state management. use the provider api instead. this should be the default imho.... examples...
https://github.com/FilledStacks/flutter-tutorials/tree/maste...
https://www.filledstacks.com/post/flutter-architecture-my-pr...
https://github.com/rrousselGit/provider
It really depends on the application though. In my case, I wanted both android and ios. Building for both platforms is pretty easy (once you setup all the keys and such).
I also quite like the material-ui components... especially for something greenfield... it is twitter bootstrap... it takes all the questions out for early design so you can focus on features. This is probably my main reason for going with it over react native. i'm also a huge fan of material-ui.com for web stuff... but i think flutter nails a more 'native' experience for mobile.
I also like Dart as a language quite a bit. The flutter_graphql library works well. Integrated with firebase_auth for login. I'm using a qr scanner library that wraps the native stuff. Intellij support is quite good. Being able to hot reload on the device is awesome. No real complaints. =)
pro-tip... one wart is their default state management. use the provider api instead. this should be the default imho.... examples...
https://github.com/FilledStacks/flutter-tutorials/tree/maste...
https://www.filledstacks.com/post/flutter-architecture-my-pr...
https://github.com/rrousselGit/provider
So the end goal is basically Supernova: https://supernova.io/
Remember me on M$ Frontpage... Had to take over a website made with that in ~ 2007.. Ended up in threwinh it away and rebuilding it myself with (relative) clean and maintainable HTML/CSS as it was quite simple, and 95% of it was static anyway.
But I understood Frontpage, my aunt used it to create and deploy a website successfully, with nothing more very than basic computer skills, so it had a valid target group.
This, on the other hand, makes one effectively enter the same information in the same way I'd do when just coding it. It fails both, the limited skill-set user class and the advanced, IMO. And, as Flutter already has really hot-reload, good previews, and allows to do such easy widgets in effectively the same way (just drag and drop replace with writing or copy/paste) or maybe even, as of good IDE integration, in a better way, it may also not be useful for "in-between" skilled user groups.
But seems to fit the "Klickibunti" (german for: UX is second class, it just needs to have fancy-looking, effect+color full graphics, for mouse-only interaction) Windows subgroup of users just fine, so maybe I'm just biased.
But I understood Frontpage, my aunt used it to create and deploy a website successfully, with nothing more very than basic computer skills, so it had a valid target group.
This, on the other hand, makes one effectively enter the same information in the same way I'd do when just coding it. It fails both, the limited skill-set user class and the advanced, IMO. And, as Flutter already has really hot-reload, good previews, and allows to do such easy widgets in effectively the same way (just drag and drop replace with writing or copy/paste) or maybe even, as of good IDE integration, in a better way, it may also not be useful for "in-between" skilled user groups.
But seems to fit the "Klickibunti" (german for: UX is second class, it just needs to have fancy-looking, effect+color full graphics, for mouse-only interaction) Windows subgroup of users just fine, so maybe I'm just biased.
TIL about the word "Klickibunti"! I will now use this in my presentations about awful UI examples! Thanks!
Too bad it's Windows-only, I wanted to try it since I build a flutter app at the moment but it does not run on Wine it seems.
Surprising right? Considering Microsoft themselves understood development tools should be cross platform.
So the Flutter UI Builder is not written in Flutter? Good selling point right there.
That would be great... I'm still waiting until apps like this actually work on android/ios instead of only on laptops. UX I actually like to do in another atmosphere than programming; currently I just sit with an iPad + Pencil on the couch and work it out like that before I go back to the laptop and implement it. It would be nice to go a step further and actually create something I can then export to my laptop.
Author here, the widget maker is actually written in Flutter and it can definitely compile to Linux/ Mac/ Windows/ Android and anything that has a screen.
Flutter Desktop, unfortunately, is still in a very early phase and I had some troubles getting the same experience one all platforms. I'm working on fixing those issues and I will provide a Mac version pretty soon and eventually a Linux and Android build too.
Flutter Desktop, unfortunately, is still in a very early phase and I had some troubles getting the same experience one all platforms. I'm working on fixing those issues and I will provide a Mac version pretty soon and eventually a Linux and Android build too.
What technology can one even choose in the current year to be confined to Windows? UWP?!
Microsoft Visual C++ according to the pdb file in the Windows download, although the flutter_windows.dll (that likely does the rendering) file also contains some Chrome related stuff (not sure if it's just the skia graphics library or more from a cursory glance).
Well it says Mac version coming soon, so may be he's still testing for Mac...