On designing in the browser
Here is an attempt to analyze some of these factors and the trend itself, with a special emphasis on practices that can make designing in the browser a successful endeavor. Firstly, some thoughts about the forces behind the trend:
Agile methods from traditional software development are migrating into the broader web design and UX communities. In Lean Manufacturing (a production and management philosophy that inspired Agile) everything that does not result in a working implementation is waste ("muda"). From this perspective, web pages in the form of static design comps qualify as waste, since the final product will discard everything but code. Designing web pages in a graphic design program becomes akin to writing extensive documentation for a piece of software before attempting to write (at least a part of) the actual program.
The advent of CSS3 and embeddable, custom web typography. With the new and upcoming CSS techniques, one can produce prototypes and final designs matching (at least in certain aspects) what has hitherto been possible with computer graphics programs.
Shifting to the browser as the main design and development environment introduces a number of opportunities and challenges for the financial, workflow, and client communication aspects of a project. The initial rationale behind this shift may well be simply the desire to use a workflow that is rooted in the native medium: if the site will be coded in web technologies eventually, we might as well make these technologies the starting point. A web page is the best environment for designing a web page. Static comps don't have depth (cannot be navigated and interacted with); flexibility (cannot be resized as a browser window); adaptability (to various types of screens: desktop, tablet, mobile); they also make it impossible to tackle cross-browser issues in the development phase. Designing in the browser makes development centered in the native medium, with the benefit of immediate feedback - thus giving more control over the process and the end result.
If employed properly, this approach can also contribute to a healthier project bottom line and a good ROI on development time, for the following reasons (ranging from the more to the less obvious):
Duplication of effort (develop a static comp, then convert it to code) is eliminated.
Designing in the browser is a code-centric approach. With the right tools (like version control) and development practices, this can be turned into an additional advantage. Code, patterns, and frameworks can be extracted and re-used across projects. Theoretically, each project potentially contains some parts or aspects that can be abstracted, extracted, modularized, or just re-used, thus becoming a production asset. Each project is obviously unique, but the ability to grow and utilize modular components, frameworks, and off-the-shelf code across projects is what differentiates the more mature software providers in the market. It's all about streamlining production, faster development, and building of long-term assets.
It forces the designer-developer to focus on site content, structure, and Information Architecture, ahead of the visuals. A web page is just a hyperlinked text document. It doesn't even look like a stripped-down version of the Photoshop control panel, with its myriad opportunities for creative expression. Staring at a blank web page with the intent of evolving it into something meaningful is more kin to writing copy in a text document than to designing an art poster. Thus, text, layout, and navigation come to the forefront; the bare essentials.
The "graphics first" approach to website development makes the assumption that a website is a visual product, first and foremost. On the other hand, focusing on copy, content flow, structure, navigation, general usability, and calls to action forces one to think in terms of cognitive consumption rather than purely aesthetic.
(One might make the argument that it is precisely the objective of good design to marry the cognitive and the visual. I would agree, but that doesn't mean that one does not need to address the aspects listed above separately and preferably as early as possible in the design process. Most websites exist to inform, educate, and then prompt some sort of action, ie they are designed for mental consumption rather than visual enjoyment).
So, with the above in mind and given the promises of increased productivity and decreased production cycles and costs, how do we make designing in the browser "work"? What do we need to know to dive straight in?
(For instance, I have developed a CSS3 / HTML5 framework for this site and other projects. I needed something that would make it easy to quickly design grid-based pages that were friendly to browser window resizing, with the least amount of code. Check it out here - it's open source).
Being good at developing low-tech prototypes is a good skill to have within this minimalist context. It allows one to defer the actual coding up to a point where there is a clear idea of what is being designed and why. Pen and paper sketches, wireframes, and the like help achieve this clarity quickly; it's a fun, creative process and the experimentation may yield some unexpected results than could outlive the scope of the project.
Investment in understanding and practicing Information Architecture is valuable here. Without understanding how the site comes together on a structural level, there's a danger you'll spend time hard-coding things that belong not in the design realm but in the overall Information Architecture / structural realm. For example, when designing a menu you may be guided by aesthetic considerations but then after you've finished something prompts you to discover that pages don't link to each other the way that is optimal; by which time you'll have to re-code it all over again to reflect the optimal navigation. IA is like a blueprint to the house: it must be done and ready before we starting putting bricks into their places.
Where does art direction fit into this? I'm not sure. I'm a developer first, and a designer second. I like to think of art direction as an extra design and semantic wrapping that is put around a web project once all the essentials (IA, copy, layout, typography) have been worked out. However, there will be occasions on which an artistic concept will drive the process. It is entirely possible to create a first-class web product out of a strong, "art-directed" idea and acquiring the said essentials along the way. The framework of in-browser development is non-dogmatic. There just seems to be a few things that constitute good practice - things that work due to the nature of the medium. I hope I've touched upon some of them here.
What are your experiences with in-browser development? I'd be glad to hear your thoughts.