Maybe I am a bit of a control freak. When I make something, I want full editorial control over the visuals and the content. And maybe it’s the minimalist in me thinking “if it doesn’t add any value — remove it. Everything else is distraction”. I just can’t bring myself to switch on comments or social sharing buttons on this website — I can’t do it. I’ll start with those shiny little not-quite-visually-similar-enough social buttons that tally up how many times your page has been shared on their networks via their JavaScript generated buttons.

First of all, unless you are The Next Web, Mashable or another web giant attracting heaps of traffic on a daily basis, a social count button isn’t going to do you or your brand any favours. Picture this scenario: you arrive at a random article on this website, you notice social buttons and note that the article has been shared 0 times on Facebook, 1 time on Twitter and 0 on Google Plus. What is your first instinctive thought? Here’s what I think — if I spot the buttons before reading the content and notice that it hasn’t been shared, I immediately doubt the integrity of the author and the trust of the message from the website as a whole. I read a lot of articles on a daily basis and sometimes I’ll gauge the usefulness of article on the recency of the post vs the share count. Yes, it’s shallow, like judging a book by it’s cover although in my defence, there are a lot of “books” to get through, whether intentional or not a social button can read like a review.

I don’t want to tread over any ground that Oliver Reichenstein has already covered in his fantastic Sweep the Sleaze article and follow up (and you should read it next if you haven’t already) so I’ll talk about things from user perceptions rather than usage and mechanics¹. A low button count is damaging. That’s my opinion and you’ll have trouble convincing me otherwise. The low count can be a result of people sharing the article by other means, like using the native sharing options in an operating system like iOS or just through good old fashioned manual sharing by copying and pasting a link into your preferred social network. These methods aren’t going to add anything to the button count, it’ll remain embarrassingly low like a poor review. According to Oliver Reichenstein’s piece around 20% links shared on websites he surveyed were completed via a social button, the other 80% were manual shares. So we can conclude that the ROI is poor.

As I mentioned before, if you are a running high traffic site and you want to use the buttons as some sort of demonstration of popularity, then I guess that’s a viable use case albeit a bit egotistical. I would wager though that the people that use them are passive sharers and wouldn’t add any value to the piece you want them to share and they probably don’t have the influence you would like to spread your message further and to the right people.

Social buttons are tools created by social networks to benefit… social networks. They want to take the conversation off your page and onto their network. I’m fine with that because I made the conscious decision to leave comments off on my website, but just think about that for your project.

Speaking of comments, they can be as damaging and in some cases more damaging than a poor share count. For comments to work right you need to stay out of the user’s way and that means leaving them completely unfiltered and moderating later. Obviously this leaves your site open to trolling — but that’s the nature of the beast, the danger of comment roulette.

Think about it this way — we are publishers. Would the New York Times let someone wander into their offices off the street and write an unsolicited remark at the end of one of their articles? Imagine reading the front page of the New York Times and at the end of a finely written piece you find the words “First!” or “Great article thanks!”. It just looks trashy. Compliments are nice to receive but to publicly display them amongst a list of generic back-pats just doesn’t sit right with me. I don’t need someone to essentially say “Good hustle Moore!” after my content.

By now you have probably guessed my opinion of comment models on the web — it’s not that I think the standard comments model is broken, I just feel like it’s not a one-size-fits-all solution. If I wanted to open up a commenting system for my website, I would potentially do something like this:

1. Write the article (no brainer)
2. Associate a hashtag with the article (or all articles) — a hook that I can look for on social networks
3. Make the effort to find people’s opinions on the piece on social networks (if they use the hashtag, then this is step is easy, if not, so what — just keep looking. Valuable opinions are worth mining for)
4. Revisit the article having gathered opinions and use the insightful thoughts to add value to my original content and credit the necessary people
5. Profit

You might be thinking, that sounds like a lot of work — it is. But take note that while digging for opinions, I’m engaging with my audience, maybe asking them to elaborate on some comments, while building trust and integrity with my work. The beauty of an approach like this is that if something you write is completely wrong or you have missed a crucial point then you can find people that disagree (trolls or otherwise) engage with them and maybe even correct the original article with their views. The important part is you maintain full editorial control, not by altering their comments, but building upon their input and giving credit where it’s due.

People can add value to an article without the article being incorrect, they can elaborate on points which you can add to the end of the piece and improve it. I call it editorial comments.

When talking to clients about this stance on social interactions, I talk about it as part of a larger social media strategy. The old/common approach is a plug-in social media strategy — shiny buttons won’t carry out your social media strategy for you. You need to do that, it requires effort to do it properly. It’s not enough to slap some cheap JavaScript buttons onto your page and mark off the social media box of your project goals. A social button cannot become the voice of your brand, that’s a human’s job.

Recently Vasilis van Gemert authored a very useful article on Smashing Magazine about Logical Breakpoints For Your Responsive Design. The article touches on how it you could theoretically produce different reading lengths and breakpoints for different languages. To support this idea Vasilis introduces an insightful little tool showing how the contrasting word length between different languages influences reading length.

This tool is worth bookmarking if you are designing multi-lingual layouts. You can take it a step further by responding to the user’s language using CSS.

The language of an HTML document is defined by the ‘lang’ attribute in the ‘<html>’ tag at the root of the document. This gives us a hook that we can use in CSS to apply globally to the document.

Imagine a scenario where we had a blog that has a language switcher between English and German. Generally German words are longer than English so we might want to set the reading length on the German version of our article to a slightly wider value.

The CSS might look something like this:

article {
   max-width:33em;
}
:lang(de) article {
  max-width:40em;
}

As soon as the ‘lang’ attribute is changed from the default ‘en’ to ‘de’ (through a mechanism like a language select dropdown) the width of the ‘<article>’ changes to a wider reading length making a (potentially) easier read for our German readers.

You could extend this technique to tweak the rest of the layout to adapt to the changing line-length. The fact that the language attribute is at the root of the document makes for a nice and clean base to apply global rules that respond to different languages.

This hilarious animated gif crafted by Tiago Franco (@Alarka) has probably been viewed by the entire web development community by now. It shows the responsive web designer’s instinctive grabbing of the browser handles whenever they open a new website. We all do it and there’s nothing wrong with that.

It illustrates a real problem in situations where web designers and developers try to design for this eventuality - to dazzle and amaze their industry colleagues while losing sight of the project’s audience. If you are building a website (responsive or otherwise) and your project personas become industry heroes rather than those you painstakingly identified at the beginning of a project then it’s time to worry. The project is in danger of losing sight of it’s original goals, the purpose it set out to serve and the value it was supposed to deliver. I would wager that this mostly happens around the concious incompetence and concious competence stages of the responsive dip.

Don’t get me wrong - I don’t have an issue with testing layouts in this manner for the right reasons, in fact I would strongly recommend stress testing your layout at random viewport widths. Try closing your eyes whilst dragging the browser handles to alter the window width, stop dragging at a random point and then open your eyes again. This removes any transitional¹ hocus-pocus from the changing layout and gives you an idea of the state in which real users will load your product. Real users aren’t going to see changing layouts, the chances are they will see only one layout state².

Don’t lose sight of who you are really building this for.

I had an epiphany recently regarding one of the biggest concerns around adopting a responsive methodology for web projects — workflow.

People have been stating that responsive design projects require a fundamental shift in the web design workflow we have become accustomed to from years of building fixed layouts based on flat images that try to represent a website. I believe the shift is actually relatively small, in fact you might be working this way already.

After a critical evaluation of my previously established workflow, I came to the same conclusion a lot of pundits have already arrived at: flat compositions just don’t work. They are as useful as a photograph of a web page, they don’t represent interactions, the infinite canvas, how typography behaves, and so on. Compositions set an unrealistic goal, a rainbow for web developers to chase to the end of a project with scattered showers of compromise and disappointment along the way.

I realised an additional enlightening thought: the design phase is ethereal throughout the project, an entity that permeates through the different stages of a project lifecycle. It moves, it’s supple, it adapts. Sound familiar? Allow me to walk you through my refined process for responsive projects¹.

Wireframes

When I wireframe I usually iterate from very low fidelity sketches with initial ideas up to a medium fidelity sketch with general layout decisions, content considerations and components to document in a functional specification².

This is where the small changes to my process begin. After annotating my wireframes to correspond with the functional specification I use an additional copy of the wireframes to label typography and modular components with reference numbers. Similar pieces can be labeled with the same colour or other categorisation techniques to help with the next step of the process.

The wireframe begins to resemble a set of instructions for an Airfix kit. Identical pieces of the wireframe that are intended to be reused are given the same reference number. The reference numbers correspond to the next part of the process which may be the biggest change depending on how you work.

Style Guide

The wireframe numbers correspond to components in the live HTML style guide. This is the heart of the design phase. After accounting for all pieces in the wireframe, you will be in a position to construct a complete style guide covering typography and modular components ready for use throughout the website. It serves a similar purpose to the pieces of an Airfix kit.

We are now in the ideal position to design in the browser — there will almost certainly be assets you still need a graphics package to create, I’m not dismissing their effectiveness for quickly testing colour and type combinations altogether either. Photoshop/Fireworks still serves a definitive purpose in my workflow albeit a much less significant role than before — mainly asset generation.

Functional Prototype

This step of the process remains unchanged. Here I build the functionality (not design, not layout) documented in the functional specification. This stage is only complete when all functionality is tested and complete.

Customised Prototype

The wireframes and style guide play a pivotal role in this methodology. They are schematics — instructions for assembling model using pieces from the style guide kit. The typographical components and modules in the HTML style guide are the pieces that you assemble according to the wireframes to build the model. This is where the design in the browser happens.

Using the wireframes as a guide for shaping the layouts in terms of proportions we can then quickly piece together detailed design layouts on top of a fully functional prototype, we can make adjustments to things that don’t work so well and quickly iterate. It’s almost like painting by numbers — it’s that easy.

I wasn’t fully sold on designing in the browser until I tried this approach. By stepping into the browser sooner, you can make more informed design decisions without shooting yourself in the foot down the line. The style guide is key to the success of this approach, the more flexible the pieces are, the better they will fit into the overall model.

In summary, the biggest change is dropping flat compositions as a deliverable — they are a heavy piece of the process that set false expectations. Perhaps they may still be of use internally for quick visualisation purposes, but they are damaging to responsive projects if treated as a deliverable. Wireframes should be given more prominence as a set of instructions that inform both the creation of the style guide as well as informing the shape of the layout when it comes to customising a functional prototype using the style guide. The wireframes should be a conceptual model of the final product, not the definitive model. This process involves greater communication with your clients which is a good thing. The style guide is presented much like Samantha Warren’s Style Tiles with the message that it contains the building blocks of the complete model. Like any process, there is always room for improvement — I would love to hear your thoughts if you have any further ideas or insights from your own process. This works for me, I hope it helps you too.

A stub¹ is the part of a document torn off and kept as a record, it usually resides at the end of documents like cheques, receipts and tickets.

I can’t think of a more apt description of this handy little technique I am about to share with you to show you how I would approach print styles in responsive projects.

Print layouts are limiting. There isn’t much you can do in the sense of advanced layouts, even floats can cause problems. For print it’s a matter of reducing the visual noise, extracting the content and determining useful supplementary information.

Lucky for us if we are developing from a mobile first standpoint we can involve print styles at this level too so that most of our layout resets for the print media type are already taken care for us before horizontal layout occurs.

<link rel="stylesheet" href="css/global.css" media="all">
<link rel="stylesheet" href="css/layout.css" media="all and (min-width: 33.236em)">
<!-- Floats and horizontal layout techniques live within layout.css where there is room, global.css contains all styles apart from horizontal layout and any adjustments for large contexts -->

I’m going to generalize for a moment: mobile first layouts are mostly full-width blocks that contain the full set of styles (minus horizontal layout specific styles like floats and widths) with a harmonious vertical rhythm. When making a print stylesheet, we usually cancel floats, reset widths and hide the unnecessary interactive elements like navigation and video. The floats and widths (generally) aren’t set in our global stylesheet so it makes perfect sense for a print media query to live at this level, so at the bottom of your single column stylesheet, you could have:

/* Print stub */

@media only print {
    header, footer, nav, video, .etc, .and-so-forth {
        display: none;
    }
}

Then you would change how you reference your stylesheets in HTML by changing the media type referencing your CSS file for layouts greater than a single column to this:

<link rel="stylesheet" href="css/global.css" media="all">
<link rel="stylesheet" href="css/layout.css" media="screen and (min-width: 33.236em)">
<!-- changed media="all and.." to media="screen and..." so when printing, the device won't look in layout.css for print styles -->

For more fine grain control over the quality over printed material from your project, you can make use of print media query values to map styles to printers with certain levels of detail:

@media print and (min-resolution: 300dpi) {
    /* Styles for printers with a print resolution greater than 300 dots per inch */
}

Putting your print styles at the bottom of your single column stylesheet means you are only pruning the styles set at a this level before horizontal layouts occur meaning they are will be quicker to produce, easier to maintain and lightweight. Responsive web design has a knack for traversing mediums, lets take advantage of that.

We are accustomed to the phrase “design patterns” which encompasses an established solution to a design problem consisting of purpose, function and appearance. There are lots of libraries cataloging these solutions to help designers and developers make sensible decisions when designing and building a product.

Two years ago Ethan Marcotte introduced Responsive Web Design, which has become the biggest movement on the web since The Web Standards movement. With Responsive Web Design we changed the way we make websites, our tools remain largely the same but our approach is different.

At a component level I believe we are still learning the ropes. A design pattern established for one device may not translate so well for another. It’s easy when designing and building responsively to ignore design pattern functionality problems lost in translation and concentrate solely on layout issues. For example a large multicolumn dropdown built for navigating multiple sections within a site may provide a good user experience on a desktop machine - it may translate poorly on smaller screens and harm the user experience.

Another example would be the lightbox design pattern. The purpose of a lightbox is to display a larger image corresponding to the selected thumbnail version while keeping the user on the same page instead of linking directly to a page showing the full image. Again, there are an abundance of solutions for solving this problem but the vast majority of existing patterns translate poorly to smaller displays. In fact you may argue that a lightbox shouldn’t even exist on small displays, the image may already be displayed at full width, and where do you go from there on a narrow viewport? These are the questions we need to ask ourselves when translating design patterns across devices and viewports.

We should challenge our current arsenal of patterns, ask difficult questions of them - how will this work on a narrow screen? On a huge screen? A TV? A touch screen? For a user with low bandwidth? I try to ask these questions at the wireframing stage so I can quickly test what works and what doesn’t, then refine and iterate. Even with a Mobile First mentality I found that you still need foresight to cover all eventualities - planning, documenting¹ and getting sign-off on your pattern behaviours pays off so you have a reference for testing and controlling project scope.

We are dealing with an entirely different beast in that we are building experiences that users will be touching with their bare hands - there is nothing between them and the interface. We need to ensure our tried and tested design patterns translate appropriately for all scenarios so that we can build a new library of responsive patterns that will assist us in making great things for the web. Don’t be afraid to hack or invent, re-invent and re-invent again.

There are lots of solutions to address the problem of responsive images. The solutions share a similar set of requirements, some meet the majority of the requirements, some don’t and specialise in doing one thing well.

I recently read a framework for discussing responsive images solutions by Jason Grigsby and his first point really hit home with me. Scaling a large image for mobile devices may not produce the desired results every time, content authors should be allowed to specify different images for different contexts.

Most solutions offer this approach including the picture tag proposal. Where this falls short, in my opinion, is that there is still a disconnect between the picture tag breakpoint values and the media query values specified in your CSS. Each time a picture tag is written you need to specify your breakpoints again. In a templating environment you would use variables to take care of this but you will still be setting your breakpoints in different places.

Then I recently read Jeremy Keith’s fantastic Conditional CSS article which helps connect your CSS media queries to JavaScript to perform actions based on breakpoints. The possibilities are endless with this little gem. One of those possibilities is using it for specifying breakpoints for responsive images that are set in our HTML.

Here’s the approach I am proposing:

<img src="mobilefirst.jpg" data-medium="tabletfriendlyversion.jpg" data-large="desktopfriendlyversion.jpg" />

We can store image URLs in data attributes to ensure they aren’t loaded initially, only the original src is loaded. This approach borrows from Josh Emerson’s Responsive-Enhance technique where you load the fastest image you can for mobile and replace on the fly where it’s suitable to do so for the end device. By combining this philosophy with Jeremy Keith’s Conditional CSS, then we have responsive images based on our media queries.

CSS:

@media all and (min-width: 45em) {
body:after {
    content: 'desktop';
    display: none;
}
}

As outlined by Jeremy’s Conditional CSS technique, this sets a string of text we can detect using JavaScript to determine when the media query is active. You would then repeat the above code for your other contexts eg “tablet”, you could extend it for a 2x retina display with the -webkit-device-pixel-ratio media query.

JavaScript:

var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');

if (size == 'desktop') {
        $('img').each(function(index) {
            var large = $(this).data('large');
            $(this).attr('src',large);
            }
}
if (size == tablet') {...

So to recap on the code above, it’s checking that when the desktop media query is active by checking the existence of the content in the “body:after” element, then it swaps the src with the value of the data attribute “data-large”. And of course you would repeat this for the other media queries too. Note I’m using jQuery above, you (the smarter one in this dialogue) could do this without a framework, I’m just proposing an approach. Users without JavaScript enabled get the low resolution, compressed mobile image specified in the img src, I’m fine with this as users without JS are getting a lo-fi version of the web anyway.

So now we have an approach that ticks a few important boxes:

• Breakpoints defined in CSS and only in the CSS
• Images can be whatever the content author specifies (no automatic resizing)
• No bandwidth hit for mobile devices
• No code repetition
• Fallback for users without JS

I would love to hear your thoughts on the approach above and any improvements you can think of.

View demo

Responsive Web Design allows us to change layouts and element appearance based upon the width and/or height of the destination device. It’s the ideal scenario for users, coders and content coordinators alike - same site, same code, same content, just optimised for your experience depending on the display properties of the device you are using.

There can be stumbling blocks along the way to a beautiful unified site that runs perfectly on all platforms, which I’ll not go into as they are well documented (think, responsive images, page weight and so-on). The one that has been teasing me for a while is Content Choreography. Trent Walton wrote a great article on the matter. My key takeaway from his article was that when it comes to the narrow width single column view, content stacking is unavoidable and the approach the majority of us take is to simply stack the page elements in the order they appear in our document order.

What happens when this order isn’t ideal for a narrow single column viewport but it works as we want it to for others? We want to make the most of the confined space and let key content and components flourish, but sometimes our hierarchy of elements can prevent that from happening. Say for example we want to present an article in the narrow single column view, but before the article appears in the stacking order we have: a header (containing site name etc), navigation, maybe even a banner advertisement, then the article. The heart of the page is buried beneath items that may be less important in this context. Rather than brutally hiding these items with a display:none property we can reorder them using another CSS property - flexbox.

The flexible box layout module allows us to do more interesting things than our current box model allows for producing layouts, including the ability to reorder elements. Sounds exactly like what we wanted to do with the article example mentioned earlier, right? The flexbox property box-ordinal-group let’s us reorder elements based on a group number assigned to elements in our CSS. They appear in the order you specify starting from 1. So in our example we would priortise the elements on the page:

• Header (1) - Contains the site name, most important
• Navigation (4) - While a key element, it’s not crucial in our example - we just want to present an article
• Banner advertisement (3) - Important for our advertisers, we are compromising for our example and dropping them below the article
• Article (2) - The second most important thing on the page apart from the site’s name.

When we apply those values to box-ordinal-group for each of the elements, the browser would render them in this order:

• Header (1)
• Article (2)
• Banner advertisement (3)
• Navigation (4)

All this happens with minimal fuss - in your single column media query you apply display:box to the parent container which houses the elements you wish to re-order, assign the box-ordinal-group values according to the order in which you want them to appear, save, refresh and - ah-ha! They appear as if they have been floated horizontally, what happened? Flexbox arranges elements horizontally by default, because we only want to apply this at the single column view (I’ll explain why later), we need to add one more property to the container alongside display:box, and that property is - box-orient:vertical. Now we are working with our familiar stacked block-level elements only this time we have the delicious power to re-order them as we please.

I mentioned briefly that we would only want to do this when our layout is viewed in a single column, allow me to explore this a little further - there are advantages to applying flexbox at a single column level. One is that it is easier to get your head around moving objects up and down rather than horizontally moving and stretching and filling and stacking. Another is that by aiming to do this at a single column media query (I hate associating devices with viewport widths but for the sake of illustrating this point this would be the mobile view) we can enjoy the incredible support for flexbox on mobile devices. In addition it is (arguably) mobile devices that feel the pain of the need to re-arrange elements for optimal presentation in that context. Also if a mobile browser can’t recognise flexbox (IE9 Mobile is the only major one missing from the list so I’m assuming it can’t), then it will simply fallback to the default document order which isn’t the worst outcome.

So unless anybody points out some fundamental flaws in this technique, and please feel free to do so if there are any, then I plan to use this a lot when building responsive sites. I can see it causing some extra foresight when building for mobile first although I don’t think that’s an entirely bad thing, you would essentially build for mobile fallbacks and the larger context’s document order first, then re-order to the ideal choreographed scenario when finished. To be honest, I’m still figuring that part out, the best way to approach this, as with everything else in responsive web design is to build and refine and repeat.

View demo (resize your browser window to see the narrow column reordering) View explanation demo

Update

Thanks to the good work of Stewart Curry and Stuart Robson, this technique has a mixin for your favourite CSS pre-processor:

• Content Choreography LESS mixin by Stu Robson
• Content Choreography SASS mixin by Stewart Curry