Tactics for front-end responsive builds
Some thoughts on how to structure the front-end development of responsive websites and applications, from @iamandyjones.
A styleguide demonstrates the design rules attached to our core markup elements including grouping content (paragraphs, lists, quotes etc), text-level semantics (hyperlinks, emphasis etc) and some document sectioning elements (headings etc). More advanced page components and layout patterns will be built upon these foundations. The styleguide should usually be the first step once we have design concepts to go on. Get the styleguide developed and into the browser based on the design (collaborate with other members of the UX team on this early on). Each element included in the styleguide should be standalone and flexible enough to be dropped anywhere throughout the site. If a styleguide has been taken from a previous project for reuse, it's important to strip out anything that's not going to be needed, to tweak & change the HTML markup that goes with it, to add extra bits if required – make it project specific and ensure we know what every line of CSS is doing before moving onto anything else.
This is a page displaying more complex layout components and patterns specific to the project – these often need some extra beef not provided by our styleguide, or it might just be used to demonstrate how a few different elements of the styleguide can be assembled together on the page to form a standalone block. The component library is a perfect place to demonstrate these advanced styles so that all members of the team can quickly reference the styles that already exist.
Patterns & components may include user interface elements like tabs and carousels etc, and anything else that can be considered as a standalone object and likely to be used multiple times throughout the project. Another example is the CSS media object, which can form a base for multiple content templates; a news list being a perfect example. This media object may exist in multiple visual variations throughout the site or application, therefore collecting and showcasing these variations in a pattern library will ensure consistency, avoid code duplication, and aid future development for all team members. Where a particular pattern requires enhanced styling (a different skin) beyond the base component, extend the styles using additional classes as hooks.
Note: Some basic sites may not demand a component library, in which case the styleguide can be extended to provide everything that's needed on its own.
Build it like lego
Together the styleguide and component library form the core style rules and will cater for the display of content on the majority of pages throughout the site. Using these resources non-technical people may be required to assemble pages from these building blocks. Therefore it's crucial that these components are flexible and object-oriented – they shouldn't fall apart if dropped into a position/location on the site that you weren't expecting, nor should they demand a precise type/amount of content. There may of course be some exceptions to this, though as a general rule - the more flexible the better.
Templates and framework
Once the core code is in place and we're happy with its flexibility, we can start to wrap this up inside our page templates/zones. These framework items (header/footer/page zones) are more rigid and structural, and are unlikely to themselves be ported and reused around the site. Therefore it's not necessary to code them up before the styleguide and component library - we know our components are flexible so wrapping them up inside template zones should be straightforward.
The approach so far sets us up for a mobile-first build...
Small screen first
For fresh responsive builds it makes sense to use a mobile first approach. By developing our flexible components first, and then applying template layouts and zones, we make sure our content modules won't break when viewed within different viewports and when used within different grid systems. The template layouts and grids can be wrapped up inside media queries that only kick in when they are needed. Doing it this way means smaller screens only apply the styles they need to, then larger screens apply the additional styles as and when required, there is no "undoing of styles" as such.
There is plenty more we need to consider:
- When best to apply enhanced (larger screen?) styles.
- Using media queries to adjust framework styles – e.g. moving from a small screen toggle menu to full width navigation bar, not the other way around.
- Using media queries to tweak core styles, we know our components are flexible, but some edge cases will still need tweaking as the viewport changes.
- How will we cater for desktop browsers that don't support media queries – mobile first means they will get a mobile view if support for media queries isn't rounded/patched.
- Do we want to make use of any conditional loading to optimise which assets and content modules are served to smaller screen/lesser capable devices?
There's no right or wrong with all this, but this general approach has been working well...