6 ms·

The main problem with these kind of tools is that they sit in a "dead zone" of being too in depth for non-technicals, yet too limiting and inefficient for engin

The main problem with these kind of tools is that they sit in a "dead zone" of being too in depth for non-technicals, yet too limiting and inefficient for engineers to bother with, as they end up injecting a huge bundle on the page just to render a form. How are you solving for that?

toddmorey 2y ago
This... isn't that. Changes made in the visual editor are translated into code and submitted to your project as a GH pull request for review. So from a project / software perspective, it looks and works like a FE engineer committed a code change.
- hoakiet98 2y ago
  > it looks and works like a FE engineer committed a code change. 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.
hoakiet98 2y ago
This is very astute. We went too far in the non-technical route the first time. It was unrealistic to expect a non-technical person to clone or run code locally so it was hard to get to the value point for them. 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.
deleted 2y ago
[deleted]
DrewADesign 2y ago
While that might be true at the moment, this is a (well designed) electron instance (edit: exists? I only saw install instructions for NPM so maybe it just needs built executables? it says it uses electron) away from being a modern replacement for WYSIWYG editors like Dreamweaver. I could see an easy integration to push your page up to a CDN or GH Pages instance. Even without, there are tons of places for moderately technical people to host static websites, and “upload the code and pictures to a server in this folder” is within many more people’s technical grasp now than it was 20 years ago. Most people don’t need all of the scaffolding most modern dynamic websites have. Online SAAS WYSIWYG web authoring tools— wix, squarespace, Wordpress, et al— have been the only practical option for people without front-end dev skills; beyond that, you’re in SSG land which requires a big jump in knowledge for very little gain in utility until you really start getting some dev knowledge, and most people don’t want or need that knowledge. Being able to stand up a site and tweak the code here and there to do something a little different is a great spot to sit in. Hell it’s what got me started on web stuff with my geocities site nearly 30 years ago. 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.
- hoakiet98 2y ago
  > I only saw install instructions for NPM so maybe it just needs built executables 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.
  - DrewADesign 2y ago
    I'm in a rather odd demographic: I've got about a decade of experience as a developer (as a paid full-time dev working on some FOSS projects) but recently switched careers to design. The design and dev mindsets are definitely different. I obviously prefer tweaking things in code, but designing a layout is fundamentally a visual communication task, so working visually is preferable. I've just started working on a new portfolio site and was wondering if I could skip the Figma/whatever wireframe phase and just use a local WYSIWYG tool for a static page. > 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. :-)
nobleach 2y ago
I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. Our current in-house tool is a drag and drop editor that allows slices of content to be stacked. Each of these slices has preprogrammed selectable options for things like colors, sizes, body copy, headlines, etc. We consider this far too limiting. Now I will agree that my use of Webflow had me beating my fist against my desk. I could do the same thing in straight HTML in 15 minutes, that took me an hour or so in Webflow. Much of that was the learning curve; figuring out "the Webflow way". I see a future where we have tons of people who are good at these low-code/no-code tools. Sure I can run circles around them by being able to write all the code by hand. But for most things they'll be "good enough".
- ramesh31 2y ago
  >I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. 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.
  - anakaine 2y ago
    This argument is akin to saying we shouldn’t have hammers because tradespeople will move on to use nail guns once they have experience. 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.

toddmorey 2y ago

This... isn't that. Changes made in the visual editor are translated into code and submitted to your project as a GH pull request for review. So from a project / software perspective, it looks and works like a FE engineer committed a code change.

hoakiet98 2y ago
> it looks and works like a FE engineer committed a code change. 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.

hoakiet98 2y ago

This is very astute. We went too far in the non-technical route the first time. It was unrealistic to expect a non-technical person to clone or run code locally so it was hard to get to the value point for them. 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.

deleted 2y ago

[deleted]

DrewADesign 2y ago

While that might be true at the moment, this is a (well designed) electron instance (edit: exists? I only saw install instructions for NPM so maybe it just needs built executables? it says it uses electron) away from being a modern replacement for WYSIWYG editors like Dreamweaver. I could see an easy integration to push your page up to a CDN or GH Pages instance. Even without, there are tons of places for moderately technical people to host static websites, and “upload the code and pictures to a server in this folder” is within many more people’s technical grasp now than it was 20 years ago. Most people don’t need all of the scaffolding most modern dynamic websites have. Online SAAS WYSIWYG web authoring tools— wix, squarespace, Wordpress, et al— have been the only practical option for people without front-end dev skills; beyond that, you’re in SSG land which requires a big jump in knowledge for very little gain in utility until you really start getting some dev knowledge, and most people don’t want or need that knowledge. Being able to stand up a site and tweak the code here and there to do something a little different is a great spot to sit in. Hell it’s what got me started on web stuff with my geocities site nearly 30 years ago. 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.

hoakiet98 2y ago
> I only saw install instructions for NPM so maybe it just needs built executables 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.
- DrewADesign 2y ago
  I'm in a rather odd demographic: I've got about a decade of experience as a developer (as a paid full-time dev working on some FOSS projects) but recently switched careers to design. The design and dev mindsets are definitely different. I obviously prefer tweaking things in code, but designing a layout is fundamentally a visual communication task, so working visually is preferable. I've just started working on a new portfolio site and was wondering if I could skip the Figma/whatever wireframe phase and just use a local WYSIWYG tool for a static page. > 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. :-)

nobleach 2y ago

I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. Our current in-house tool is a drag and drop editor that allows slices of content to be stacked. Each of these slices has preprogrammed selectable options for things like colors, sizes, body copy, headlines, etc. We consider this far too limiting. Now I will agree that my use of Webflow had me beating my fist against my desk. I could do the same thing in straight HTML in 15 minutes, that took me an hour or so in Webflow. Much of that was the learning curve; figuring out "the Webflow way". I see a future where we have tons of people who are good at these low-code/no-code tools. Sure I can run circles around them by being able to write all the code by hand. But for most things they'll be "good enough".

ramesh31 2y ago
>I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. 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.
- anakaine 2y ago
  This argument is akin to saying we shouldn’t have hammers because tradespeople will move on to use nail guns once they have experience. 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.