Widget-Maker – A Flutter UI Builder
widgetmaker.dev
widgetmaker.dev
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.
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.
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.
Really? What is this then... https://reactstudio.com/ ... (just one of many many examples).
> The rest...
I admire your ability to dream. =)
Microsoft tried that before. Designers prefer Adobe tools. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/cre...
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 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...
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-...
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".
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...
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.
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.