The web and its related disciplines have grown organically. I think it’s safe to say the web is not the domain of just the geeks anymore—we all live here. And those of us who work here should have sophisticated, native tools to do our jobs.
A little over two years ago, I started reflecting on the web as a design medium. Coming from a print design background, most of what I knew about design was still applicable; but the things that weren’t made a huge difference. What came of this was a presentation I gave at a few conferences (the abbreviated 10-minute version of which you can see on Vimeo). The discussions that followed prompted me to look closely at how the creative process—and the tools we use—affect designing for the screen.
The framework for what a page is has changed considerably even in the past few years, though our applications for designing those frameworks are still stuck in the web of yore, and largely dictated by their use for print design. This article focuses on some of the tools we currently have at our disposal, mostly either freely available or from Adobe.
What’s this “design” you speak of?
Design is a multifaceted problem. How something behaves is interdependent on how it looks, sounds, reads, moves, and responds. We can’t separate these from the end result, but we can divide and conquer them during the creative process. Web design is not merely building. It’s not just designing. It’s not only the rest of the myriad disciplines and titles we all align ourselves with, but the culmination of all these things.
One process, or “how I work”
For over a decade, I’ve been designing websites. And I’ve followed nearly the same process for every one of them: once it’s time for visual design to happen, I typically start out in rough form (sketches, grey boxes), then move on to higher fidelity comps in Photoshop. I make these Photoshop comps look as real as possible, and continue to revise them for clients until they sign off on the designs. I make exceptions as needed depending on the problem at hand, but I rarely allow much visual design and layout to happen during coding. This includes painstakingly changing type styles and colors in Photoshop when revisions are needed. I’m experienced enough with making websites that I know what I can push off until coding happens, and how certain things will act when in use. I like spending my time this way because it helps me focus on the story I’m trying to tell with my design.
Our current toolbox
Every option out there has its tradeoffs. These are not intended to be knocks against the goals of these applications; they’re all powerful in their own right. The purpose of this brief audit is to highlight the gaps in the creative process.
Photoshop has high-fidelity design capabilities and image editing, but the type rendering isn’t true-to-browser and it’s lacking in layout capabilities. Each new release feels more bloated and directionless than the last.
Illustrator is great for drawing and working with vectors, but the type and image rendering aren’t true-to-browser and it’s ill suited for anything but the simplest layouts.
InDesign is capable of high-fidelity layouts and has advanced type styling features with stylesheets, but it’s primarily a print application and lacks the language and feel for screen-based designs.
Fireworks showed promise back in the hands of Macromedia, but it has taken a backseat under Adobe. It’s primarily a screen-based design app and is great for prototyping and image optimization, but it lacks true-to-browser type rendering, is flakey performance-wise, and feels neglected among the flagship Adobe products.
Dreamweaver is a hybrid WYSIWYG text editor with true-to-browser type and layout rendering, but it lacks flexible visual design capabilities, image editing, and typographic control.
Browsers are obviously the baseline for type and layout rendering as they are the platforms we’re designing for; but the design production is then transferred to hand coding in text editors. Hand coding isn’t the problem here; it’s the prospect of laying out a page without design production tools that’s difficult for many (myself included).
In recent years, a few indie image editing apps have hit the scene, including Pixelmator and Acorn. These apps, and others like them, are impressive achievements, and a good alternative for certain tasks like image editing. Unfortunately, they aren’t sophisticated enough to compete with the applications above when it comes to web design and layout. And that’s OK—I don’t believe they want to compete in this space; I only mention them for the purpose of discussion.
So what does an app that’s made for web design look like? What are the native and common attributes that keep popping up with every page we design? This is a start for the considerations I find myself making on nearly every design I work on.
Per document grids
Different designs require different grids. Currently, in an app like Photoshop, you are only able to set global grid settings. Meaning, if you want to use different grids for your documents, you need to change these settings each time. Many people I know (myself included) get around this by just drawing out a grid on a separate layer and placing it above all the other layers. The disadvantage of this is not being able to use any sort of snap-to-grid and alignment functions built into the program. Everything either needs to be eyeballed or placed mathematically through a measurement palette. Having this reside at the document level would allow a design’s grid to travel with it and stay intact for repeat uses (especially important when working as part of a team and sharing documents).
Webpages are living, dynamic spaces where the smallest interaction from a visitor can change the scope of an entire site. Menus can emerge and recede, system messages display and require action, page elements move, and the contents shift, all without the need for a page refresh. Because we’re not dealing with a static medium, we need to be able to design for interactions and the shifting landscapes of a webpage. This is probably heading into something akin to object-oriented design, but an application needs to see elements rather than blocks of color or text. Photoshop, Illustrator, and Fireworks have some low-level functionality in this regard, but the need for more dynamic and non-destructive handling is clear.
The Character and Paragraph Style palettes from InDesign are able to globally control type similarly to how we use CSS.
CSS-esque type styling (dynamic styles palette)
This one should come as no surprise. CSS saves loads of time when it comes to global changes to typography. Merely changing a link color or font styling for a headliness in a Photoshop file can be tedious because they aren’t centrally controlled. InDesign offers Character and Paragraph styles, which work like a charm. Something along those lines, but obviously geared a bit more towards CSS functionality, would be key. Additionally, being able to relatively link type styles (“make h2s 200% the base body text size”) would be very powerful.
Fonts are exploding on the web in a big way. The ability to design with external fonts, or be able to use WOFF fonts safely, would help depict our designs better, and allow for quicker changes. Hell, being able to specify a font stack along with your styles—so you could quickly cycle through the visual changes that occur with fallback fonts—would be killer.
Page flow, text wrap, and fluidity
Every element on a webpage has the ability to affect the layout of other elements. We should be able to specify what actions to take (float, clear, wrap, etc.) when that happens. Additionally, a browser window is a fluid canvas; desktop design apps only work with a fixed canvas size, making comping a fluid/flexible design little more than a guess.
Knowledge of current browser interfaces
Using any of the desktop design apps for web design means having a bit of knowledge for the parameters of a browser window and screen sizes. Most of us probably work at what we consider a safe size (right now, likely around a 960px-wide viewing area). An application that can be configured to preview for a given screen size or the sizes of the different browser chromes (not unlike xScope’s “Screens” feature) could be really handy. Especially if the different views of a browser also carry with them the rendering styles, defaults, fonts, and more for the platform and browser version.
Form elements are part of the basic language of the web. I’m tired of taking screenshots of forms in various states just to comp into a page. These things are baked into the OS, and an app should be able to easily allow for their display, not as bitmaps, but as editable objects.
This is a big one, and an area I don’t think I’m as qualified to discuss. Design for mobile devices is a difficult problem; there are so many devices, most with unique software and hardware, and it’s the field with the most amount of movement. Perhaps these requirements would be clearer after some formulation of the above occurred.
Options for the future
Why not design in the browser?
By now you must be saying, “hey moron, just design in a browser!” Well, I half-agree with you. In my article from a few years back about Fireworks I made the case for a new desktop app that could handle some of these functions. With how much things have changed in recent years, I’m more inclined to suggest the way forward probably lies with the help of a browser.
But I don’t think the browser is enough. A web designer jumping into the browser before tackling the creative and messaging problems is akin to an architect hammering pieces of wood together and then measuring afterwards. The imaginative process is cut short by the tools at hand; and it’s that imagination—or spark—at the beginning of a design that lays the path for everything that follows. Without it, you’re at best able to make a website that looks like a website—rather than a design that tells a story in the form of a website.
Can WebKit save us?
I’m asking for something that sits on the fence between all of this. I don’t think any of the current desktop apps or any given browser gets the job done. They all do a pretty good job at a few things, but no single one does well enough to really make it a solid prospect.
So why not build a desktop app for web design around WebKit? I’m not talking about an in-browser AJAX toolkit for dragging elements around and changing fonts, but an actual desktop application built with WebKit as the core to its display. It could have accurate rendering and previews for the way page elements would look, but with some of the WYSIWYG tools desktop design apps have. We wouldn’t just approximate pixels in a flat comp, our CSS would be baked in to the layouts we draw and create on the page. And as Webkit grows, so too could this new app, always taking advantage of the latest and greatest functionality. Just like a browser, it could pull assets from remote servers; and just like a desktop app, it could make use of local processing power and OS-level functionality. This would allow it to effectively combine some of the best of both worlds, with a foot firmly planted in the web.
The advantages would be monumental, allowing a strong creative and explorative process, while seeing how things could react on a live stage. It would fulfill many of the items on my wishlist because these are already part of core browser functionality. We would essentially be designing with live page elements; not a picture of a text field—but a text field you could click into and start typing, and then drag to a different area of the page entirely.
I know I’m generalizing; I’m a designer first and most certainly not a developer, but I’ve been occupying this space and using these tools long enough to have a hunch for what works and what doesn’t. An application like this could change the process of web design considerably. Most importantly, it wouldn’t be a proxy application that we use to simulate the way webpages look—it would already speak the language of the web. It would truly be designing in the browser.