4 ms·

I don't believe there is a major leap to be made. Here's why. There have always been visual editors for the web. As the author suggests, they have relied on ab

by jarrett 13y ago

I don't believe there is a major leap to be made. Here's why. There have always been visual editors for the web. As the author suggests, they have relied on abstractions of the underlying code. For example, the CSS box model (width/height, padding, border, margin) are often abstracted as draggable handles on bounding boxes. Yet these systems suffer from some fundamental limitations: 1. They obscure the underlying implementation, making it harder for designers to understand and fix problems when they inevitably occur. On a related note, the lack of visibility into the code inhibits learning. 2. They lack the power to express more advanced styling rules, such as the following: /* Paragraphs have 20px margin above unless they follow a heading */ p {margin: 20px 0;} h1 + p {margin-top: 0;} /* Don't indent the top-level UL, but indent 20px for each level of nesting */ ul {margin: 0;} ul ul {margin: 0 0 0 20px;} /* Divs that are immediate children of forms get 20px margins, but divs nested within those don't. */ form > div {margin: 20px 0;} Or, if they do have the power to express those rules, they're doing so in one of two ways: Letting you write CSS ad-hoc, or building a complex GUI that maps to those CSS rules. In the former case, you're back to hand-coding. In the latter case, you're using a clunkier proxy for hand-coding. 3. They lack the power to express idiosyncratic JavaScript interactions. They can provide some generic primitives like rollouts. But many, many real-world apps need fine-grained control over interaction. For example, today I built a system of nested lists with sorting, deletion, and insertion to arbitrary depth. It was so idiosyncratic that it couldn't have possibly been made into a generic component in a visual editor. Problems of that nature are fairly common in my work. And no, the idiosyncrasy is not a sign that something's wrong: Different problem domains often call for (slightly) different interfaces. 4. They don't play very well with dynamic websites. If you need forms or for HTML to be generated from a database--both of which are very common needs--you can't express that generically in a visual editor. Expressing that kind of logic is an act of programming. Historically, efforts to abstract programming into a visual process have been disappointing or outright failures. Source code is the only workable way to express a computer program.

callmevlad 13y ago
1. I think a good abstraction should make it clear what the underlying implementation is doing, and Webflow gives you access to the generated code if you need it. Sounds like a leaky abstraction, but aren't they all? ;) 2. Yes, they do now, but they won't always. For example, we're already working on an intuitive implementation of nested selectors. But I agree with you, things like pseudo-elements, complex selectors, etc are harder to move to the UI - but it's not impossible. 3. I agree with you to an extent, but consider this: the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code. There will always be ultra-custom components, but they don't make up the vast majority of web development. 4. See #3 on forms. And I think you'd be surprised by what you can do with content pulled from a database in a UI. We have something in the works, and honestly it has to be seen to be believed.
- jarrett 13y ago
  > Webflow gives you access to the generated code if you need it. So you're assuming that the designer will have to do some hand-coding after all, yes? I agree that it will almost always be necessary. So, how do you ensure that the generated code is pleasant to work with, and not a mess? Historically, that's always been a huge problem in this genre of software. > For example, we're already working on an intuitive implementation of nested selectors...move to the UI It sounds like you intend to build a graphical representation of the concepts that code has traditionally expressed. As I briefly touched on, that ambition has a troubled history. Many attempts[1] have been made, but none has replaced text-based programming in the mainstream. The basic problem is this: Code represented graphically is still code, it still carries with it all the cognitive challenges of code, and now it's in a clunkier format than text. > the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code. Naturally, you can author static content (with limited styling logic) in a visual environment. There have been plenty of apps for that dating back to the early days. Dreamweaver comes to mind. I don't dispute that much. My point is that I don't see room for a dramatic advance beyond the status quo of that genre. And that there are known limitations to the status quo. The only form I see is an email list signup, which points to an external service. Again, that's always been easy with visual editors. It's also easy in code. E.g.: <form action="http://external.service.example.com/" method="post"> <label for="email">Your email:</label> <input type="text" id="email"/> <input type="submit" value="Sign up"/> </form> For someone who has the brains to learn a complex graphical editing tool, the above should not be difficult to learn. For this example--an email signup form--the backend is where everything interesting happens. The backend for an email signup form such as the one above could easily be tens of thousands of lines of code. Or more. So I don't think it's fair to say that a non-coder "built" that email signup form. > And I think you'd be surprised by what you can do with content pulled from a database in a UI. I'm familiar with apps that do that, and I think I know their upper limits. Applications like MS Access have been doing that for years. Those kinds of abstractions have always existed and always will. The problem is that they're limited. Assumptions about the user experience and business logic are baked into the abstractions. Do you foresee a breakthrough on that front? http://en.wikipedia.org/wiki/Visual_programming_language http://en.wikipedia.org/wiki/Visual_programming_language

by jarrett 13y ago

callmevlad 13y ago

1. I think a good abstraction should make it clear what the underlying implementation is doing, and Webflow gives you access to the generated code if you need it. Sounds like a leaky abstraction, but aren't they all? ;) 2. Yes, they do now, but they won't always. For example, we're already working on an intuitive implementation of nested selectors. But I agree with you, things like pseudo-elements, complex selectors, etc are harder to move to the UI - but it's not impossible. 3. I agree with you to an extent, but consider this: the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code. There will always be ultra-custom components, but they don't make up the vast majority of web development. 4. See #3 on forms. And I think you'd be surprised by what you can do with content pulled from a database in a UI. We have something in the works, and honestly it has to be seen to be believed.

jarrett 13y ago
> Webflow gives you access to the generated code if you need it. So you're assuming that the designer will have to do some hand-coding after all, yes? I agree that it will almost always be necessary. So, how do you ensure that the generated code is pleasant to work with, and not a mess? Historically, that's always been a huge problem in this genre of software. > For example, we're already working on an intuitive implementation of nested selectors...move to the UI It sounds like you intend to build a graphical representation of the concepts that code has traditionally expressed. As I briefly touched on, that ambition has a troubled history. Many attempts[1] have been made, but none has replaced text-based programming in the mainstream. The basic problem is this: Code represented graphically is still code, it still carries with it all the cognitive challenges of code, and now it's in a clunkier format than text. > the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code. Naturally, you can author static content (with limited styling logic) in a visual environment. There have been plenty of apps for that dating back to the early days. Dreamweaver comes to mind. I don't dispute that much. My point is that I don't see room for a dramatic advance beyond the status quo of that genre. And that there are known limitations to the status quo. The only form I see is an email list signup, which points to an external service. Again, that's always been easy with visual editors. It's also easy in code. E.g.: <form action="http://external.service.example.com/" method="post"> <label for="email">Your email:</label> <input type="text" id="email"/> <input type="submit" value="Sign up"/> </form> For someone who has the brains to learn a complex graphical editing tool, the above should not be difficult to learn. For this example--an email signup form--the backend is where everything interesting happens. The backend for an email signup form such as the one above could easily be tens of thousands of lines of code. Or more. So I don't think it's fair to say that a non-coder "built" that email signup form. > And I think you'd be surprised by what you can do with content pulled from a database in a UI. I'm familiar with apps that do that, and I think I know their upper limits. Applications like MS Access have been doing that for years. Those kinds of abstractions have always existed and always will. The problem is that they're limited. Assumptions about the user experience and business logic are baked into the abstractions. Do you foresee a breakthrough on that front? http://en.wikipedia.org/wiki/Visual_programming_language http://en.wikipedia.org/wiki/Visual_programming_language