is the design of kevin kennedy

Visual Code

The design world is aflutter with the announcement of a brand new version of Creative Cloud from Adobe.

What is clear from their announcements is that they are moving quickly and aggressively towards the modern web. Features like being able to export assets more easily and including CSS properties in text styling will have an immediate impact on a lot of design workflows.

They are also continuing to polish their line of Edge branded products. These are smaller, more focused applications that typically handle one or two tasks that we used to do in code, visually.

My workflow today is very firmly split between the stages of visual exploration and code-based execution, and Adobe seems to be trying to combine these experiences.

In the print world, design and production are regularly combined into a single program. We work for hours on layout, color and typography, and then export a packaged, compressed, flattened version of our work as a PDF. There is no in-between step of hand-coding Postscript or re-creating our work with optimized assets, just design and then export.

On the web, we are starting to see similar thinking in the world of preprocessing. We used to code our CSS and Javascript directly, but over the years, as patterns become more apparent and browsers become more advanced, we started coding in languages built on top of CSS and Javascript. These languages give us a lot of convenience and power, and then with a single command, get exported as standard CSS and Javascript.

We decided as a community that it is more important to have a convenient and readable coding environment than it is to have complete control over the final output.

From my perspective, there isn’t much of a mental leap from that to how we might interact with a purely visual editor that outputs a pile of code at the end. In general, I think Adobe is on the right track there.

The early days of WYSIWYG were rough, and probably left a lot of scars in the minds of web developers. Coding a website requires knowledge of document flow and how boxes interact with that flow. That knowledge can be hard to replicate in a visual workspace. There’s a big difference between an object that is floated to the left and one that is aligned to the left, but visually they might look identical.

I also feel that there can be a lot of benefits to keeping these workflows separate. The web got to where it is today because early on we pushed it with our graphics programs, and then later experimented with ways to get that same look in our browser.

Spending more time in a design program to polish a finished product doesn’t sound terrible to me, but there is one crucial area where my print metaphor breaks down, and that is the speed of innovation. Print is a very mature medium, and it also has very defined physical and experiential limits. The web is a wild west by comparison, with a sea of developers constantly challenging and pushing the platform forward.

Visual design tools that attempt to output interactive code will always be limited by the widgets or modules that the developer chooses to implement in them. Code, on the other hand, is limitless in what it can achieve or show to the user.

The attempt to bridge complete visual freedom with complete code-based freedom may result in a solution that only gives us the worst of both worlds, a constrained creative environment with limited customization options.

I have hope that a program can bridge this divide, I just don’t think I’ve seen it yet.