Grids, Frameworks and designing in the browser

It seems like a long time since 960.gs was released. A time when every designer and his dog were foaming at the mouth with excitement over the idea of grid based web design.

I was guilty of such behaviour myself, although BluePrint was my grid of choice. A year ago you’d find me creating mockups in Fireworks or Photoshop based on a templated grid which I’d created to replicate the BluePrint grid system. 24 semi opaque 30 pixel columns.

I feel like I’ve come a long way since then. I no longer use Fireworks for my visuals (in fact, I now use very little imagery in my design work at all) instead choosing to design in the browser. I do this for several reasons (many of which are explained well elsewhere) a couple of which I’d like to share now.

Less CSS

Web design traditionally begins in an image editing application like Photoshop or Fireworks. This is because back in the dark ages, web sites were built using countless nested tables, inline styles and endless font tags. It was far easier to create a design by dragging a few boxes around in Photoshop rather than write all that code.

We’ve come a long way since then and modern methodologies (primarily CSS and standards compliant HTML) means web pages can be put together rapidly. Less CSS makes that process even quicker. The ability to define variables within my stylesheet means that I can genuinely create designs (and change them based on feedback) far quicker than I ever could in Photoshop / Fireworks.

For example I’ve built a CSS grid which is generated entirely from 2 variables in my .less file;- the column width and the gutter width. Changing the column width from 50 to 60 changes the entire grid and updates the design instantly.

Less also allows you to nest CSS classes and create shorthand “mixins” for complex or oft-used styles. It can also minify your stylesheet preparing it for production use as it compiles. All in all it shifts CSS authoring into top gear.

Interactivity

Modern web sites (and apps in particular) are more interactive than ever. The adoption of popular javascript libraries like jQuery has made things possible we could only dream about in the past.

Drop down menus were once regarded as advanced functionality, now they’re pretty much standard practise and are often animated. Demonstrating that animation (and even the dropdown itself) in a flat visual is a tiresome task.

Obviously dropdown menus are an elementary example and there is far more interactivity happening on the majority of web pages today, but the principle is clear to see. Interactivity is not easy to demonstrate in a flat visual.

One of the main things I’ve noticed since I started sending clients fully coded design visuals is their reaction to this interactivity. If you’re not dealing with a web savvy individual, explaining AJAX sliders, tooltips and modal windows via a flat visual can be frustrating for both parties and will often lead to compromise before you even begin coding, simply because you aren’t on the same wavelength.

Sending a fully functional design communicates this better than words will likely ever be able to.

Mobile

John O’Nolan is right when he says the “Mobile web” is not the next big thing but the growing number of mobile visitors to a broad variety of web sites is certainly attracting attention.

The upturn in mobile visitors has certainly been enough to encourage businesses to cater for their mobile users. Whether it’s through “responsive” web design, or by serving a different site entirely, mobile versions of web sites are popping up all over the place. With Amazon reporting over $2bn revenue in mobile transactions the “mobile web” is evolving at a rapid pace.

Interactivity and UX is a particularly important component when designing for mobile devices. All of a sudden there are no hover states (how will my dropdowns work now?!), you have to account for slower networks, a different set of browser capabilities plus unorthodox user habbits.

Again, it makes far more sense to design mobile optimised web sites directly for the platform they will be used on. The client can play around with the prototype in it’s natural environment allowing them to notice things they might otherwise ignore or not deem important.

In closing

So while I still use a grid, it’s one I’ve constructed using Less CSS with widths and gutters set as variables. It’s extremely useful being able to alter the entire structure of a web site by simply changing two numbers.

If the site I’m building is to be optimised for mobile devices I’ll include media queries for each device within which I’ll author a grid specific to those viewports.

The general structure will likely be built on the awesome collection of best practises assembled by Paul Irish in his HTML5 Boiler Plate.

I’ll also include my personal collection Less mixins to streamline my CSS and promote progressive enhancements.

All in all, I’ve come a long way in the last 12 months. I wonder how I’ll be building web sites a further 12 months down the road.

Comments are closed.