A DevTools for Designers
In 2010, Jeffrey Zeldman wrote “An InDesign for HTML and CSS?”, which explored the idea of a web prototyping tool, accessible and familiar to visual designers, that would output decent code that could be handed off to developers. Eight years later, have we reached that goal, or is it time for a new call to action?
TL:DR; Yes, it’s time for visual design tools in the browser. But read on if you’re interested in why.
A world made by hand: Design before the computer
Visual design’s roots are in handcraft. Cave paintings, petroglyphs, clay sculptures, hieroglyphic alphabets; tapestries, mosaics, paintings, calligraphy; hand-cut type, watercolours, lithography, silkscreen; in all of these, the artist executed their work manually, even down to creating their own art materials. This remained true well into the 19th century age of mechanical reproduction.
The user interface of handcrafting, if you will, is direct manipulation; the physical transformation of materials, the application of pigment to canvas, the placement of type into composing sticks, the pressing of roller to paper.
Computers took decades to evolve into useful, familiar tools for visual designers. Aside from pioneering computer artists who would hand-code their creations for output on oscilloscopes and plotters, it remained a remote and specialist instrument, disconnected from the handcraft tradition.
To design with a computer meant needing to think like a computer, to give the computer the correct commands, in the correct order, and produce the desired output.
Old school
I first learned graphic design by working on my college and university newspapers, in the late 1980s.
At college, we used CompuGraphics phototypesetters to generate body copy and headlines. Body copy was formatted and output from a green-screen EditWriter 7500, using special code keys to mark changes to bold and italic, paragraph breaks, and so on.
Inside the machine, once the story was sent to “print,” a precisely timed strobe light flashed through a spinning disc bearing a photographic negative of the typeface, to expose positive images of each letter of the story onto a strip of photo paper. It was like a typewriter that used light instead of ink.
Developed headlines and stories were run through a waxer to make the back side of the paper sticky, then we’d cut them up with X-Acto knives to lay them out into column grids on galley sheets. Borders and lines were applied by hand with special vinyl tape; if we wanted to use fancy typefaces for a headline or title page, we used an enlarger camera to copy them out of a specimen book.
Every issue was a handcrafted product; we literally touched everything that went onto every page.
GUI deliciousness
Later, we switched to using Aldus PageMaker 1.0 and a laser printer, and in the following years, the entire print industry switched over to digital prepress systems.
Among many technical breakthroughs, the most important innovation that made this transition successful was the graphical user interface. Without it, designers simply wouldn’t have adopted the tools.
If you had learned your craft in the pre-digital era, programs like Illustrator and PageMaker mapped your physical drafting table and galley sheets to the screen.
The toolbox palette, with its clearly understandable Susan Kare-designed icons, replaced your jars of pens, brushes, liner tape, rulers, scissors, knives, and paste pots. Everything in the program was measured in points and picas. It was a superb example of mapping designers’ traditions, and existing mental models, to a brand-new software environment.
Desktop publishing would never have taken off if designers had been asked to do everything in a cryptic, green-screen command-line environment, only able to guess at the results before it came out on paper.
PostScript ensured that what you saw was what you got; and the GUI offered the direct manipulation designers were used to, multiplied with new digital superpowers that let them be faster, more precise, and more flexible.
The computer liberated designers from purely mechanical considerations, to experiment with form, as Neville Brody, April Greiman and others demonstrated in the late 80s and 1990s.
Where’s *our* DevTools?
In 2018, web browsers offer vast potential to interactive designers, as revolutionary as what PostScript and desktop publishing offered for print thirty years ago.
Innovations like Grid, flexbox, gradients, rotation, transforms, clipping modes, CSS Shapes, SVG, blend modes, OpenType and variable type are now used everyday. (And that’s just scratching the surface of 2D layout.)
Decades of work by leaders such as Jen Simmons, Rachel Andrew, Estelle Weyl, Una Kravets, Amelia Bellamy-Royds, Sarah Drasner, Val Head, Rachel Nabors, Lea Verou and many others have brought these features into the mainstream of web development, both as insiders pushing for adoption inside the standards process and with browser makers, and as design evangelists who exhort the possibilities and teach us how to unleash them.
Still, today, the only way to really design for the web, on the web, with precise control, is via markup languages and programming code. Thinking like the machine, to get the machine to do what you want.
In this sense, the potential of browser layout tools is locked away, not just for designers, but for everyone. There’s no GUI direct manipulation; no tools that map the designer’s mental model and handcraft tradition.
There aren’t even any rudimentary sketching tools, which is why our stakeholders and managers turn to PowerPoint to illustrate their ideas.
I’m technical, but not a coder. And I’m not alone.
After a decade in print, I switched to designing for digital in 2001. My work since then has been a mix of interaction design and visual design, with smatterings of usability, information architecture and content strategy as needed.
I use Adobe InDesign to do high-fidelity static mockups. I find it easy to map its box layout model and text style rules to CSS, which in turn makes it easier for me to translate into developer specs.
That’s only possible because I’ve picked up a fair amount of technical knowledge, HTML and CSS along the way. I can even explain Grid and flexbox, after a fashion, and I’ve experimented with using Material Design Lite to do layouts.
I can edit front-end markup; I’m just way faster at drawing rectangles and arranging them into user interfaces. I’m technical, but not a coder.
When you can draw a screen element in a single intuitive gesture — point, click, drag, release — versus having to type hundreds of characters in at least two different documents, the appeal of visual tools is self-evident.
It is often said, glibly, by non-designers, that ‘designers should learn to code,’ which really means designers should learn markup. Which gets no argument from me. It’s sensible. It’s practically a tautology.
I don’t think it means we can, or should, expect designers to become production-level front-end developers.
For instance, I’m part of a team that makes enterprise software, that ships as high-performance native server applications with web interfaces. We have, as you would expect, fairly complex build systems involving code that compiles to JavaScript, Sass, modular components for use with our front-end framework, native code that runs on the server, and so on.
There’s simply no way I could jump in and contribute at that level without going back to school for several years. And by the time I’d be done, I might have to start over again.
In a way, this cultural attitude, as expressed as priorities in browser dev tool features, can be seen as a form of gatekeeping. Insisting on coding as the preferred, if not the only way to design for the web, keeps non-coding users and designers locked out.
Looking at the proliferation of the developer ecosystem over the past few years, it’s evident that tooling that caters to coders’ skillsets and mindsets have flourished, but there’s little to enable designers to contribute using the actual materials of the web, in a way that caters to them.
As an aside: There is also an argument to be made that the ‘designers should learn to code’ maxim is, like many things in the history of computing, an expression of the ongoing co-optation by male programmers of what was originally seen as a feminine job, frontend visual design and styling. But that is another article for another day.
2018: The golden age of prototyping?
To return to Jeffrey Zeldman’s 2010 article, he concluded at that time by saying “no company will ever create the modern-day equivalent of Illustrator and PageMaker” for the web, citing the fact that crafting good code requires “professionalism, wisdom, and experience.”
Four years later, he interviewed Tom Giannattasio from Macaw on the Big Web Show podcast. Zeldman described that brand-new app as “the superhot web design tool of the future.” Macaw has since been acquired by Invision, as the foundation of their forthcoming Studio app.
Until Studio comes out of NDA, I can’t say for sure if it will meet its hype, or designers’ expectations, but it’s not hype to say we are now living in a Golden Age of visual prototyping tools.
The Prototypr blog lists the current state of the field here.
- Sketch (Mac only) is the market leader. Originally conceived as a lightweight alternative to Illustrator, it’s become a powerful tool for screen design, with a large plugin ecosystem including Craft and Zeplin.
- InVision is making a strong play with its forthcoming, cross-platform Studio tool, the product of their aforementioned acquisition of Macaw.
- Tumult Hype Pro is a very powerful visual editor for Mac, aimed less at creating pages and layouts than for animated HTML5 content, but it’s a useful tool for prototyping.
- After a false start with the Muse CC product, Adobe released its Sketch competitor, Adobe XD, intended from the ground up for interaction design; it has some unique, time-saving features like Grid Repeat of objects, the ability to create clickable flows of screens, and so on.
- Webflow is one of the few tools focused on straightforward standards-based web design that outputs HTML and CSS, enabling relatively quick production of responsive layouts.
- Google acqui-hired two startups, RelativeWave and Pixate, to work as part of the Google Design team, but they haven’t yet released a web tool for designers. Web Designer, a tool they acquired from Motorola Mobility, is aimed more at mobile ad creators; it feels very slow and simplistic.
- Other tools are specialized to different use cases and workflows, such as the venerable prototyping tool Axure, the intentionally lo-fi Balsamiq Mockups, the unique vector tools in Figma, and the animation-centric Principle.
All of these visual tools can help teams solidify ideas, explore options, refine flows, create specs, and generate consensus.
But, critically, the majority of them aren’t web-centric. None really integrate with a modern web development workflow, not without converters or plugins anyway; and their output is not websites, but clickable simulations of websites.
They make things much more convenient, compared to older methods of using Photoshop or Illustrator to produce static comps, then export them into another tool so you can add clickable hotspots. Now, you can do it all in a single app.
Still, these prototypes are, inevitably, one-way artifacts that have to be first analyzed by developers, then recreated in code.
Experienced teams know that their designs will inevitably evolve faster on the code side, as developers encounter real-world issues and constraints. Unless you invest hundreds of hours revising your mockups to stay in sync, those changes will likely never make it back in, so they’re effectively disposable after that point.
Tantalizing glimpses
The closest thing on the market to a real visual web design application is Webflow. It provides a live-rendered view that you can interact with, preview responsive viewport sizes, add elements and assets easily, and edit CSS more or less directly by pointing and clicking, via a comprehensive set of contextual sidebar menus and dialogs. It’s really quite nice for what it does, and people do very comprehensive site designs with it.
With a paid plan, you can view and export the code it generates and use custom code via Codemirror embeds, but at the moment there is no full-fledged code editor. (I hear there are many new features coming this year, so stay tuned.) It is less accommodating of “just draw a rectangle and drag it anywhere” design workflows though, but that might change.
Lock-in and proprietary ecosystems
While the web is open, many of these tools are closed.
Teams must standardize on the same application(s) to be able to exchange files and share libraries, workflow tools, UI kits and other resources; in some cases the choice of tool also dictates the platform you run them on. Those are trade-offs teams must consider, and for many, the benefits of proprietary apps outweigh the downside.
But proprietary apps with proprietary file formats reinforce a very old-school design-and-hand-off approach. Even if it gets you consensus faster, does it help your designers work seamlessly with your coders?
I can’t help but think that we deal with these trade-offs only because the market options are so limited. If something like Sketch were out there, but that used native web code, wouldn’t it become instantly popular?
For tools that purport to help design for the web, almost none of these tools can import the native materials of the web: HTML, CSS and JS.
If you have a chosen component library or framework, these tools can’t use them, nor can you paste in snippets or link out to your favourite animation script (as you can in CodePen, which I love to bits). You can only tediously re-create the visual elements by drawing them, one by one, or by relying on someone else’s prebuilt kits and templates.
Design ecosystems like these are like tropical greenhouses with special soil. Your delicate flowers flourish and look beautiful through the windows. But you can’t replant those orchids outside, or give them to another person to use in their garden; and the soil inside won’t support the local heirloom roses from outside.
A wish list for a modern visual web design tool
I was originally inspired to write this article after seeing the new Grid Inspector in Firefox.
It reminded me so strongly of box outlines and grids in InDesign, that it was easy to imagine using a pointer tool to click on content in one grid cell to select it, and drag it to another one, having things snap perfectly, and — bonus — having the code update itself intelligently and automatically.
Firefox also has the beginnings of a drag-and-drop visual editor, with its dev tools controls for absolutely-positioned elements.
From there, it wasn’t too hard to imagine something that would let you do things like:
- Set up a grid in a New Grid dialog box.
- Then simply draw boxes, drag them where needed, have everything snap to the grid.
- Click an object to set its layout and visual properties via familiar tools like object handles, contextual menus and sidebar palettes.
- Draw or drag objects onto others to nest them.
- Type, link, and style text with familiar visual controls; tweak styles from sidebar dialogs, or import style sheets (Sass partials, for instance) to apply them from a Styles palette.
- Naturally, there’d be extensive table creation tools.
- Want to rotate that thing? If it’s rotatable, just click on it, grab it by the rotate handle and turn it.
- Using a CSS library with a .thing-rotator-20 class? Just select the object, then apply the class from a sidebar palette list.
- Draw CSS Shapes with a pen tool, just like clipping paths and shapes in the graphics tools we know and love.
- Switch to a different breakpoint, adjust the design to fit, and it would smartly put that code into a media query for you.
- Prototype interactions and animations with a timeline-based keyframe editor, extending the Animation Inspector, and/or offering a library of common transitions that you could chain together, as in Keynote.
- Create and style form elements and form validation.
- All of this should be equally accessible through keyboard commands and tab-to-select.
Going further:
- Saving, reusing and sharing design elements. Extending the kind of ‘snippets’ function in most code editors to a fuller library of components available to import and drag-and-drop into place; an ‘atomic library’.
- Elements could be everything from simple style rules, to colour palettes, to a flexbox navbar, to a full front-end framework. They could be saved out by themselves, or packaged with dependent styles and JavaScript.
Dev tools ++
If we’re going to have desktop-quality visual design tools, it stands to reason that we’d want to upgrade from a simple inspector to a full-blown, modern code editor with syntax highlighting.
Code changes would be linked directly to the visual editor. Edit the code, see the design update in real time, and vice versa. You could choose to use one, or the other, or both; plus, you’d have the usual browser suite of developer tools at your command. It’d be super useful to quickly sketch something out, then clean it up with better structuring and syntax later.
In a perfect world, this editor could also do useful things like autoprefixing, compile LESS, Sass, and TypeScript, output minified and concatenated files, and serve up the site to other browsers for debugging, making those tasks easier for people who can’t or wouldn’t delve into command-line tool chains. (Desktop apps like CodeKit and Prepros fill these gaps today.)
Moving forward
Better visual web tools are a given, but I expect, as with everything related to the industry, there will be vigorous debate about what tools are valuable, who should create them, who they’re for, and who should be responsible for them.
Should these tools be in the browser?
If visual design functions are seen as a superset of existing dev tools, then it’s a natural step to make the browser itself both a reader and a professionally capable authoring tool.
The advantages to this approach would be tight integration with the rendering engine, and avoiding the issue of proprietary file formats; it could use vanilla HTML, CSS and JS, maybe with some JSON or JSDocs for configuration and for things not well represented in other formats.
If browser-editor makers could agree on an open, interoperable set of standards for things like saved snippets and components, then it eliminates the problems with proprietary or platform-specific tools. You would at least be able to export a set of vanilla files that could be opened in any IDE, and ideally, you could open and edit a project seamlessly in any compatible tool.
I see Mozilla as a potential leader here; they’ve made great strides with Firefox, and their support for the development community is legendary.
Or should these be third-party tools, or extensions of existing tools?
Another approach would be to build visual tools into current IDEs, or conversely, merge IDE functions into existing visual tools, with the trade-off that this might result in proprietary file formats and lock-in.
- Adobe’s experience with Muse CC and Dreamweaver show they have some codebase experience in this area, and they’ve also supported the open-source Brackets project (a code editor based on Electron), so it’s not hard to imagine they would be able to do it; it’s an open question if they would create a tool whose file format wouldn’t be proprietary, or tied into an Adobe CC subscription somehow.
- Microsoft has reinvented itself as a design-led organization; it’d be nice to put the visual back into Visual Studio Code, and it’d be handy to have a tool that would let you test on built-in IE 11 and Edge engines.
- Panic have always had great visual style. Would ‘Visua Studia Coda’ be a stretch?
Addressing potential downsides
Experienced web designers and developers will recognize the challenges presented by a visual tool that also outputs code.
- As Jeffrey Zeldman notably stated, an experienced coder uses their judgment to create well-structured markup. Do we want to guide the novice designer with automation, wizards or templates, so that elements are created semantically, tied to a CSS grid?
- Similarly, will we need linters for best practices, accessibility, and so on?
- Will it reinforce the notion of design as mere styling and decoration? I would hope not. That said, isn’t styling and decoration important to a good user experience? It’s not necessarily the first thing you should be thinking about, but visual designers will want something they can explore with, just as they use their Adobe tools today.
- Would it help visual designers and others avoid learning code? Maybe. I often think that we don’t ask graphic designers to write PostScript in order to render their work; they don’t even think about it. Modern Microsoft Office documents are written in XML, but we don’t ask people to edit them using TextWrangler. If it makes them more productive, and output something that their colleagues can use, that’s a net positive. Motivated designers will want to dive in, and they’ll be able to better visualize the connection between visual changes, stylesheets and markup.
- Would accessible tools mean more well-meaning people are empowered to do terrible things? Possibly. But we said the same thing about desktop publishing. Sturgeon’s Law applies; there will be a lot of GeoCities-level stuff produced by beginners. But broadly, having access to tools means more people will be empowered to learn. I certainly wouldn’t have learned graphic design if I hadn’t been privileged enough to have a secondhand Mac with Adobe software on it, and to be living with my parents and thus have a lot of free time to play and explore.
- Would a browser with this much functionality in it become potentially bloated and buggy? If so, maybe it’s worth splitting off into a Developer Edition or some sort of mega-plugin.
Democratizing web design: A call to action
It is inevitable that a proper, standards-based visual design tool for the web will arrive. The pieces are all there, waiting to be assembled; the only questions are in what form, and for whom, it will be created.
This last point is important. Sure, anyone can learn code to design for the web, but the majority of people don’t, and unless things become easier, they never will. Most people find it easier to just draw, even crudely, using whatever graphical tools are available to them.
Browsers have professional-level visual design and typographic powers built-in, but accessing them is a lot like using that CompuGraphic typesetter from 1977; a DOS-like environment with not one but two text-only formatting languages to learn, plus a text-only scripting language, and the expectation that you must think the way the computer thinks to get good results.
It is notable that seven years after the EditWriter came out, the Macintosh, the GUI, and desktop publishing applications made it obsolete.
Direct manipulation of everything in a GUI environment is, today, as normal as breathing; designers certainly wouldn’t give it up.
Making print design accessible and easy to use had a broad impact on society. Desktop publishing put a printing press within reach of the masses; it unleashed creativity, enabled voices to be amplified, and raised visual literacy. Today, every word processor can do credible layout, and high-resolution printers cost less than even the cheapest smartphone.
Print publishing is not just democratic, it’s ubiquitous. The web’s desktop publishing moment is long overdue.
It’s time for the introduction of visual web design tools
- Preferably available in the browser, to everyone;
- That ordinary people can easily learn to use;
- That help people learn both design and code;
- That experienced designers who understand code can use masterfully;
- That help designers and coders communicate and share;
- That output vanilla code that is publishable and re-usable anywhere.
I’m hoping that moment comes soon. As a technically-inclined non-coder, I’m eager to be able to draw layouts as easily as I do in InDesign, tweak the code as easily as in Visual Studio, and then hand the results over to my colleagues as something other than PNGs.
I’m guessing I’m not alone.
Thanks very much to Rachel Nabors, Micah Godbolt, and Clarissa Peterson for providing feedback and advice on this article.
Correction, April 13: Clarified some of Webflow’s features, which I had mischaracterized; you can export code, and it’s not just for use with their CMS.
Updated June 22, 2018, to remove outdated references and clarify some items.
Postscript
After writing this article, I received tons of interesting feedback (see the Responses, below).
Google’s Paul Bakaus got in touch to tell me about the work the Chrome Dev Tools team were putting in to a feature called Layout Tools, which, unless I’m mistaken, hasn’t made it out of the labs yet.
Mozilla’s Patrick Brosset chimed in to let me know they were also working on visual layout tools:
Webflow’s Vlad Magdalin gave me a peek into their future roadmap:
Other initiatives are coming from projects like Cicerone and Modulz. I’m optimistic that easy-to-use web design tools will be in our hands sooner, rather than later.
