Jordan Moore MembershipRSS

Building with Content Choreography

26th April 2012

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:

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

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


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

Web HD

14th April 2012

Remember those “HD Ready” stickers you used to see stuck in the corner of a flat screen TV? Back then retailers thought it was important to tell you that the TV you were about to buy is future-proof (that is to say it would be capable of displaying high resolution imagery when the technology arrives).

I can see the same thing happening with computing, we currently have “retina” displays on mobile devices (including non-Apple products) capable of displaying high resolution graphical content. Where Apple calls something a retina display that can be expected as a given for all their future mobile products, you can bet other companies will follow suit. Another safe bet would be to count on Apple leading the way with retina display laptops and desktops1.

The early adopters of high definition TVs experienced standard definition broadcasts until high definition signals were broadcast to their TV set which then enhanced their experience. The signal we broadcast on the high definition web comes in the form of high resolution images, video and scalable vector graphics, and we already have a lot2 of devices in the wild that are ready to receive this content.

The key to serving high definition web pages to these devices is scalability. Unlike TVs displaying signals in a 16:9 format, we have screen orientation, an infinite canvas, connection speed and a number of other things to work with. We can serve the right layout to the end device using responsive web design and serve the right content using server-side techniques so no device is unfairly expected to download HD content when it is either unnecessary or incapable. The entire experience needs to scale appropriately, upwards and downwards.

We should start making use of this technology. Like the advances in technology that happened around modem speeds during the transition from dial up to broadband. The web benefitted from the speed increase and became a more immersive experience as a result of the media we were capable of showing on it. We pushed the web’s capabilities then and we should do the same now. We have the ability with the high definition web to help create an even richer experience3.

  1. Daring Fireball Linked List: New High-DPI UI Resources in 10.7.3 

  2. Apple Q1 2012 Results With $46.33 Billion In Revenue | 

  3. If you want to put a label to this phase in the web’s life cycle eg “Web 2.0” then “Web HD” has a nice ring to it. 

The web was always responsive

17th March 2012

The web is inherently responsive. It’s in it’s DNA. If you create a structured HTML document with no CSS applied and open it in any browser, you will see it is naturally fluid1 and will fit any window size.

This is why mobile first makes sense to me. Block level elements stack nicely on top of each other and are fluid by default so our code should’t be heavy at this stage. From a styling perspective, at the mobile first stage you are essentially adding colour, type properties and establishing the vertical relationship between objects.

At your breakpoints you are mainly dealing with layout (widths and floats). Jeremy Keith’s approach for serving stylesheets helps here. Jeremy serves a separate stylesheet for mobile which filters through all properties to the layout stylesheet which is only applied when a viewport can handle it. The layout stylesheet shouldn’t be heavy either as it should only contain layout properties.

Realising that the web is naturally responsive encourages your thinking to keep your code light. A lot of the work is already done for you when using a mobile first approach. That was my epiphany, I hope it helps you too.

  1. I owe my epiphany to Chris Armstrong who pointed this out to me during our first responsive design project together. 

Sensors for Responsive Web Design

25th February 2012

You probably heard about a little event in London this week called Responsive Summit - the brainchild of Josh Brewer and my work colleague Chris Armstrong. What started out as an informal chat between the two a week earlier ended up as a bigger discussion between more colleagues including Mark Boulton, Paul McKeever, Dan Mall, Paul Lloyd among others and of course the web community via Twitter.

One of the discussions that particularly interested me was initially mentioned by Mark Boulton before the event even began. He explains the properties of what makes responsive web design:

A simple example of this is your central heating. Mapping central heating to those three:

  1. Sensors: This is your thermostat. It measures the temperature.
  2. Systems: This is the software in your thermostat, or on your boiler, that you can programme.
  3. Actuators: This is the thing that turns your boiler on or off.

This is a responsive design system. Now, looking at web design, let’s try and map Responsive Web Design to it:

  1. Sensors: This is the browser
  2. Systems: This is our CSS — specifically the @media declarations
  3. Actuators: This is our CSS too — specifically what falls within our @media queries

Using @media queries, the browser detects the width. The browser is the thing that is sensing here.

At the moment, all that we can do reliably (well, fairly), and knowably, is use the browser as our single sensor by which to sense. We have one sensor. We need more.

(via A Responsive Experience - The Personal Disquiet of Mark Boulton)

I would add that the browser has a few other sensors along with detecting the viewport width that we can make use of for designing responsively.


We could perhaps use geolocation as a way of detecting movement1. If a person is constantly moving, that’s a pretty clear indicator that they are travelling. We could better shape their experience by responding to their situation at that point in time.

Time of day

You may be aware of Liz Danzico’s lovely Bobulate. During the day you will be served a stylesheet that has dark text on a white background, after sunset you will be served a stylesheet that has light text on a darker background to reduce glare and enhance the reading experience. This is responsive web design - the page shapes the experience for you at that particular point in time.

Reading distance

Reading distance2, for me, is the golden ticket. We don’t have a sensor for this yet. If we could sense how close or how far a reader is from the screen, we could let the content respond appropriately - think reading on a mobile device, sitting stationed at a desktop machine or relaxing and reading the web on a TV from the comfort of your sofa.

Mark Boulton is right, we do need more sensors. Geolocation and time are two small sensors that could help us in little ways to learn a bit more about our reader beyond changing their layout based on their screen size.

We’re capable of so much more.

(via A Responsive Experience - The Personal Disquiet of Mark Boulton)

  1. I am not sure how ethical this is. Although if we are just using it to see if someone is on the move or stationary then I wouldn’t have a problem with it. 

  2. Tim Brown had an excellent quote on this, I can’t find it or recall it word-for-word. I’m sure it’s here somewhere

Our Changing Tools

22nd February 2012

As we adapt our code to adapt to changing contexts so must our process and therefore so must our tools.

Luke Wroblewski mentioned recently on Twitter:

When trying to design in code, I inevitably need to bubble up to Photoshop every now & then.

(via Luke W on Twitter)

This made me think of my own process. Photoshop1 has become an add-on to the design and build process whereas before it was at the core of every design decision and central to the design process itself.

Responsive web design has naturally moved us away from the world of the finite canvas of tools like Photoshop and on to the infinite canvas of the the web. Those I know that design and build responsive layouts no longer use Photoshop as the pixel perfect representation of the site yet to be built and have moved towards designing in the browser instead. We now design in proportions, not pixels2.

So what is the role of a graphics editor in a responsive designer’s toolkit? I can’t answer for everybody, and I’d love to hear your thoughts, but for me the clue is in the name. Photoshop deals with raster graphics like photographs or textures that are otherwise unachievable natively in the browser. I find it ironic that responsive design has changed the role of my tools - they serve a different purpose now, they change, they respond.

  1. I’m using Photoshop as a reference here. I personally use Fireworks. 

  2. Trent Walton does a much better job of putting the mindset of responsive design into words than I can. 

Watch and Learn

15th February 2012

I am a visual learner. I learn best when watching an example, my mind absorbs images and motion better than static words or instructions. One is more visually interesting than the other.

I love watching people passionate about their craft - their traits, techniques and decision making - how they do things. It helps me get better at what I do. It helps shape my approach to my craft.

Ever since I watched A History Of The Title Sequence by Jurjen Versteeg, I was gripped by his attention to detail, the precision and care that he puts into each title painstakingly crafted by his tools. It’s taught me to do the same in my work, with my tools. Although they are different they don’t change how attentive I can be to my work.

Sometimes it’s nice to just take a moment and sit in someone else’s presence and watch them work.

Built to last

8th February 2012

My parents have a table, a really solid table that has played host to thousands of breakfasts, lunches, dinners and homework assignments. It is the centrepiece of the kitchen and still looks fantastic years after we brought it into our home. I wonder if the woodworker who built the table realised what an important part of our family life it would be, it really means something to us. Ever since I watched Wilson Miner’s talk at Build last year1, I can’t stop thinking about making meaningful things that will last.

Perhaps I’m more concerned about leaving behind a legacy. What do we want to be remembered for when we are gone? Architects, artists, sculptors leave behind a physical representation of their work. We are in a lucky position where we can be the makers of experiences and memories.

Wilson didn’t directly talk about revolution, perhaps this is a feeling of internal revolution that I feel, maybe you feel it too, that we are part of something big. We are well accustomed to the fact that the web is in its infancy and that we as developers and designers have more influence on its direction than anyone else through organisations like the W3C. We shape the future of this platform for all who use it.

I can see many parallels between the industrial revolution during the 18th and 19th century and the current state of the web industry. The industrial revolution was a period in time where major advances in machinery and technology changed how the people of the times lived their everyday lives. It sounds very familiar to the progression of the web from it’s introduction to public consciousness in the 90’s, through the web standards movement in the last decade and now it’s coming of age.

A view over London as it thrives during the industrial revolution

As Wilson mentioned in his talk we spend increasingly large amounts of our day looking at screens. The things we make on these screens: the design patterns, decisions and journeys are building the foundation of the web for future generations. One day we will look back and be proud to say “I was part of that”.

  1. I missed the event in person but the video Andy McMillan posted moved me to write this. I heard reports of Wilson moving the room to silence and some people to tears 

Chasing timelessness on the web

17th January 2012

Cameron Koczon wrote a rousing piece for the latest issue of A List Apart today with a lot of useful advice and observations:

We need to think about products over posters and people over page views. We need this to happen at every level: in design schools, in design writing, and in the things we celebrate online and in person. We have a new purpose: elevate design and help change the world. Let’s talk about how to do that.

The web is maturing as a medium. As we move away from the cheap, tacky, disposable designs that accompanied Web 2.0, we enter a phase where quality content is complimented by more considered design. Publications like Method and Craft and The Great Discontent are obvious examples of the shift towards finer content where recently our feed readers were full of sites publishing lists of techniques and plugins.

We strive for timelessness on this medium that is inherently temporary, and I feel that comes naturally as we learn the strengths and weaknesses of the web as a platform and the tools we use. By pushing such boundaries we make better things as a result from our learning. It is no longer deemed acceptable to produce a web product for one device which may be replaced by another device tomorrow.

Just like Jeffery Zeldman led the web standards movement, great thinkers like Ethan Marcotte lead the way for the web’s next phase of making quality things that work where the web works, making things that last.

We get to go make things. Things that nudge the world a little bit in what we hope is the right direction. We get to put a dent in the universe. This is a great job.

~ Wilson Miner

← Newer Articles

About Jordan Moore

Jordan is a web designer passionate about responsive web design and content choreography. He as a penchant for typography having worked previously with the Typecast team.

He writes occasionally for .net Magazine and Smashing Magazine and currently works for Eyekiller in Bangor, Northern Ireland. You can follow him on twitter @jordanmoore

Available for freelance projects in early 2014


By becoming a member you will help support my writing and the growth of this site as well as receive the Transcripts newsletter with interviews from the web's finest makers and Tickertape

Site ambassadors