Designing the new, fully responsive wired.co.uk article pages

Recently, Condé Nast Digital undertook a complete redesign of the articles published on wired.co.uk. The aim was to provide a more content-first and immersive experience. These aims were established after research by our Information Architect.

We started on the path of fulfilling those aims over a year ago with the redesign of the GQ.co.uk articles and the introduction of what we call the ‘StickyScrollRead’ component, which allowed the editors to embed media that would be pulled out of the body copy at screen widths wider that 1000px and pinned on screen. That meant the user could continue to read the article and still refer to the peice of media that the copy was about. This proved to be a much more immersive experience and allowed the body copy more room to breath.

We wanted the Wired article templates to maintain the SSR functionality that had worked so well on GQ but we had also learnt a lot since the GQ designs that we could incorporate into Wired. Design process wise, we had also evolved a lot more too since the GQ articles were designed.

The templates for the GQ articles were designed entirely with Photoshop, with every different article variant (long form article, short form article, straight to gallery etc..) and every article template with a different embed (short form article with image embed, short form article with video…) being mocked up as a PSD. We ended up with 20 – 30 PSD’s and a wall of printouts that covered the office! It was time consuming, tedious and did not represent the final product as we would ‘tweak’ things during the development process.

The proposed concept for the Wired article designs was more in depth and advanced than its GQ counterpart and the thought of mocking up 50 – 60 Photoshop files was enough for us to put down our PS lasso tool and explore more accurate and efficient methods of communicating our designs to the development team.

The GQ articles that preceded the Wired redesign.

Typography

As many of our projects do, we started by looking at how we could represent the brand’s values through its typography. We looked through the printed magazine and identified styles that they use to tell different stories, colors they had used as well as styles for highlighting text and captions.

We then started to experiment with different type combinations, colors and font sizes through Typecast, creating a complete initial style guide for all headings, paragraphs and pull quotes as well as experimenting with side by side comparisons. This would prove to be the groundwork for our typography which we would return to later.

Building a style guide in Typecast.

The style guide implemented.

Layout

We picked an article from the print magazine and found the equivalent article on wired.co.uk. They were exactly the same story but where the magazine article had images of varying sizes, pull quotes spanning columns with the paragraph text wrapping around it and ample additions of white space, the online equivalent had a lead image above one long area of text surrounded by the site housing, shouting at the user to view something else.

The old Wired article design.

Wired magazine is well known for it’s innovative and bespoke layouts, for which it has won many awards. We wanted to try and replicate the magazine style layouts, with bits cutting into the body copy and not have all the copy area feel so regimented. We knew that the SSR component splits the page into 2 columns, one for the article body and one for the media embeds that get pulled out and pinned but we didn’t want the embeds to feel completely detached from the paragraph text.

We began to create the same article, using the same copy and images from the website to create a basic version of the SSR template using CodePen. The goal was to experiment with placing full width, keep in line and in content media within the flow of the article to create a more visually striking and engaging layout. Since designing the GQ article pages we had decided that it would be a more natural reading experience to have the copy on the left and the media in the right column so we switched them around and we also wanted to incorporate the standard ad units such as the double sky and MPU’s within the body copy, rather than give the adverts their own column (like on GQ) that would be redundant when there were no ads or when the ads had scrolled away.

Building in Codepen.

v1.1

In the first prototype the article led with a huge, full width landscape image which had much more impact and gave the sense of a magazine feature article. One of my favourite evolutions from the GQ templates was the introduction of the all mighty full-width image. GQ’s template enabled the editors to add ‘Pulled-to-side’ portrait and landscape images but they could sometimes lose their presence as the user’s screen got narrower and the images shrunk and the full width image was our solution.

The typography styles created in Typecast had not been used yet but there were basic styles assigned to the paragraph, intro text and quotes to help get a sense of hierarchy.

The SSR had also not been implemented but a column had been created with pull to side images which helped us to experiment with what width to set the pull to side column in relation to the page and basic double sky and MPU units were added to the body copy to see if they would disturb the flow of the text.

As a first draft, this approach proved far more useful than us experimenting with the same content via Photoshop. This not only allowed us to make some basic layout decisions quickly and iteratively but we could also use it as a base from which the developers could build on to add further functionality to and that’s exactly what they did.

Version 1.

v1.2

The CodePen proof of concept was passed onto the development team and they added the SSR functionality (so the pulled to side images actually pinned to the screen) as well as allowing us to change the positioning of a piece of media by changing its class before handing it back to the design team for styling.

At this point, we started to style the article with the font styles that we had previously created in Typecast by simply exporting the CSS directly from the web app. We could now also start experimenting more with different ways to embed content and see what worked well at different widths and for different stories. For example, leading with a full width portrait image was a bad idea as there would be an abundance of white space around the title and would also push the first paragraph too far down the page. We found that the best combinations seemed to be to lead with a pulled to side image and maybe a keep in line landscape as they had the least effect on the flow of the text. We also worked on optimizing the body copy for the most comfortable reading experience by controlling the max-width of the paragraph copy. Instead of adding more padding between the paragraph text and the pulled to side media, we indented the body copy so that the copy was as central on the screen as possible and it also allowed keep in line images to bleed off the screen much like a print layout might do.

Prototyping version 2.

This collaborative and agile prototyping method helped us to really make informed decisions quickly as we could easily test our designs on any device, screen width or browser and make amends with minimal fuss. We worked with real content as much as possible to make sure that we were not forgetting to style a certain rare class that gets added to only a few paragraphs — I’m looking at you .p1 — that we may otherwise have missed until later in development. We also created multiple article types using the same template to see how it worked when there was just 1 image and some short copy or if it was a review article.

Although we always knew that our CodePen templates were only going to be a proof of concept, we really tried to go into as much detail and make as many informed decisions about the design and layout as early on as possible.

v1.3

Once we were happy with the basic style and structure of the template, the developers transferred the code into their own coding environment, splitting up the CSS for each media embed into it’s own SASS file so the design team could easily access and change the CSS for just the ‘blob’ — which is what we ended up calling any add-ons that you could embed within an article… eg. images, video, reviews…etc — that we wanted to edit.

This was a huge help as by the time the dev’s had done their stuff and hooked it all up to the back end, the code was too complicated for any of us designers to understand and locate the parts that we wanted to change. This approach was also useful when styling new blobs, like the gallery thumbnails, read next or review ratings, as we would just create a new SCSS file with all the styles for just that individual blob, which made it far easier to update and maintain.

The ability to access and edit the CSS was a huge help to us designers. It was the first time that we had moved away from the ‘design in Photoshop – deliver PSDs – developers code – designers review’, method of creating a website and it meant that we were able to really fine tune the smallest aspects of our designs.

In the past, using the old methods, we may of launched the Wired articles at this stage (fully functional with some design tweaks which can be made after launch) but as us designers now had access to the CSS, we were able to spend the last few days adding a few subtle touches that would improve the experience. We added little ‘Enlarge’ icons on the corner of the images to let the user know that by clicking on any of them, you could open them as a full width, gallery image. We user tested articles on different devices to get the optimum body copy width for the best reading experience as well as spent more time fine-tuning the text links, quote styles and image captions, all small details that would together make a big difference.

This was a far more collaborative project than any other I had previously worked on with designers, information architects, project managers, developers and editors all working together at different stages of the project; adding their bit to a prototype that was constantly growing and developing into the product that it is today.

The final, fully responsive article design.

Not spending time designing all the styles, layouts and variations at different break points beforehand, meant that we could in a way, design by development. We wouldn’t wait until something was perfect to build it but instead just built something and worked on getting it perfect. This did mean that there were days where we would measure once and cut ten times but it also allowed for constant testing, development and more importantly, discussion on improvements which helped keep everyone engaged and involved with the project.

We are constantly reviewing and improving the build but we are also very proud of what we have managed to deliver in a pretty short period of time. The Wired articles not only represent beautiful, print style layout at any screen width and on any device but also a shift in the way we at Condé Nast Digital work as a team.

What do you think of the wired.co.uk article pages? How does Condé Nast Digital’s design process compare with your own? Let us know in the comments.

Javier Ghaemi

Javier Ghaemi is a multi-disciplined designer with experience in working across print, web and product design. He has worked on websites for brands such as GQ and Vogue and is excited by responsive design, web fonts and designing for touch devices. Follow him at @onlinedesigner2 or at www.javierghaemi.co.uk.