This post aims to outline the entire project processes and act as an informal case-study for the construction of a large-scale responsive website. The South Tees site contains over 1,000 pages and while Responsive Design is not a new technique, documented examples of client sites on this scale are few and far between. The more we share our experiences, the better our techniques and processes will become as a result.
Planning and scoping
Although not totally related to Responsive Design, it’s good to talk about some of the processes earlier on in the project. These will differ agency to agency, project to project but here is some of what was undertaken:
Kick-off meeting
After we had talked through the client brief/briefing form and begun to establish things like objectives, success criteria and target audiences — it became immediately obvious that the site was going to be very information-heavy.
We made sure to outline the benefits of responsive design to the Trust from the very beginning. Given the subject matter and working with a public sector organisation; the concept of One Web couldn’t have been more pertinent.
I followed this up by creating a responsive prototype to demonstrate a typical navigation pattern. This proved a useful example and luckily the Trust & their Communications department are switched-on technically, so bought into the benefits fairly easily.
Content audit
This was crucial to the project’s success. For a site so vast, starting the content process rolling as early as possible was paramount. The Trust were tasked with analyising every page of their existing site and auditing content under certain headings. Each page was given a score, an action (e.g. keep, remove, move), a priority, a department/division and a content manager.
Above all it made the client recognise just how important a dedication to content is and prompted them to raise their budget and involvement with our proposed CMS training.
UX research
This took the shape of eight 30-minute telephone interviews. To ensure relevance, the participants must have used one of the South Tees hospitals in the past and also visited the existing website. The theory was that quality of research is better than quantity; if you pick the right people, user research/testing doesn’t have to be a long and drawn out process.
The research focused on user’s experiences of the existing site, effectiveness in finding information/completing tasks and their expectations as a whole. Alongside this research we also created a number of user personas which we could reference when making decisions.
Feature-based quoting
We held an ideas workshop and given all the information available (e.g. brief, aims, research) talked in relation to creative and technical requirements. Ideas from this meeting formed a list of features, each given a priority and a time estimate.
Each item was then written onto a card. Starting with the most important, we worked backwards to prioritise the cards and assemble a finalised set of features that lay within the project budget. This became the project’s specification.
I think whether Responsive Design should be included “as standard” and what it costs is totally subjective. Price ultimately is dictated by time — how much you put into the process and how quickly you work will differ for everyone.
Wireframing and design
Whilst the benefits of mobile-first are clear technically, I think the planning and design phases of a project are a little less set in stone. Responsive Design, its tools and processes are still at relative infancy and for the moment I think a variety of different methods can all lead to a successful outcome.
We adopted a very traditional approach to wireframing and design during the project. That is, we created desktop wireframes that led into desktop visual comps. Naturally, direction was informed by the UX research & content audit, and any obvious tripping points relating to smaller screens were considered as we went.
From there we worked backwards to see how the desktop design could be optimised for smaller screens. This part was done almost entirely at the build stage. As opposed to planning from mobile upwards or designing fully in-browser, this method of working (on a responsive site) may be a little less idealistic. But we found it was certainly workable.
Whilst the Trust had bought-in to concept of Responsive Design they were commissioning a primarily desktop website. Given the scoping stages had taken some time, they were keen to see design comps in desktop form as early as possible (and trusted us to take care of the rest). This is a client mindset we will have to work hard to change, I feel. In hindsight we could have presented more of an overall process, as opposed to focusing largely on the technology.
We identified and agreed 15 key pages which were wireframed and then produced into visual comps in Adobe Fireworks. It was these comps that the Trust signed-off against before we started building (with room for any slight changes necessary during the build).
Whilst users finding information was clearly important, some of the site’s other aims & objectives were in relation to launching the Trust’s new brand. During the design, a careful balance had to be struck between user experience and marketing the Trust & their services (as well as adhering to NHS brand guidelines).
Build and technical
It was my role to complete all of the project’s technical work. The initial build stage involved taking each designed page, then turning it into a static HTML/CSS template. I then integrated these into the site’s CMS — WordPress.
While the site was designed desktop down, the build was carried out mobile-first. The whole mobile/content-first concept encompasses more than just how you build, but from a technical point of view the benefits are clearly proven.
Working with the design comps I knew which elements needed to appear on the page and what to aim for in desktop browsers. I started by coding the HTML alone without touching any CSS until I had established the core markup for each page. I find this helps to remind you just how fluid elements are before you’ve even added any CSS, and helps you plan re-ordering in the browser. From here I implemented the styling from the desktop designs with everything pretty much still linearised.
ems for flexibility). These were helped by a peppering of max-widths to accommodate line length and image sizes. I used a combination of setting the desktop layout first then refactoring my CSS for smaller screens, or visa-versa.
Changing of the grid/column structure through the breakpoints led me to an early version of my recently-released proportional grids concept. This uses fixed gutters with proportional columns, and helps you avoid the need for re-defining lots of CSS as screen size increases.
Adopting a more object-orientated approach and creating re-useable elements such as the media object helped me out loads in bringing the build together quickly (that’s a really powerful bit of code!).
I used Sass to compile my CSS (via CodeKit) which was a first for me on a project of this size. It’s no substitute for logical & efficient CSS but I think it’s a great tool and working with mixins helps me code more quickly.
The @import function allows you to separate sections of a stylesheet into manageable chunks which helps when serving old IE. The site needed to be 99% identical in IE7, which the Trust use internally. IE7 and 8 are fully supported and receive a fixed-width, 960px wide layout. If you’re trying to polyfill these older browsers with media queries, you’re doing it wrong!
User context
Although it has been lauded that you should never assume a user’s intentions because they are on a certain device, the research and user personas made us realise that context can be important in some instances. For example, visitors to the site who are travelling to a hospital for an appointment or seeking information during a medical emergency.
These scenarios impacted how I prioritised content during the build. For example, pushing the “Finding a hospital” and “Getting here” (contact info) panels to the top of the page on smaller screens.
Considering content hierarchy across the range of screen sizes inevitably happens on any responsive project, but it was good to have specific context to inform decisions made.
Being constrained by source order (or having to duplicate content) can be one of Responsive Design’s limitations, although developments like flexbox make things slightly easier. Fortunately I was able to accomplish what we wanted using float alone.
Navigation
Much has been written about responsive navigation patterns; in summary, they all have their pros and cons. I opted to use the dropdown menu pattern in the header and footer on small screens.
As per my prototype, I used slightly modified version of Samuel Cotterall’s touchdown.js script to group together the two sets of links in the header. There are four navigation layouts which all give the primary navigation and search equal prominance either stacked, or side-by-side.
display: block added to make them more clickable.
I wouldn’t say it’s ideal having to scroll most of the way down the page to reach sub navigation, but I’m not sure we had a much better option.
Style guide
While the build went along each module created was extracted and placed into the site’s comprehensive style guide. This documented all available content styles and ensured every item could be re-used when placed in different contexts. An object orientated approach really came into its own here, simply adding classes to change layout or give a colour variation.
To make things easier I created WordPress shortcodes and provided HTML code snippets below each item. It is unreasonable to expect all clients to be able to use HTML to update content but often some HTML knowledge is required to do anything beyond basic WYSIWYG styles. The code snippets helped the Trust so they were comfortable using either the visual shortcodes or HTML view (and actually chose HTML view most of the time!)
Images
Problems did arise with the home page slider and the “hero” images however, which served to act as billboards for the Trust and their individual Services (promotion being one of the project’s objectives). Images here sat at > 1000px wide, with the slider weighing in at about 350kb.
Here I decided to evaluate what was most important and in referencing the user personas decided both items were of secondary importance to other content. Neither are loaded on mobiles, using the Mobile Detect script to test the browser’s User Agent string (from a list which looks to be updated fairly frequently).
Admittedly two rules were broken here; assuming user context and implementing UA sniffing which is not without its flaws. However I felt page loading time was paramount, and alongside the mobile-first build the homepage came in at less than 220kb.
As the content was text-heavy, there really weren’t many other large images across the site. I didn’t feel the need to implement a responsive image solution such as Adaptive Images or Responsive Enhance, though I may do so during a later release.
At least for the time being, I think we have to be more considerate to images at the design stage. Raster images & high resolution devices being the main challenges; but before a standard such as the <picture> element is defined (hopefully soon) things are less than perfect. Should we ease off on things like sliders and photography until we have a more solid solution? Perhaps.
Graphics
.no-svg class via Modernizr.)
Icons were brought together using Fontello to compile a custom font containing only the iconography required (keeping file size to a minimum). To add each icon I used CSS pseudo elements with unicode characters in the content: property, meaning no extra markup was needed. I find icon fonts very effective, but worry that perhaps our reliance on them to overcome technicalities may lead to a lot of websites looking very similar.
Building the site mobile-first meant that the header, footer and background (branding) graphics only loaded when the screen size became appropriate. I opted to keep these as raster PNGs simply because they were too detailed to be usable as SVGs without a huge file size.
Tables
One slight hurdle during development was displaying tabular data; each Consultant profile page needed to display their weekly Timetable. Luckily as profile data is pulled via an XML feed it meant I could easily control the markup and formatting of the table.
This allowed me to hide the <thead> on smaller screens, then use HTML5 data-labels and a CSS pseudo-element with content: attr(data-label) property to prepend each table cell with an equivalent label. Kudos must go to Chris Garrett for this method.
data-labels when inserting a table via CMS.
As such I chose to leave alone all other content tables after initially looking at David Bushell‘s Responsive Tables. I decided it was slightly more intuitive for the user to drag the page (as opposed to the <tbody>) to view additional columns. The layout breaks slightly on some pages, but the result is far from drastic.
WordPress integration
During the build I was able to create the IA required relatively easily, helped largely by a great plugin from Scribu called Posts 2 Posts. The plugin allows you to create many-to-many relationships between posts. For instance; letting sidebar panels be managed centrally, and then assigned to individual pages.
I worked up five custom post types; Hospitals, Wards, Services, Consultants and Panels. Hospitals and Services are effectively a replica of Pages (hierarchical) and function identically. The site’s sub-navigation tests for the current post type before listing the relevant child pages. Separating these three post types allowed me to simplify the admin interface and display specific post meta boxes (created using the Advanced Custom Fields Plugin) only where they were needed.
Using the Post 2 Posts plugin I created connections to easily assign Wards to Hospitals, link related Services, and add sidebar Panels to any Page, Hospital or Service. We also created a custom plugin for the Consultants section which parses an XML feed exported from a central NHS database, then imports the data into the Consultants custom post type (with Services cross-linked).
Whilst all this is fairly standard fare for a lot of CMS’ out there, it’s good to see you can push the capabilities of WordPress and create something more complex. I often wonder if (as a CMS) WordPress will end up being limited by its beginnings solely as a blogging platform though. One issue I find is in the flexibility and reliability of the Permalink structure which seems a bit hit-and-miss at times.
CMS training
Thoroughly training the client for content upload meant we could focus efforts on other parts of the project. Let’s face it, no agency likes to spend time uploading content!
The training process worked really well. The Trust have now set up their own internal web team, with the content leader independently training numerous editors across different Service departments. Making use of the Revisionary plugin allowed any content added/edited to be held in a moderation queue for approval before going live, meaning administrators can retain overall ownership of content.
In summary
Hopefully I’ve provided an honest look at most stages of this particular project. Responsive Design workflow seems to be a big discussion point right now (here too), but I don’t think for a minute there’s ever a one-size-fits-all. What’s vital is to initiate the process and consider everything at the very beginning.
For responsive builds look not just at on-screen flexibility, layout and navigation — but in terms of an overall user experience. Consider things like data load, images and content hierarchy at all stages, then pick the option that feels most appropriate given everything that you know.
Our landscape is changing every day and what’s difficult is adapting quickly. This project began 9 months ago and yes, there are things we may look to do differently or more efficiently next time. Stop and assess each part of your workflow after every project and more importantly, write about it!
A month since launch, in more than 26,000 visits the site is seeing almost 20% usage via mobile or tablet. Interestingly, 75% of that is via an Apple device. I’d like to think that all of those users are getting a great experience, helped by Responsive Design and the decisions made here.
Please let me know what you think of the South Tees site and what we did right or wrong. If you have any further questions about anything please get in touch or comment below!
Likewise, if you want a responsive website Mixd would love to hear from you!