Looking for the right tool
Whether or not to design in the browser is an often debated subject. The latest discussion seems to be prompted, in part, because of the recent Responsive Summit (by the way, if you haven’t done so already, be sure to check out a few recaps of the day).
Mark Boulton just put his thoughts to screen with a post entitled “Responsive Summit: The One Tool”. In it, he makes the case that knowing your materials is more important than using a specific tool. He makes an excellent point when he discusses why he feels comfortable in Photoshop:
Since 1997, I’ve been working almost exclusively on the web. Throughout all of that time, the realisation of what the projects would look like are done in Photoshop. That means, yes, I’ve been using Photoshop in a production environment for fifteen years. Malcolm Gladwell said it takes 10,000 hours, or 10 years of repetitive use, to become an expert in something. I guess that means I’m an expert in creating pictures of websites. Photoshop is like an extension of my mind. To use Photoshop for me is as effortless and almost as fast as a pencil. I get stuff done; quickly.
That point, that the familiarity you have with a tool matters, is an important one to keep in mind. Designing is a creative endeavour. You can’t do it well with tools you aren’t entirely comfortable with.
If we had been designing in the browser since 1997, this would all be a non-issue. Of course it wasn’t possible back then to do so—our tools were too limited. That’s not the point I’m making. The point is that if we had that same level of experience designing in the browser, I suspect no one would debate whether the approach made sense. Designing in the browser lets you get deeply entrenched in the characteristics of the web. Designing in a graphics editor like Photoshop removes you from them.
Those against designing in the browser talk about how working in code is too limiting. Of course the opposite is true as well—working in a graphics editor is too limiting in many ways. You are limited to designing for a specific size at a time. You are limited by not being able to design for interactions. That’s a big one. The web is an interactive medium, not a static one. It has little in common with print and much more in common with software. Graphic editors, for all their powerful tools, aren’t equipped to handle this.
There is room for a better tool here. One that lets you experiment easily, but doesn’t detach you from the constraints and capabilities of the environment you are creating for. Later in his post, Mark continues:
I can’t have happy accidents in a browser when I’m writing specific rules and then watching the results in a browser. There is too much in the feedback loop.
This made me think of a presentation by Bret Victor called “Inventing on Principle”. Not only do I recommend it, I think it should be required viewing.
During the presentation he discusses the need for immediate feedback from our tools:
Creators need an immediate connection to what they create. And what I mean by that is when you’re making something, if you make a change or you make a decision, you need to see the effect of that immediately. There can’t be any delay, and there can’t be anything hidden. Creators have to be able to see what they’re doing.
Specifically, he tackles coding. He demonstrates a tool that lets him instantly see how the changes in his Javascript affect the canvas for which he is creating. This instantaneous feedback provides fertile ground for experimentation, and he demonstrates that over and over in the video. Because of the direct connection between the code and the result, you’re able to start using advanced controls (start around 3:45 into the video, and again around 10:45) to help the process of discovery and experimentation.
This, I think, is where we need to head. We need to be able to create on the web, but we need tools that make it easier for us to experiment. Tools that let us be creative without decoupling us from the very medium we are creating for.
We’re not likely to ever remove a graphic editor completely from our workflow, nor should that be our goal. There is nothing wrong with graphic editors. We simply need to be aware of what they are good at, and where they fall short. Instead, our goal should be to move towards tools and processes that let us capitalize on the interactive nature of the web.
It’s about using the right tool for the right job. I’m not convinced we have the right tool yet.