Dependencies Dependency - Design

I make a discerning effort to keep up to date with the latest front end tools and frameworks - I check article aggregators regularly, such as muzli and codrops, get involved in many code discussions, and even find myself delving into the browser development discussions to see what features are coming next.

But when it comes to actual development tools, my efforts to keep up to date are starting to feel like a bit of a waste of time. Partly because there are so many of them, and partly because the problems they aimed to solve are lesser than the ones they cause!

I’m going to split this into two articles though, the first of which being about Design…

This morning, I read an article about the idea of the “Full Stack Designer” - essentially just a title to give to a designer who can also do some development. Its primary point was that designers are developing a greater awareness of code; that there no longer needs to be a separation between Designer and Developer, because the designers can now do the development.

Sadly, the argument wasn’t that the designers can do the development because they are making a greater effort to learn to code, but because there are now tools that can do the code for them. This is true, there are loads of these tools, Macaw and Webflow are two among them.

The principle of this is perhaps quite appealing, and I can certainly see the advantages of having visual design tools that do the code for you - cutting out the middle man as it were, thus reducing your costs by not having to hire as many people, and also by speeding up your workflow because designers wouldn’t have to communicate their ideas and intentions to other developers. The idea here is that we can now code the visual way through tools that do it for you.

This is nothing new. Various web hosts have been doing similar things for a while now with drag and drop website builder tools. Webflow and Macaw are obviously far more complex, and don’t limit you to a small set of components within a restricted layout. But many of the problems still remain the same. The main one being that, you don’t really understand what it is that you’re getting.

When you drag a new component onto the page in a WYSIWYG (what-you-see-is-what-you-get) editor, you are indeed seeing what you’re going to get… or rather, you’re seeing what you might get, because it may look different out of the editor, and especially may look different in a different browser, on a different environment, and at a different screen width. And that’s just a simple drag and drop component. Now apply that same concern to a design suite that produces code for you…

In my development life, I spend a lot of time on cross-browser compatibility and device testing. In the world of modern front end development, that’s a very big part of what we do. And that’s the problem. Tools like Webflow and Macaw don’t cater for all the bizarre browser caveats out there, they may not (and likely will not) adhere to a long established development agency’s standards, and if your client demands IE7 (or even IE8) support, then the generated code from tools like that will never be sufficient.

The counter-argument of course is to use these tools as a starting point - a stepping stone to get you past that initial hurdle, which you then test, refine, and adjust. But that means altering something where it may not be immediately obvious what the impact might be.

When a bug is raised on a site that your developers have worked on from the very beginning, in many cases, they can identify what the problem might be just by the description. Or at least have a firm idea of where to start looking. With generated code from design tools, that really doesn’t apply. So perhaps the question here is, do you want to bang out a quick website that you don’t understand the workings of, or produce something maintainable that your entire team can be proud of?

Developing this tool dependency to become “full stack” is risking becoming a jack of all trades, and a master of none. I suppose my point is, the more dependent you become on your tools to take over part of the process for you, the more of your potential client base you’ll ultimately exclude.

All of these modern tools are built with very modern principles in mind, for modern designers who use modern techniques. And while there will always be a place for that, as long as there’s a corporate client base out there that still demands support for older browsers, these tools will never supersede high quality Front End Developers.


Posted: July 16th, 2015
Categories: web, design, code