Posted on:
No Photoshop

Responsive Web Design brought innovation in the way the web is built. As many other developers, we needed to find a sustainable process to build websites.
In the second part of UI Farm’s series on our Responsive Framework, we’ll explain the process we found best suitable for our design and development needs.

Traditional Web Design Workflow

  1. Mockup design (sketching, wireframing)
  2. Several static image designs
  3. Client asks for changes
  4. New static designs (various iterations between 3 and 4)
  5. Development implementation
  6. Preview
  7. Client asks for further changes, as the browser renders things differently
  8. Final deployment

Then came Responsive Web Design

Photoshop No More

We’ve all used tools like Adobe Fireworks or Photoshop to design websites. Both of them don’t fit with a modern workflow that involves responsive web design.

As we’re focused on running a website on every device, emulating a devices behaviour along with the look and feel and user interaction, this becomes very hard and time consuming with static image files.
As a result, our workflow differs from that of a traditional web agency.

What Does UI Farm Use, Then?

Graphic elements can be done with different tools. We decided to be software agnostic — as long as we can share and work on the same files — without being particularly attached to any of them.

An helpful application should allow us to:

  1. Work mostly with vectors
  2. Create layers automatically
  3. Easily group/manage/mask objects
  4. Copy CSS code natively from the canvas, without “export for web”
  5. Handle and export multiple images or sets in a few clicks

Currently, the application having the listed features is Sketch. This tool is very handy for mockups as well.

Copy CSS attributes

Fig.1 — Copy CSS Attributes directly from Sketch

Paste CSS in a code editor

/* Rectangle 1: */
border-radius: 8px;
background-image: -o-linear-gradient(-90deg, #FFD152 0%, #FF6207 100%);
background-image: -moz-linear-gradient(-90deg, #FFD152 0%, #FF6207 100%);
background-image: -webkit-linear-gradient(-90deg, #FFD152 0%, #FF6207 100%);
background-image: -ms-linear-gradient(-90deg, #FFD152 0%, #FF6207 100%);
background-image: linear-gradient(-180deg, #FFD152 0%, #FF6207 100%);

Since When Designers Need to Handle Code?

Let’s face it, the web designer role is changing. UI/UX designers and front-end developers need to become more hybrid, with less separation between roles.

At UI Farm we all know how to:

  • Evaluate User Experience
  • Design and code
  • Involve each other with state-of-the-art techniques
  • Build a style guide for both design and code
  • Produce (and update) technical documentation

A New Process: Designing in the Browser

Content First

Content defines both design and development of a website:

Content precedes design. Design in the absence of content is not design, it’s decoration.
Jeffrey Zeldman

We don’t use faux content or placeholders, because we need real content as a starting point for creating the whole responsive workflow, and also determining the major breakpoints.

Once the content is defined, we start sketching the most significant pages and elements of the website, and then jump into designing directly in a web standard browser.

Step 1: Wireframes

All our projects start with our responsive framework, in particular a high-level layer of it, which is unstyled and has a number of rules, calculations and a fully semantic fluid grid. This helps to speed up the process of wireframe design in the browser.

We build a child skin on top of the framework, starting to properly structure the wireframe with a mobile-first perspective. At this stage we don’t mind about colours or any other effect or design element.

Our fully responsive HTML wireframes provide multiple huge benefits:

  1. Our clients can see the wireframes via a URL, so they can test the prototype using any device, on any supported browser to see the full user interaction (also, no multiple static files to keep track of)
  2. Starting from the very beginning we write real code, we won’t refactor anything later
  3. Focusing on progressive enhancement, cross-browser capabilities and validations from the start, we treat performance as a design thing
  4. Changes are a lot quicker than changing static image files
  5. Potential design pitfalls can be identified up-front
  6. Colours are real
  7. Typography is real

This stage is a true collaborative effort until the client is happy with the page. A copy of the HTML responsive wireframes are deployed to a specific URL, with different version releases to keep track of them.

Tools of the Trade: The Browser

From the start, we use:

  • HTML5
  • CSS3
  • JavaScript
  • Browser’s development tools (i.e. Firebug)
  • Plugins to test and debug

Tools of the Trade: SASS and Compass

UI Farm doesn’t write plain CSS. Pre-processors allow us to set variables, mixins and functions that makes easiest and quickest to achieve good results. With SASS and Compass it’s easy to change global colours, effects, states of objects in a fraction of the time.

Tools of the Trade: Responsive Semantic Fluid Grid

As stated in our previous post, at the highest level of our framework we define a responsive fluid grid. We don’t inject any redundant div in the markup or multiple classes in the CSS to define columns. We set one main mixin, relying on several global variables, to dynamically calculate fluid columns:

// columns
@mixin colspan($n:1) {
    width: ($col-w * $n) + ($gutter-w * ($n - 1));
    @if $n == $cols {
        margin-right: 0;
    } @else {
        margin-right: $gutter-w;
    }
}
@mixin col($n:1) {
    float: left;
    @include colspan($n);
}

Then we assign columns-width to any markup elements in the page:

aside[role="complementary"] {
    @include col(3);
}

As columns are calculated with percentage proportions, we can handle dimensions through media query and change layout without altering markup or stylesheets.

Step 2: Full Design

At this stage, the structure and main functionality of the website are done. We can now focus on the look and feel of our pages.

Tools of the Trade: CSS3

CSS3 offers plenty of fancy effects such as:

  • Shadows
  • Gradients
  • Transitions
  • Animations
  • Rotations

Where CSS3 is not enough, or is not fully supported, a bit of JavaScript is on the rescue, if needed. We support graceful degradation for older browsers: since we use feature detection, we try to address missing functionalities and act against them, instead of serving multiple redundant browser-specific “hacks”.

When particular graphical elements are needed, we use the graphic tools of our choice.

Tools of the Trade: SVG

Scalable Vector Graphics (SVG) is an XML-based file format for describing two-dimensional vector graphics. Like vector formats, it builds images using maths and geometry rather than a grid of pixels.
SVG is perfect when it comes to Retina displays and responsive design: it scales without distortion while maintaining small file sizes.

SVG files are human readable. That means they can be opened with a code editor and changes can be done on the fly (i.e. colour changes).

There are few different ways to handle SVG files. So far, the best tool we used is Pavol Rusnak’s SVG Edit (hosted on Google Code). Files exported by this tool are highly readable and lighter.

The SVG format is supported by every browser except IE 8 and down and Android 2.3 and down. We’ll need to provide a replacement file (PNG, JPEG, GIF) to allow our vector image to be visible on older browsers.

Modernizr can help: it will add a class upon page load to thetag called ‘svg’ if the browser supports it or a class ‘no-svg’ if it doesn’t.

Step 3: Deployment

As we are now designing directly into the browser we already have the final HTML5 responsive templates, thus no further development is needed and we can deploy into production.

We believe there’s a nice side effect of this new workflow: it addresses one of the most spread myth about responsive design.

Responsive design costs more than a traditional one.

For both short and long term, this is deeply untrue.

What’s Next?

Stay tuned for the next part in the series on our Responsive Framework:

  1. Performance
  2. Design in the browser
  3. On-demand content
  4. UI Farm’s Responsive Workflow

Get in contact.