Hence, we're focusing on this being more efficient for the engineer. We're limiting to just injecting clean styling for now which is where I personally spend too much time with UIs.
The initial goal is to shorten the loop between code, save, check the browser, adjust code, repeat... and just give engineers the ability to edit the page directly like you would a Figma prototype.
I think this is a great example of why we need more product people involved with FOSS. Having worked in dev for quite some time before I got into design, I’ve experienced the blind spots inherent to having a purely technical focus. From the dev perspective, user needs often seem straightforward or even intuitive, but that’s heavily skewed by a completely different approach to using and reasoning about software than end users have. Developers are often pessimistic about users that seemingly always fail to grasp something they consider trivial, but developers rarely have to confront the actual complexity of other people’s jobs. Lots of people are smart and can solve problems, even if they don't have a formidable mental model of software development. Tweaking basic HTML/CSS generated by something else is well within their problem-solving capability and doesn’t require much technical know-how.
Sorry for the confusion, this is an Electron app. I just didn't ship an executable with it at the moment.
> I could see an easy integration to push your page up to a CDN or GH Pages instance.
That is certainly in the cards. Though, in my opinion, it becomes more useful to edit complex web application since there are many tools supporting static sites but not many for production web apps.
> user needs often seem straightforward or even intuitive, but that’s heavily skewed by a completely different approach to using and reasoning about software than end users have
I am guilty of this. My long-long term hope is to be able to collaborate better with my product folks where they are able to enact their own intuition in the product instead of having to go through me for every change needed.
While this is easy for a marketing page, it's much more difficult to do in a complex application context.
> there are many tools supporting static sites but not many for production web apps.
The funny thing is that the only true WYSIWYG tool I can find that isn't part of a paid SaaS ecosystem or complete inflexible garbage is Adobe Dreamweaver, which has been dying a slow death for decades. It has a few positive traits-- it makes responsive designs, works with bootstrap 4 and a few CSS libraries which make relatively clean code rather than spinning up the inscrutable spaghetti monsters it did in the aughts, and has a really solid built-in code editor (which I assume is Brackets on the back end) but there are bits of primary functionality that have just been broken for years and clearly not on the docket for an update. I looked at it for a few hours last week and decided it probably wasn't long for this world.
Of course you can't spit without hitting an SSG with hot reloading, and in-editor previews are de rigueur, but none of those offer a visual-first workflow for page design, which is what a professional designer really needs. You can have document-style WYSIWYG editing a la TinyMCE, which is fine for a blog post, but if you want to put together the structure of a page from the ground up, you're still context switching between an editor and a browser window which is an ineffective way for designers to work, even if they have the knowhow.
> While this is easy for a marketing page, it's much more difficult to do in a complex application context.
Sure, and this would have saved me some time in the various complex web apps I've made. But for the technically simpler use cases like my portfolio page, unless you're going to use Squarespace, Wix, Artstation, Webflow, etc etc etc and buy into their ecosystem, there really is no option for people that need reasonable control over the site's design without a code-first approach. Aside from Dreamweaver, I think the only one I could actually locate and install was part of Sea Monkey, and it seems to be an... uh... let's say under-loved part of an already under-loved suite of tools. And while my portfolio or a marketing landing page are technically simpler, the quality of the layout is often significantly more important than it is in a web app. Web apps usually convey factual information, figures, maybe provide tools for modifying things, etc. In a marketing page or a portfolio, what you're trying to communicate-- vibe, flow, visual movement, and other intangibles-- takes much more nuance.
(In fact, when developers see a software interface they think was 'ruined by a designer', it was usually ruined by a project manager or a developer trying to make something 'look designed' by mimicking some simple, elegant design they saw that was totally inappropriate for the application. Then they call someone like me. :-)
Someone above suggested https://bootstrapstudio.io/ which seems to fit the static page use case very well.
> it was usually ruined by a project manager or a developer trying to make something 'look designed' by mimicking some simple, elegant design they saw that was totally inappropriate for the application.
This hits home for me as someone who ruins design to ship faster. I think dev being the gatekeeper for UI can turn out badly when we start cutting corners or inserting our own opinions into the implementation.
I hope giving designers the ability to contribute on the UI side can alleviate this issue.
The problem there (and this is from experience building and supporting such a tool for non-technical users) is that people learn. Anyone who spends enough time in one of these tools will quickly pick up the fundamentals enough to become frustrated with the limitations. Or their engineering team will see the inneficient code being created and take it upon themselves to just implement these things quickly and simply. So you can start leaking the abstraction and allowing custom CSS/HTML, but then you very quickly arrive at a place that is useless for both teams.
There is a place for both. You don’t need to spend much time on here, reddit, or many other forums to find people complaining about the lack of decent middle ground tooling to get started with front end dev.
This is exactly the goal :)
To ramesh31 point, we're trying to be cognizant about not putting bloat into the code as we support things like inserting new components since that is where these types of tools typically converge.