What does designing in the browser mean?
Putting it all together and designing and presenting in the same medium
The responsive web design workflow fundamentally changes how we work. If you’ve been hearing a lot about this recently, it’s because a shift is happening in how we build websites. By getting a prospective design into code as soon as possible, a lot of gaps are immediately filled and there’s a renewed focus on the end product because you are dealing with something interactive instead of something static.
Designing in browser requires a change in mindset. We’re not designing pages, but systems. We’re designing tiny bootstraps for each site that should cover a kitchen-sink-like range of site elements. The end goal is a theming style guide with well-maintained, reusable code that fills gaps that aren’t accounted for when tackling one page at a time.
In order to effectively design for today and tomorrow’s Web, we must replace outdated design artifacts with real collaboration and communication. —Brad Frost via Development Is Design
Building a flexible process
Agency-life is dependent on comfortably balancing new technologies with creating work that all audiences can consume. Design processes are constantly challenged and creating efficiencies in the process is something we exhaustively tinker with, so we can work productively and focus our efforts on what’s important (site architecture, performance, usability, etc.).
Defining roles and choosing the right tools
Our team is multidisciplinary, our best work is done collaboratively and our team is like-minded but also with significantly different perspectives. This allows us to bounce ideas off each other to come to our best conclusions. When designing in the browser, establishing what people are comfortable with is the best way to get to production-ready code.
A design artifact no longer tells the whole story. Instead of working under the assumption that you will build out a comp at a 960px width screen size, you need to understand the fluidity of the design and how it will look at each different screen size. One of our most recent initiatives has been to standardize the design process in terms of what front-end developers get from visual designers in terms of hand-offs.
For example, once a style tile direction is agreed upon with a client, we get the layout flushed out in a flat, static rough. Yes, there’s still a need for static roughs, the reason is that its the most efficient way for us to get to that next step. We are working in tandem once the next sign-off happens, so we can get visuals into code and the design becomes flexible as soon as possible. A themer will then work with a designer to set our baselines and get the “kitchen sink” style guide in place. The upside we have a functional starting point to begin architecting the site.
An obligatory shout out to Photoshop: This design approach doesn’t make Photoshop obsolete. What it does do is re-classifies it as a graphic design tool rather than a web design tool. It always has been this, but it’s reliance on building layouts in the past has kind of given it a mistaken identity. Now that we can’t get away with “pixel perfect” layouts that look the same on every screen, laying design elements out directly in the browser is the most efficient and effective route.
Take it apart, steal the parts that you like, and adapt them to your own way of working. — Joni Korpi via So, You’re a Web Designer, right?
Real interaction over endless documentation
Discovery and documentation is a non-negotiable necessity in any project’s life. The quicker we see real life-examples, the quicker we understand breakpoint because real interactions raise more questions than endless documentation. We deliver better results by making something as real as possible.
We can easily iterate and adjust on the fly: Typography and layout are now Sass/CSS tweaks. We store colors, fonts, buttons, form elements and other site baselines in global variables so site-wide changes become consistent and simple. Slightly more advanced components become extends or mixins that are built as reusable bits of code that can be called on as needed throughout a project. Working within the team to establish variables and mixins reenforces their consistent use throughout a project. Making sure something is built semantically (so others working on it can find their way around) and is scalable (so as the site grows, the structure remains in tact) is an integral part of the front-end architecture and something we spend a lot of time focusing on up front.
A website built with form and function (and optimized for everything from a 3" watch to a 21" wide-screen monitor)
The intricacies of a design really need to be communicated and achieved by working together, rather than dictated from a designer to a front-end developer or themer.
Putting a style guide in code is one step we can take to make sure we’re a) speaking the same language and b) making something that elements are consistent throughout the process. Creating a multi-device site that scales across devices requires a lot of gap-filling. Being able to work in the same medium the project will ultimately be seen, fills a lot of those gaps.
New-age web design tools
While you may have been hearing a lot about this recently, and designing in the browser is a term that has been tossed around for a while now, what we’re really doing is merging different skill sets and disciplines into the same product. A lot of the tools that tackle this problem are still very new or in beta, here’s a look at a few:
Macaw
It’s the alternative to Adobe Photoshop that’s built not as a graphic design tool, but as a web design tool. It’s Kickstarter met its $75K fundraising goal in one day. It’s a visual editor that also writes HTML and CSS that’s production-ready. It will be released to the public in January 2014.
http://macaw.co/
Team Sass’ Style Prototoypes
Style guide-driven Yeoman Generator with the aim to design in design in browser, build in browser and sign-off in browser. It’s a ruby gem powered by Sass + Compass, Bower and Grunt that allows you to create style tiles, style guides and color guides. It’s at version 0.6. This stuff is all pretty new.
https://github.com/Team-Sass/Style-Prototypes
