Riding the Webflow

Vlad from Webflow gave a history of programming languages, through the lens of abstraction layers. What does this have to do with responsive web design, he rhetoricals?

How we as coders and designers "talk" to web browsers is basically via languages, of course. And we've had to hack standards and conventions to do what we want to do, and that involves, usually, getting deep into a language like CSS, or JavaScript, or some library you saw once on github.

So Vlad doesn't want to take Photoshop behaviors to web design. He says they looked at framework tools such as Bootstrap or Foundation and tried to distill these ideas into a visual workflow. (This is also the goal of Adobe Edge Reflow and Macaw.)

Interesting idea, to place a layer/wrapper around what you're working with visually. But what looks promising is being able to export both the HTML and CSS (Edge Reflow has a bit of an issue so far with the former) as well-formed text. And you don't have to remember to place classes. Though you can't live-edit code. Yet.

Automatic handling of server-side forms? I'll have to figure out that later. And curious that they're gunning for Axure RP, to "own the entire experience" by allowing in-app interaction design.

After spending a week trying to learn Zurb Foundation, after reviewing basic CSS, this looks promising.

Update after RWD reflection outside of the RDF:

Though Webflow's goals, their awareness of "still need to do", and mission are admirable, there are still some elements of their product, their fee structure, and their philosophy that could make Webflow problematic for many graphic designers, web architects, and interaction designers. 

First is the web-based model. They promise Webflow will be Firefox-compatible soon (for those, like me, who don't want to use Chrome), but it's still a lot of code that has to run in your browser. If you're like me, with a dozen or more tabs that have to be open, you already see your browser chewing up tons of RAM and CPU cycles (here: 2010 MBP w/ hybrid hard drive and 8GB of RAM). Adding the styled UI and app chrome of Webflow into the mix would be a beachball — or worse, a crash — waiting to happen. Not to mention, as an audience member did, that the controls and items in the Webflow UI already are in a small font, and there's currently no way to specify type size apart from zooming in the whole browser content. I'm not sure this works well if you work on a laptop, as I do. 

The web-based model also means Webflow hosts the designs you build (some pay tiers offer a custom, hosted domain, such as yourdesign.webflow.com). Of course this makes it easy to point stakeholders and collaborators to what you're working on, and you can download the CSS and HTML (a great feature, and the code looks relatively clean), but it's not clear how well you'll be able to host the code on your own server and point stylesheets and JavaScript links to Webflow's libraries. This is especially acute if you're dealing with server-side forms.

Currently, you also can't use multiple style sheet links in a Webflow project, as you can with, say, Foundation's standard of offloading custom CSS to app.css. Given that they're still working on creating vital CSS components such as menu bars, this ability would allow users to use Webflow even if the company hasn't yet added a component that user finds vital. 

But overall, it's a promising start. The "grab a component, place it, style it" model for building CSS and responsive designs is a tool I've long wanted, and asked "why can't we just drag to define a box, and the app delivers the code?" As mentioned above, Adobe Edge Reflow, Macaw, and others, are promising to make easier what's becoming increasingly hard work.