Gloople: Responsive Design Review

Following last year’s Passenger Focus case study, today I present the Gloople responsive design review. Gloople is an ecommerce platform with emphasis on social and mobile. We designed and built the website at Browser.

Please bear in mind this is a beta registration launch. The final site, fully optimised, and the ecommerce platform will arive later this year. Sign up for updates.

User experience, accessibility, and performance were at the heart of the design direction behind the new Gloople website. As I wrote earlier this year, responsive design should go beyond simply stacking content vertically on smaller devices.

With Gloople we’ve implemented various design patterns to improve navigation and content discovery. If you saw my off-canvas navigation article on Smashing Magazine, you’ll recognise a similar technique with the registration form (pictured above). CSS transforms & transitions are excellent for animation performance.

On the features page you’ll see an accordion-to-modal pattern.

This was surprisingly simple to implement. My biggest concern was making the modal scrollable should it not fit exactly on screen. Rather than absolutely positioning the modal over the main content, I fixed the main element, thus allowing the modal to sit in the normal document flow — I’ll upload a demo of this technique soon!

Scalable Graphics

You’ll immediately notice the amount of SVG (scalable vector graphics) we’re using on Gloople. The illustrative, flat-colour aesthetic is as much about creating a modern brand as it is about creating a style suitable for the Web — fast loading; high definition.

Small icons in the fixed header are embedded straight into the stylesheet to reduce HTTP requests: background-image: url('data:image/svg+xml;base64,[data]');

Generating CSS with Compass makes this workflow a breeze. When the SVG assets are edited we just rebuild the CSS. No manual encoding.

There are SVG optimisers like SVGO to reduce file size by removing unnecessary meta data, elements, and whitespace (this is on the to-do list). Unfortunately a few browsers have rendering bugs — e.g. Chrome on Android (now fixed) — that result in early rasterisation. You may opt for a 2x resolution PNG if sharp definition is priority right now.

Inline SVG

For the larger feature page illustrations we’re writing SVG directly inline of the HTML (view-source to see what I mean).

In the PHP template this is outputted straight into the rendered HTML. The page source looks something like this:

<div class="feature-image is-svg" data-no-svg="fallback.png">
  <!--[if (gt IE 8)]><!-->
    <svg xmlns="http://www.w3.org/2000/svg" height="200px" width="200px">
      <!--[svg data...]-->
    </svg>
  <!--<![endif]-->
</div>

Conditional comments hide the SVG element from IE<8 to avoid parsing errors. In this scenario I'm using Modernizr’s inline SVG detection to replace with fallback PNG images if required.

In truth, this is not easy to content manage. Two images, raster & vector, need to be art-worked and uploaded. Anyone know a command line tool to create a rasterised version of an SVG image? That would be the preferred deployment step.

Responsive Images

Of course, you can’t deny a website of photography. The big hero images are automatically cropped at three difference dimensions (small, medium, large). I then modified Scott Jehl’s picture element polyfill; rather than simply providing the smallest image as default, I’m using the cookies technique to predict which of the three images is best suited. Rather experimental — I wasn’t planning to ship it — but it actually works quite well.

Media Queries and Sass

For Gloople I decided to switch things up by moving from global breakpoints to a more modular pattern. I found Jake Archibald’s old IE mixin useful. Sass includes are broken down by modular, .e.g. features, pricing, blog. Each of these files has their own set of media queries particular to their content. This makes it so much easier to understand how each modular changes. While you can no longer see an overview of what happens to everything at a particular breakpoint, that’s what the browser is for.

Finally, you may have read my article on height-based queries and viewport units (recognise the early prototype?). I’m employing CSS vertical height units in moderation; they’re very buggy. On iOS devices the height calculations seemed to bear no resemblance to the viewport. I’ve had to disable them on iOS. I think only Chrome on the desktop works well… despite the issues, I believe this aspect of responsive design deserves its primetime.

This was my final project as an employee at Browser. Though I’ve left London to move back up North, I do hope it isn’t the last time I work with those fine folk :)

Thanks to Erik K for the Surface template, and ~slaveoffear for the Nexus 4.