The
Guide to
Responsive Web Design Responsive versus adaptive design Content strategy for responsive design Build animations that scale Make your sites run faster on mobile RIP responsive design
in association with
Subscribe To NET
Get the No.1 magazine for Web Designers and Developers delivered to your door, your device, or both
NEW Print & digital edition great reasons to subscribe Print edition delivered to your door ● Interactive digital edition download ● Read on iPad, Android, Kindle, Nook and more ● 13 issues in a one-year subscription ● Money-back guarantee ●
From
£66
save up to
54
%
myfavouritemagazines.co.uk/NETSUBS16 Terms & conditions: Prices and savings quoted are compared to buying full priced UK print and digital issues. You will receive 13 issues in a year. If you are dissatisfied in any way you can write to us or call us to cancel your subscription at any time and we will refund you for all un-mailed issues. Prices correct at point of print and subject to change. For full terms and conditions please visit: myfavm.ag/magterms. Offer ends 31 March 2016
Welcome
Contents Responsive versus adaptive design
4
Content strategy for RWD
10
Build animations that scale
12
Make your sites run faster on mobile 16
Opinion: RIP RWD
19
in association With
Welcome
editor’s note
We have been keen supporters of the idea of responsive web design since the very beginning, and, boy, have we come a long way. It’s not a theory any more. It’s now a well-established standard that has truly revolutionised web design. That doesn’t mean it’s got any easier. Designing for a myriad of devices (and global audiences) poses significant challenges. And thanks to Google’s mobile-friendly update last year, it’s now more important than ever to figure responsive design out. So for this special guide we have invited some of the best experts to cover the issues that should be integral to every responsive design project: Ben Callahan discusses the difference between responsive and adaptive design, Matt Gibson dives into content strategy, Sarah Drasner explains how to create scalable
animations, Andy Davies explores how to make sites perform better, and Brad Frost controversially claims that responsive design is dead! And if that’s not enough, you should check out our brand new Responsive Web Design Handbook: Vol 2 (netm.ag/ RWDhandbook-278). It’s packed with practical solutions for cutting-edge layout options, responsive images, emails and WordPress portfolios, plus much more. You’ll find a teaser on the back page. Go, make it responsive!
Oliver Lindberg Editor, net magazine creativebloq.com/net-magazine
a note from our partner At Webflow, we want to empower everyone to create for the web. But for web creativity to mean anything, it has to be consumed. It has to be created for someone. It has to be designed to meet people’s needs, whether for entertainment, education or support. So we’re just as passionate about empowering everyone to consume web content. And that’s one reason responsive design is so important to us. For design to be truly responsive, it has to give people the content they’re looking for, anywhere, any time, and regardless of what device they’re using. It means helping people all over the world, whether they’re using a feature phone in Tunisia or a 6S in Silicon Valley. It means that instead of making assumptions about what people want
when they’re ‘on the go’, we use research, informed hypotheses, and constant testing and iteration so we know what they want and how to give it to them. Today, over 300,000 designers, creative professionals and entrepreneurs use Webflow to share their creativity with the world. We hope this supplement gives you the knowledge, ideas and inspiration you need to build for the web responsively, whatever tools you use.
John Moore Williams Head of content strategy, Webflow www.webflow.com
responsive guide 3
Rwd
Special report
Author BEN CALLAHAN Ben is the president of Sparkbox and founder of the Build Right workshop series. He writes about the web on industry blogs, and speaks at events seesparkbox.com Illustrator Mike Brennan Mike (@mike_ brennan01) is a graphic designer based in Bath. He is currently art editor at Total Film
4
responsive guide
Special report
Ben Callahan unpicks the differences between responsive and adaptive design, and explores how they can help us build flexible layouts
E
very time I hear someone ask, “Which is better, responsive or adaptive web design?” I wince. The question itself reeks of misunderstanding, similar to the ‘native apps versus web apps’ conversation. Rather than attempting to answer the question of which is better, I’d like to try for a bit of clarification around these terms.
Layout Back in 2010, the foundations of how we worked on the web were challenged with the introduction of responsive web design (RWD). Initially defined as a purely frontend technique involving a single DOM and some very fancy CSS (fluid layouts, flexible media and media queries), RWD was the practical answer to the theory of One Web (adactio.com/ journal/1716) many of us desired.
During this time, many web makers realised they could take a shortcut by skipping fluid, percentage-based layouts and just create several static, typically pixel-based layouts using media queries. Since this approach didn’t match the original definition of responsive web design, we began to call this approach ‘adaptive web design’. Perhaps we should have said ‘adaptive layouts’ , since the only real difference was the missing percentage-based, fluid layout of a responsive approach.
More than layout Around the same time, some supersmart folks like Aaron Gustafson and Karen McGrane were using the term ‘adaptive’, but in different ways.
Adaptive design philosophy Gustafson published the first edition of Adaptive Web Design in May of 2011. In this tremendous work, he succinctly describes adaptive web design as a “philosophy … which grounds me and helps me put any new technology, technique, or idea in perspective.” By Gustafson’s definition, adaptive web design is primarily about progressive enhancement. Responsive techniques are a part of this approach, but do not make up the entirety of the solution. Instead, fluid layouts, flexible media and media queries are used in combination with other core principles like universal
responsive guide 5
Rwd
Special report
accessibility, embracing fault tolerance, and enhancing on demand. This book is a manifesto for those of us that want to build experiences using web technology that will reach as many people as possible.
Adaptive content strategy McGrane has been speaking about adaptive content since at least 2012 (netm. ag/adapting-278). Her presentations on the topic are some of the best I’ve seen. She challenges attendees not to “give in when our content authors demand a WYSIWYG text editor that works ‘just like Microsoft Word’.” She shares techniques that empower you to capture content in chunks instead of blobs, which enables you to serve multiple channels from within a single content management system. Sometimes, this might mean serving a different article title to a small screen than you do to one with a larger viewport width. After all, truncation is not a content strategy. McGrane’s thinking here is specifically focused on our process as it relates to content. Her ideas could be integrated as easily into an m-dot site, a responsive site, or a site embracing Gustafson’s adaptive web design philosophy.
Adaptive techniques Of course, there is (at least) one more usage of the term adaptive design floating around. It comes into play when we recognise there may be
Seminal work Aaron Gustafson’s Adaptive Web Design is a must-have for every web-maker
some component of a web system that requires such a variation in experience from one device to another, it’s more efficient to create two separate versions of that component to be served in different situations. Which version to serve could be based on any number of factors, including screen or viewport size, location, user agent, or pretty much anything else you can dream up. You may recall Luke Wroblewski writing about RESS (Responsive Design + Server Side Components) back in 2011 (netm.ag/RESS278). This idea has been expanded over
Device metrics Google’s Device Metrics page offers some details about a handful of common devices
6
responsive guide
the years, and folks have used it as an iterative step towards a fully responsive approach, or as a great solution on its own (netm.ag/mixing-278).
Shifting our mindset At Sparkbox, we’ve recently been working with an organisation to help it redesign a large ecommerce site. The company came to us because it was looking for a web studio that had helped other big brands make the shift to responsive. When we got involved, its design team had already spent a significant amount of time planning its approach. As you can imagine, it had established a system of breakpoints for small, medium, large, and extra-large screens. This is a natural step to take, given our industry’s history of breaking the web’s inherent flexibility by fixing widths with CSS. However, this way of thinking actually creates the illusion of control, instead of truly embracing the fluidity needed to work with a responsive mindset. Ideally, we would have established a much more robust foundation. We could have taken a more iterative approach, using prototyping and constantly refactoring the designs into a system of reusable patterns. Of course, this can create
The QA challenge
Go adaptive For more clarification on ways to integrate adaptive content into your work, read Karen McGrane’s Content Strategy for Mobile
challenges later in the process (see the boxout on ‘The QA Challenge’). Today’s web demands an excellent experience at any width – not just for an iPhone, iPad and Cinema Display. It’s this ideal that drove me to write ‘There is no Breakpoint’ (netm.ag/ breakpoint-278). These days, it’s common for our work to include dozens and dozens of media queries. Some of these are for major breakpoints, and some are minor. Major breakpoints occur when there
Bringing them together Adaptive layouts, adaptive content, adaptive web design. With all these terms floating around, it’s easy to see why there is so much confusion. Adaptive layouts and adaptive content encourage us to think about unique experiences or content for unique situations. Conversely, a purely responsive approach is one that drives us to see what we’re building as a single experience (despite its ability to shift), and to serve the same content and functionality to every device.
I would encourage you to begin every project with a responsive mindset – aiming for parity of content, functionality and experience are coordinated shifts across elements in the system – typically a layout shift in columns. Minor breakpoints (aka tweakpoints) are for more detailed shifts in-between those major breaks – think subtle font size or spacing adjustments. This way of thinking allows us to operate at a system level, and to acknowledge that our designs must work well across a tremendous spectrum of device sizes. One web, designed for the broadest audience possible.
The question of an adaptive approach versus a responsive one is tricky to address, mostly because the terms are so confusing. I would encourage you to begin every project with a responsive mindset – aiming for parity of content, functionality and experience – and only to veer from this ideal when needed. And when you find those points, an adaptive approach can be used to – well – adapt. I suppose the unfortunate answer to our initial question must be: it depends.
When I graduated from college, I took a job as a software engineer. I was basically responsible for fixing the bugs. I worked with this guy (we’ll call him John) who was my ‘tester’. Any time I committed code, John was notified and would test it for me. Nine times out of 10, he denied my requests to merge code and rejected my work. Nine times out of 10, the work I was submitting was actually correct and ended up getting merged. Let’s just say, John and I didn’t get along so well. So what was happening? John and I were operating from two different perspectives. I was looking at a problem from the context of a developer who wanted to build the best possible experience. This drove me to consider solutions that challenged the way the product worked but benefitted our users. John was viewing the problem from the context of the bug report. In his world, there was one solution and I was rocking the boat. This tension is not uncommon. Imagine that the product being tested is a fluid, web-based interface. The complexity of testing a simple interaction goes through the roof. No more PDF spec documents of what the interface should look like. Now, we’re testing across a myriad of devices, browsers and bandwidths. Needless to say, this can be frustrating. The only viable solution I’ve found is education. Our QA engineers need to be just as aware of the intricacies of a responsive approach as our designers and developers. In fact, they need to sit in the same room, hear the same conversations, have access to the same tools. This is a big shift for organisations, some of which are still struggling just to put designers and devs together. We have a lot of work to do to allow this mindset to permeate our culture. That change works best when it happens as a ground-swell. So, as cheesy as it sounds, you need to be the change you wish to see!
responsive guide 7
Promotion
Promotion
Webflow takes the pain out of responsive design Want the responsive power of a developer without spending all day in a code editor? It’s time you met Webflow As a smart, savvy web professional, you will have got used to building out multiple mockups for different screen sizes, or translating those mockups into clean, production-ready code. But it doesn’t have to be this way. You don’t have to kick off your development process by building a bunch of static representations of a living, breathing, dynamic website. Or translating all those representations into code. Instead, why not start your next website with a tool that: ● Works with the basic building blocks of the web (HTML, CSS and JavaScript) ● Has a completely visual interface ● Looks and feels like the tools you know
8
responsive guide
● Lets you visually manipulate markup so what you see is actually what you get ● Automates a lot of the most annoying aspects of responsive design for you In other words, why not use Webflow?
A familiar, visual workspace From the moment you log in, you’ll feel right at home. Instead of translating your designs into code with a text editor, you’ll use familiar visual tools to achieve exactly the look you want. Just pick an HTML element, drop it onto the canvas, give it a class name and style away. All our pre-built components are responsive, so you’ll never have to ask yourself, ‘Will this work on
Promotion
Meet a truly visual CMS
With Webflow, every design change you make will cascade down on to all smaller devices
my phone?’ You’ll start designing in the desktop view, but there’s no need to keep switching between device sizes. Instead, every edit you make will automatically cascade down to smaller viewports (so your desktop styles cascade to all sizes, while tablet styles only affect smartphones).
animations that work beautifully on every device (as long as you remember there’s no hover on mobile). That means freelance designers get the power to design, prototype, build and launch websites all by themselves. Which also means a faster design process, and happier clients.
Webflow’s clean, production-ready code means your sites will be ready to launch as soon as you get sign off And you aren’t stuck with whatever reflow Webflow comes up with. Nope – everything is customisable. Switch over to tablet or mobile views to make your site look, feel, and perform just the way you’d like. Since people use devices other than iPhones to access the web, Webflow even offers adjustable breakpoint previews, so you can see exactly how your site will look on the boss’ BlackBerry. Super-handy when you know your audience has a particular fondness for Nexus devices, for example. Webflow also allows you to create rich, engaging interactions and
But Webflow isn’t just for freelancers. Agency and enterprise designers can easily use it to: ● Wireframe, prototype, and rapidly iterate on ideas ● Easily illustrate interaction concepts ● Quickly build ready-to-launch landing pages ● Build blogs and other content hubs
Of course, Webflow is more than just a visual web design tool and hosting platform. With the allnew, all-visual Webflow CMS, you can easily build totally custom, content-driven websites. With no need to mess with databases, PHP, or hiring a developer. Or trying to cram your unique content into what is, in the end, just another blogging platform. With Webflow CMS, you can create completely custom structures for your content, design that content in a familiar visual interface, and edit it right on the live website. Plus, adding new dynamic content is as easy as filling out a form. While other CMSs can produce similar end results, they usually require extensive collaboration with designers and developers – an involved process that can take months. But with Webflow CMS, a single designer can create a powerful, dynamic and responsive site in a matter of days, or even hours. Want to learn more about the future of content management? Take a look at webflow.com/cms.
Webflow’s clean, production-ready code means your sites will be ready to launch as soon as you get sign off. And even if you can’t use Webflow’s code (for whatever reason), you can export it for your dev team to work from.
Discover the future of responsive design at webflow.com responsive guide 9
Rwd
Content strategy
Content strategy
A b o u t t he a u t h o r
Mat t Gibs on w: cyber-duck.co.uk t: @duckymatt job: Chief creative officer, Cyber-Duck areas of expertise: UX, IA, HTML and CSS, project management
CONTENT STRATEGY FOR RESPONSIVE DESIGN
Responsive web design is often seen as an implementation challenge. Here, Matt Gibson considers it through the lens of content strategy
Usually, when we talk about responsive design, we talk about implementation. We muse about how to use media queries, fluid grids and other techniques to make our designs stretch and adapt to any screen size or environment. While that’s a good start, these techniques alone won’t ensure our designs are easy to use across a plethora of platforms, let alone actually useful for our audience. This is where content strategy comes in. It defines which content we’ll need, and – more importantly – why we need it in the first place.
Mobile-first The approach outlined by Luke Wroblewski in Mobile First is quite rightly touted as the most appropriate way to approach the canvas for responsive design. However I think we should go further, and consider content strategy through mobile-first. Starting with a smaller canvas increases focus. It makes us concentrate on what content really matters and what is core to the user experience. If we start with a huge desktop canvas, we’ve got all this extra space to play with. It’s tempting to shove more and more content onto our canvas, regardless of how much value it adds. We end up reducing the worth of our core content by surrounding it with content that, for the majority of users, isn’t relevant. The result is interfaces so full of noise that users struggle to identify and use the parts that are genuinely useful. Instead, we should carefully consider why our content exists. Often, plenty of our content is included (or not) purely because of assumption. And assumption is the enemy of a solid content
10
responsive guide
strategy. The trouble is, it’s easy for us to make assumptions about what users want or need, especially when it comes to mobile. There’s this pernicious idea that people only use their mobile phones when they’re in a rush, or ‘on the go’. Of course, that may be true some of the time. But research studies have found that 60 per cent of smartphone data is used indoors. People are just as likely to use their mobile whilst sat at their desk, relaxing on the sofa, or even while sat on the toilet (apparently four in 10 of us regularly use our mobile phones in the loo). So how can we avoid making these assumptions? The obvious starting point for challenging our own biases about what our users really need is to speak to them. Conducting research by interviewing users, observing them and analysing any available data helps strip away the veneer of assumptions.
Content parity matters This is why content parity is so important. We must get out of the habit of presuming what a user will or won’t need – or do – based on the device they’re using. Instead we need to ensure our core content is available across any platform. So, no more proverbial slamming of doors in the faces of our users, forcing them to download our app, or telling them their screen isn’t big enough. No more presumptions about what content people might find useful on their phones. For example, I recently ordered something from Amazon on mobile, before realising I’d given the wrong payment details. This should have been easy to rectify, but because Amazon hides the content
Content strategy
related to editing an order on mobile, it wasn’t. Requesting the desktop version of the site kept redirecting me to a different page. So I ended up having to wait until I had access to my laptop to fix my order, all because Amazon presumed people wouldn’t need to edit orders on their phones. As Karen McGrane says: “You don’t get to decide what device somebody uses to access the internet. They do” (netm.ag/mcgrane-278).
Parity and priority Of course, content parity doesn’t mean we shouldn’t adapt how we prioritise our content for different
We must not presume what a user will or won’t need based on the device they’re using platforms. The main priority for users accessing your site on smaller screens might not be the same for users on bigger screens. We applied this thinking to the cyber-duck.co.uk website menu. It has parity on every platform, so you can still access all the content, whatever device you’re using. But as screen space becomes more scarce, we change the menu items that are immediately visible. We even begin to surface new menu items: directions to our office, or our phone number. We knew from traffic data this was the content people were looking for on their mobile
devices. By giving it more priority, we could make it easier for people to find.
Finding your core content So how do we define our core content? A good place to start is writing down both organisational and user goals and finding any areas of clear overlap. Then, using research as a base, map out user journeys that are based on the types of tasks users come to the website to complete. From this, you can begin to plan what content you’ll need and how you should communicate it. Chances are you have some of the content you need already. By auditing our existing inventory of content, and framing it against the items that support both our organisational and user goals, we can define what content to keep and what content we’ll need to create. That doesn’t mean you need to have every single piece of content ready and in place before designing. From my experience, this just isn’t realistic. Instead, our designs will ultimately be shaped by understanding and knowing what our content will be made of, and the types of content required.
Planning for portability As the landscape we’re designing for is constantly shifting, our content needs to be flexible. We must create content with portability in mind from the outset, because it will need to reach more places and platforms than ever before. Ultimately, a deviceagnostic approach to content strategy is best. Let content dictate layout and interface design, rather than the other way around.
responsive guide 11
Rwd
Animation
A b o u t t he a u t h o r
S a r a h Dr asner
w: sarahdrasnerdesign.com t: @sarah_edo job: Senior UX engineer, Trulia (Zillow Group) areas of expertise: JUX, SVG
Animation
Create animations that scale for all devices Sarah Drasner explains how, by using the right tools and smart design,
we can make our animations shine in a multi-device world Animation on the web is particularly nuanced, as we have to adjust our work to take into account bandwidth, code compatibility and product design. In this article I’ll explain the recommended set-up for a truly scalable animation. I’ll also cover different ways of working with the animation to achieve positive user experiences and parity across our multi-device world. I will cover a selection of key use cases: adding CSS animation to SVG sprites, dealing with standalone graphics that require complex movement, creating a responsive experience that adjusts to the viewport, and making animations simpler for mobile. I highly recommend using SVG (Scalable Vector Graphics) for graphics with responsive animations. These are resolution-independent, so you won’t have
12
responsive guide
to load up additional HTTP requests or bog yourself down with replacement image media queries. As an alternative to the img attribute, the picture element handles image replacement quite nicely, but when dealing with different-sized moving images, it becomes much more cumbersome to keep the animation consistent. SVG is far superior in this way: we can write code once and continue to adjust the visual complexity of our image. SVG also provides a navigable DOM, so it becomes simple to reach inside a complicated graphic and animate elements individually. As its name suggests, SVG is built to scale. It’s incredibly simple and intuitive to adjust the size of a SVG. Even with these key features, though, units and even the way we perceive images will change from
Animation
in-depth
Responsive information
Figure 1 With this approach, as well as changing the size we also reduce the complexity of our design
screen size to screen size. Don’t worry; I’ve got you covered! Let’s take a look at a few ways of working with responsive animation.
SVG Sprites and CSS Animation This first technique works particularly well for responsive, standalone animation – for example when illustrating text. We start with a typical responsive sprite, and adapt not just the size of the image, but the complexity of the graphic too. This makes a lot of sense when you think about what we can visually interpret on a smaller screen. In order for the graphics of our animation to remain clear, we must also consider screen real estate. Take a look at the illustration above (you’ll find the final animation at netm.ag/demo1-278). On the left you can see we have designed for desktop, tablet and mobile implementations. On the right, we have done two things to get ready for export. The first is to remove repetition. We can see clearly that the desktop and tablet views are similar enough that we could either alter the properties or replace them with CSS media queries. An example of such an alteration would be to adjust the background so it’s green instead of blue. For the mountains, the change in design between different device sizes is significant enough that we will need to apply a class on the element to hide or reveal it. The most important part of this technique lies in the way we’re handling the viewBox attribute. You can think of the viewBox as a little window in which we view the SVG. The SVG itself can extend beyond the bounds of the viewBox , but only the area within it will be visible. The rest will be cropped out. For the desktop and tablet versions, we want only the first tile to be shown, so initially we set the viewBox inline in the SVG to cover just the top section of the sprite: viewBox="0 0 490 474" . We then shift the visible area with JavaScript to "0 490 500 500" .
Responsive development with SVGs doesn’t have to stop with the SVG. The fact that the SVG DOM plays so nicely with HTML DOM attributes means you can have multiple pieces that switch places on the screen. Even things like infographics – traditionally flat images that are totally inaccessible to screen readers – can become completely accessible. Infographics are a great example of how animation and responsive design can completely overhaul the way we show information, but the use of infographics as a sharing mechanism has steadily declined. One possible reason is that in the last two years, mobile engagement has increased over even desktop. Infographics that are exciting on desktop become an arduous affair on a mobile device. With the rise of traffic on mobile, sharing via social media becomes frustrating and causes the engagement potential of these images to decline. Animation, with its potential for attracting attention as well as interaction, could completely revolutionise this way of presenting information. Responsive animation means keeping our large mobile audiences engaged. Adding accessibility into the mix means we’ve got an all-inclusive, interesting, easy-to-use way to show a lot of information at once.
Animation options Animation can help make infographics much more accessible on mobile
responsive guide 13
Rwd
Animation
focus on
Resources Jank Free www.jankfree.org The Chrome team’s performance website offers articles, videos and guides to educate developers on how to avoid performance pitfalls while animating. SVGOMG jakearchibald.github.io/svgomg Jake Archibald’s SVG optimiser can save you from an incredible amount of cruft. This visual GUI extends the terminal-based SVGO, but its visual indicator quickly shows you the results of your work. Animation in responsive design 24ways.org/2015/animation-in-responsive-design Val Head’s responsive animation article presents different ways to implement responsive design with focused art direction and choreographed UX, without limiting performance. Animating SVG with GSAP greensock.com/svg-tips This post takes you through a myriad of GreenSock features via live demos of capabilities and comparisons. Each section comes with links to their docs, which provide good jumping-off points. Responsive animated infographics netm.ag/info-278 In this presentation, I take a detailed look at how we can breathe new life into the infographics format with animation, and explain how to implement these updates yourself.
Complex movement Any time you have a standalone graphic with more complex movement, I suggest switching to the GreenSock Animation Platform (GSAP), rather than using CSS. Although there are loads of cool things that GSAP has to offer, the main advantages in this case are twofold. The first is cross-browser stability. Thanks to all our browsers and systems, frontend development means a large testing matrix. When we include mobile, it gets exponentially more complex. Older Safari browsers on older Apple devices can have spotty support for moving SVGs, and there are a lot of gotchas on Android as well. GSAP offers really stable movement, without sacrificing speed. The second advantage is the timeline. This allows for the stacking of tweens and even staggered effects, with streamlined and intuitive code. For the rest of the examples in this article, I’ll pair GSAP and SVG. Let’s first establish that animating elements with transforms and opacity is the most performant
Animating elements with transforms and opacity is the most performant approach approach. It’s easier for the browser to optimise because it reduces repaints, which is the most important thing to keep your eye on for jankand stutter-free animation. Also, if we use the attributes within the SVG DOM they will scale in tandem with the entire SVG, because they are honouring the space within the viewBox . So if you scale a complex SVG using percentage, flexbox or other techniques, your animation will also scale accordingly. This means you don’t have to adjust anything; you can focus on writing your code correctly just once. And that is a pretty huge boon. For example, let’s consider a really complicated animation like the one shown in fig 2 (code at netm. ag/demo2-278). I will usually design all the elements I need first, and slowly reveal them over time. This allows me to plan things out in advance, which leads to cleaner, more legible code. The finished animation is completely scalable – you can randomly adjust the button while it’s running and have the entire thing adjust to a new percentage (see fig 3).
Responsive UX Figure 2 The original design in Illustrator – we design everything first, and then slowly reveal things
14
responsive guide
Designing a responsive experience that adjusts to the viewport relies on some planning in the design stage.
Animation initially, so it can be triggered by a user click event. Now everything is scoped to its requisite section, all the way from design to finished product, it’s easy to know where to go for adjustments. We separate out these builds and have each Lego-like piece adjust via percentage, and it scales beautifully. Alternatively, flexbox would work equally well, depending on the support level.
Less pizzazz on mobile
Figure 3 The animation changes sizes when you click the button, but the animation experience stays consistent
You can think of it like little interlocking Lego blocks: we go through the design, build and development stages, scoping each particular area to itself, but what the user ends up with is a complete (yet completely different) view on each viewport. We took this approach for our Huggy Laser Panda animation (shown on page 12). Take a look at it in action at netm.ag/demo3-278. We designed this carefully, considering the units that would have to switch and stack. On mobile, to make the pieces correctly interlock, we adjust the positioning of the right section (outlined in magenta for clarity), and flip it so it can stack appropriately. We make sure each part shown in the boxed sections is exported within individual SVGs and properly named, including smaller units or groups. This means in our export settings (I use Jake Archibald’s SVGOMG), we do not remove unnecessary IDs or groups. We then use multiple functions. Each section is scoped independently, and there is one repeated function for all of the animations that loop.
Let’s face it, mobile connections (particularly in less developed countries), can be pretty slow. Whether you only have a few key animation interactions on your site or a huge WebGL experience, sometimes an animation that looks beautiful on desktop need not scale down to a mobile experience. In the case of a large canvas animation, or even a really complex SVG animation that is non-critical to the user experience, sometimes the best thing you can do is to tone it down or turn it off for smaller devices. Active Theory’s site does a beautiful job of this (fig 4) by showing you a full particle canvas animation on desktop, which is replaced with a simple polygon background on mobile. The interactions on mobile are still very on-point, transitioning beautifully beyond even what we expect on native. The team still shows off its interaction prowess in the way you navigate the site, which is arguably more impressive on mobile than an animated background would be anyway. The design saves the bandwidth for what counts.
Conclusion Whether you design for responsive from start to finish or simply turn animations off on mobile, having a concrete plan for what your viewers experience from device to device is vital. This is particularly true in a landscape where mobile is king. Content, type of image, and user bandwidth all help guide animation choices for responsive design.
Figure 4 Active Theory
keeps its visual language consistent, while dropping heavy canvas animations on mobile
function revolve() { var tl = new TimelineMax(); tl.to(gear, 4, {transformOrigin:"50% 50%", rotation:360, repeat:-1, ease: Linear.easeNone}, "begin"); ... return tl; } This makes the design much easier to build off and reason about. We can even pause each animation
responsive guide 15
Rwd
Performance
A b o u t t he a u t h o r
Andy Davies w: andydavies.me t: @andydavies job: Web performance advocate, NCC Group areas of expertise: performance, ecommerce, web development
Performance
Make your websites run faster on mobile
Andy Davies explores how we can build pages that deliver a speedy experience across all the devices Mobile phones and tablets are quickly becoming the main way we access the web, with many retailers and news organisations seeing more than half their traffic coming from these devices. Phones and mobile networks are getting faster, but there’s still a huge discrepancy in capabilities. Cheaper phones tend to have slower processors and less memory – and even though 4G networks are being rolled out, we still spend large amounts of time connected to 3G or even 2G networks. 4G speeds in the US fell as more people switched, so faster networks might not save us, in any case. The sites we’re attempting to deliver are getting larger – figures from the HTTP Archive (mobile. httparchive.org) show the average mobile site is now over 1.2MB. We’re asking more and more of our visitors’ devices and the networks they use.
Measure what matters It’s easy to measure page size or the number of HTTP requests, but they don’t really represent our users’
16
responsive guide
experiences. We need measures that are relevant to the visitor’s experience – for example, how quickly usable content appears, or when someone can start interacting with a page. We can create filmstrips in WebPageTest that show the progress of our pages as they load. This tool even has a metric – Speed Index – representing how quickly the visible screen is drawn. Lower scores are better, and 1,000 is a great target to aim for. Using the W3C User Timing API (www.w3.org/TR/ user-timing) we can also measure critical events, such as how long our hero image takes to load in our visitors’ browsers.
The critical rendering path Once we understand how long we’re making people wait, we can start to work on reducing that time. The areas I concentrate on first are the resources a browser needs to display content and the dependencies between them. This is known as the critical rendering path (for more on this,
Performance
Page progress
there’s an excellent guide from Google’s Chrome team: netm.ag/CRP-278). When the browser receives the HTML for a page, it starts building the DOM. As it’s doing this it discovers the other resources a page needs: style sheets, scripts, images and so on. The style sheets are downloaded, parsed and the CSS Object Model (CSSOM) is built. Scripts may query the style information of elements – dimensions, position and so on – so any synchronous scripts that follow the style sheets don’t get executed until the CSSOM has been built. Once the browser has the DOM and the styles that apply to the elements, it can start to lay out and paint the page to the screen. It’s also at this point the browser finally discovers any custom fonts or background images. Many of the resources on the critical rendering path just keep growing. In the last two years, the size of
If we want fast sites, we must be more deliberate about what we include on our pages style sheets and scripts have grown by a third, and fonts have more than doubled. We’re too relaxed about how our pages perform. If we want fast sites, we must be more deliberate about what we include.
We can go further still and split our styles into those needed to render a page’s core content and those that can be loaded later. The smaller the set of core styles, the less work a browser has to render the page. For this we can use a library like Filament Group’s loadCSS (netm.ag/loadCSS-278). The Guardian is known for pioneering this approach and actually inserts its core styles directly into the HTML. Others are following similar approaches: one mainstream retailer has a core CSS of only 6.8KB, and its site is very fast for most of its visitors.
A filmstrip from WebPageTest illustrating how the Guardian’s homepage renders
Fonts We’ve fallen in love with web fonts, but at what cost to our visitors’ experience? Fonts are discovered late in the critical rendering path and at this point downloading the font or retrieving it from cache may be the only thing that’s preventing the text on the page from being displayed. Could you limit the number of custom fonts you use to one, or maybe two? Or could you follow Medium’s lead and only use the fonts already available on devices (netm.ag/TNT-278)? If you can’t, look at how you can shrink the font download. Sub-setting can remove any glyphs you don’t need. All modern browsers support WOFF, but WOFF2 (with its more efficient compression) will make the download smaller still. Currently we rely on JavaScript to control whether a font blocks text rendering, but new browser features will enable better control in CSS. The font-display
Styles CSS has a tendency to grow over time – as sites evolve people are cautious about changing existing styles and so add new ones instead. Gzip compression reduces the download size of CSS but the browser still has to decompress it and parse the rules. The uncompressed size of style sheets can be 10 times the downloaded size and contain thousands of rules that introduce a noticeable impact on performance. Structured approaches to CSS and design such as Atomic Design, OOCSS and so on, coupled with style guides, are a great way to manage CSS over time. Teams that adopt these approaches appear to be better at keeping CSS under control.
Page growth HTTP Archive shows what mobile pages are made up of and how they’ve grown over the years
responsive guide 17
Rwd
Performance
blocking script element. This introduces the risk that when their scripts are slow to load, they delay the rest of the page. In the worst case scenario they may be completely unavailable or break your page completely.
Tame image size Although I’ve focused on measuring performance based on time, size still does matter – particularly where visitors pay for their data, or have really slow connections. Images continue to contribute the largest proportion of the page size, so delivering the optimal version is vital. Initially, responsive design used a single image and relied on browsers scaling it to fit the device, but this leads to devices downloading images that are far too large for them, wasting bandwidth, and increasing processor load. Tim Kadlec observed some devices taking over a second to resize large images. The srcset attribute and picture element give us better control over the images we deliver to mobile devices. srcset hints to the browser which image
Waiting game We all hate waiting for fonts to load
property will allow us to control render blocking behaviour in CSS. It’s only available in Chrome Canary at the moment, but should gain wider use. Finally, W3C preload hints will remove delays by enabling us to specify fonts that should be downloaded without waiting for CSS to be parsed first.
Scripts When a browser comes across a synchronous script (one without the async attribute) it pauses DOM construction until the script finishes running. If the script isn’t already in the browser cache, then it must be downloaded, adding to the delay. Often to prevent the delay from scripts, we add them to the bottom of the page. However, browsers have got more intelligent and the preloader now downloads these early (even though they won’t block). By including scripts early and using the async attribute, we help the browser to prioritise the download appropriately. The browser knows it must download the script, but it also knows it doesn’t need to wait and can carry on building the DOM. Unfortunately most scripts are included synchronously and so block DOM construction. Changing them to non-blocking and triggering their behaviour using an event handler will improve our rendering performance. Third-party scripts such as A/B testing and tag management are often included using a normal
18
responsive guide
Size matters – especially where visitors pay for their data, or have really slow connections it should pick, but the browser is free to override that choice. It’s generally used where we have the same image but want to deliver different versions in terms of size or resolution. picture on the other hand is an instruction to the browser, and uses a media query-like syntax to define which image the browser should choose. It’s typically used where a different crop of an image is needed for a smaller-screen device. There’s still the challenge of deciding what size images and which variations our design needs, but by using srcset and picture we can deliver optimal images to most modern browsers. PictureFill allows us to polyfill them in older browsers too.
Be deliberate As Lara Hogan reminds us in Designing for Performance, fast sites don’t happen by accident. They’re something we need to be deliberate about, both in the processes we adopt and the techniques we choose to use. With new features like responsive images, better control over font loading and APIs like service worker, browser makers are offering us new tools to help make our pages faster. How deliberate are you being?
Rwd
Opinion
Opinion
RIP RWD
Brad Frost explains why the ‘responsive’ label is no longer relevant fast-paced web design landscape. It’s up to us to help steer our organisations and clients in the right direction. We web designers and developers have seen the future, and realised it requires us to step up to the plate and take a more active role in our organisations’ decision making. To do that, we must discard the blame game. No more ‘Oh, I want to do the right thing, but my clients are dumb and my boss won’t let me.’ Take ownership. It’s not easy convincing people to follow one path instead of another, but that’s what’s required in order to do great work. It’s critical to fight on behalf of our users, and push back when asked to do things that are detrimental to the user experience. Make your clients and stakeholders understand why adding 17MB videos and 23 tracking scripts to a web page is a terrible idea. And if they still disagree, stick to your guns. Things like responsiveness, performance, accessibility, patterns and documentation should be baked into our workflows by default. You don’t have to ask permission to follow your craft’s best practices. If that means doing things on the sly, so be it. In 2016, we need to roll up our sleeves, fight the good fight, and do whatever we can to make great experiences for our users.
Responsive design is dead. OK, maybe it’s not that dramatic, but we’ve thankfully reached a point where responsive design has become the default approach for creating things for the web. Five-plus years ago, the ‘responsive’ label gave us something to rally around as we frantically searched for ways to cope with this explosion of web-enabled devices, screen sizes, form factors and so on. But the time has come for us to stop shoving the word ‘responsive’ in front of everything. Folks like Andy Clarke and even Ethan Marcotte himself have predicted this day would come, and I think in 2016 it’s finally here. To look at the future of responsive web design is simply to look at the future of web design. That is not to say responsive design is no longer important (it’s more critical than ever), but the time has come to move beyond surface-level labelling and focus on the tangible things organisations can do to create great experiences. Now the novelty of responsive design has worn off, how do we roll up our sleeves and really get things done?
Fighting the good fight
PROFILE
It’s not the responsibility of business folks and other non-web stakeholders to keep up with the insanely
19
responsive guide
Brad (bradfrost.com) is a web designer, speaker and consultant based in Pittsburgh, PA. He has helped create tools including This Is Responsive, Pattern Lab and Styleguides.io
9000
From the makers of
in association with
Like this? You may also like this ...
Pick up your copy at
www.myfavouritemagazines.co.uk/design