 All right, good morning, Waltham. How are you guys doing today? Got a room full of decaf drinkers. That's incredibly exciting to me. It's really great to be here. I just want to say a quick thank you to Constant Contact for inviting me out here. I'd hate to ever be the guy who has to follow Michael Lopp on a conference lineup. So that aside, it is really great to be here and to be part of this amazing event. So my name is Ethan Marcott. I'm a local designer based here in Cambridge, more specifically, on Beep on Twitter. If you follow me there, I apologize profusely. But I actually have a confession to make to you guys. And I feel like I can do that. I've been in this room for all of 10 seconds. I feel like I know you. I am an incredibly, impossibly lazy person. I'll get to that in a minute. Because what I'd actually like to do first is tell you a quick story about a tree. Now, this tree is located in the Pando Forest. Now, Pando is actually located in Utah. It's part of the Fish Lake National Reserve. And it's 106 acres in size. It's a fairly good-sized forest. So if you're walking through Pando, you're surrounded by these beautiful white trunks shooting up out of the ground. And there are some 40,000 or so estimated to be in Pando. But as you're looking through this tree, it becomes apparent to you after a few minutes that I've actually lied to you. Because Pando isn't actually a forest. It's just one single tree. You see, Pando is the Latin term for eye spread. And Pando is not a forest, but rather it's a giant clonal colony of one single quaking aspen tree. So all those 40,000 trunks that you see are actually just stems, all shooting out of this massive underground root system that they all share, which I think is kind of beautiful. And Pando's age is actually estimated to be some 80,000 years old, although there's some scientists who may be credible. I have no idea. Let's say its age is actually closer to 1 million years. But regardless of which side of the debate you fall on, Pando is both the oldest and the largest known organism on the planet. This is a talk about web design, I promise. The reason I love this story so much, though, is because I think in recent years, we've started to see web design's forest for its trees. We've moved further and further away from this old, outdated view of a page, right? This sort of abstract system of columns and rows. And we sort of stuck with content. And we understand more than when we're building our interfaces. When we're designing our products, our work begins a level beneath that on the individual components and pieces of our design. There's this one amazing essay by a friend of mine, Trent Walton, who wrote about his transition from someone who was kind of a responsive design skeptic into somebody who's doing some of the best responsive design work out there today. And he talks about how he traded the control he had in Photoshop for a new kind of control. And I think it's interesting to point out that he doesn't say less control, but a new kind. One that uses flexible grids, flexible images, and media queries to build not a page, but a network of content that can be rearranged at any screen size to best convey a message. And I think there's something really kind of poetic about that image, right? And that we've really just sort of moved away from this notion that there's sort of like an ideal canonical view of our design. And as we move further and further beyond the desktop, we are really designing these networks of content that can be built from the ground up. And so to do so, we need to understand the characteristics of these individual pieces of our design. And then basically turn them into that network that can be rearranged at any screen size to best convey a message. And I have another confession to make. It feels incredibly weird to be the guy talking about responsive design, even though I wrote the first article, because I met a publishing deadline. And I wasn't expecting anything like the reception that it got. To see basically every single industry get incredibly excited about the flexibility at the heart of responsive design, or more specifically, the flexibility at the heart of the web. And use that network of content idea to basically rearrange their interfaces, rearrange their content to think about how they can tell stories, how they can communicate to their audiences regardless of the size of their screen, whether it's incredibly wide or incredibly small. And once they start using those ingredients of a responsive design, fluid grids and media queries, then they basically understand those technical constraints are really sort of the easy ones to figure out. Now, the bigger problems start to come into workflow. How we collaborate together, how we think about designing these hierarchies. Now, that's not to say that responsive design's the answer for every problem in the digital world, but it's another tool in the box. And I think it helps us tell some of these stories when we're dealing with all of these challenges. Because I think it's fairly safe to say that just working online, we have a fairly tough job. And it's not remotely the toughest job in the world. I'm not even going to pretend that. But we have our challenges, and they seem to be compounding themselves. So it's not even just about individual device classes anymore. We're being asked to design compelling digital experiences for more operating systems than at any point in the web's very short history. We're dealing with more input modes that we ever had to think about previously, and devices that can't neatly be siloed into touch or analog, but some of them sort of straddled the two really effectively and well. We're dealing with more displays of varying color density and degree. In other words, we're basically at this point now where the words that we use to refer to these devices broadly, tablet and mobile, are so broad and just so useless. I mean, they're so inexact in trying to address the challenges of what we're trying to build and design and publish on a daily basis. And I think Google Glass is probably in there somewhere, too, I don't know. But putting all that aside for just a second, I mean, these challenges, it's not like they're going down at any point. I mean, there are these new browsing contexts, and new device classes hitting the market. We just saw a couple of new ones hit just a few days ago from Apple's keynote. Hardware and software vendors are experimenting with new interaction models that we weren't thinking about when we were designing our products and designing our interfaces. And the web that we use to publish our content that our audience has used to reach our sites and services is far more broadly accessed today than at any point in its very short history. But it's also far more fragile and far more volatile that we might like to think about when we're starting to have these conversations about what our sites and services need to build and what they need to be. So when I'm looking at the fragility of the network and all these new interaction models and these new device classes that are hitting the market, I'd like to say that I rise to the occasion every single day. And I don't cry myself to sleep at night. But more often than not, I'll be totally honest with you guys, my reaction tends to be one of, well, frankly, laziness. I get a little bit negative. I get a little bit tired. And frankly, most days, I just want to go back directly to bed. Always leave with a gift, mom said. She didn't actually say that, but I like to pretend that she did. But here's the thing about laziness. We use a lot of language in our daily work. I could be talking to you, and we could be talking about a mutual friend of ours. And I could describe her as liberal or conservative, as a logical or a real daydreamer. And depending on who you are and the values that you hold dear, either one of those words would be seen as either a compliment or a complaint. Laziness doesn't really have that problem, though. Everyone just sort of regards it as just like an awful, terrible thing, right? It's just something that's preventing you from being a better version of yourself, from building a better product, from getting to that next level of professionalism. And I'm here to suggest today that maybe the picture's a little bit more complicated than that. Maybe laziness is what we need to deal with some of the complexity that we're dealing with in the marketplace right now. There's this one great quote by Khalil Gibran, who basically said that our anxiety does not come from thinking about the future, but from wanting to control it. And I know at least for me, and maybe I'm just the lone person in the room here, but that's definitely true, I look at all these challenges, new device classes, a very volatile network. And I just sort of see them as something that I need to meet head on, that I need to have a solution ready at hand to sort of design a better solution, to design a better interface, to basically answer that question. And I'm wondering if maybe that's the wrong approach. And in fact, maybe a little bit of laziness applied intelligently to web design could actually maybe be a little bit of a virtue. Because maybe it's about letting go, relinquishing that need to control the experience perfectly, and maybe just provide some rough parameters for shaping it, as it's being experienced in all these thousands upon millions of devices that our users are accessing our work with. So anyway, this is kind of an open ramble about how laziness, as I've seen it, has been kind of manifesting itself in my work. And to do so, I thought I'd actually walk through a couple different specific components of responsive design to sort of tell you how I think about maybe letting go a little bit more, but maybe also being able to do a little bit more in the same result. So with that, let's get started right with layout. Now, at least for me, laziness in responsive design has been kind of manifesting itself in two aspects of my work, specifically dealing with video and other kinds of embedded media in a responsive design, and then actually designing the grids that kind of house the content, that sort of power the interfaces that I'm working on. So starting right with media, there's been an incredible amount of writing about responsive images and working with fixed-width media in a flexible layout. And there's a significant amount of work that goes into that, but this is kind of the first step in the journey. There's one simple line of CSS. And all that it says, basically, is that if you have an image in a completely flexible layout, its width will never exceed the width of its containing element. Its maximum width will never be greater than 100%. And it'll have this really neat shrink wrap effect as it resizes proportionally. I mentioned that because the nice thing about this approach is it can be extended to include other kinds of media as well, like embedded objects and embedded video. So here's a quick example from my blog, which is neither responsive or attractive. Let's be perfectly honest here. But you'll notice that I'm using the same CSS rule. And because of the flexible layout and because of that max-width 100% rule, the video always sort of hues to the width of that completely flexible container. It never bleeds out breaking the layout. Now this is obviously not optimal because, I mean, the height of the video hasn't changed. And this is really a problem of scale because the video that we put into our pages doesn't actually have any intrinsic dimensions, like images do. So we have to specify them in the document. We have to actually manually write them out into HTML because it's 2014 and we all love doing that. But we can override the width pretty easily with the CSS as we just did. But we can't do the same thing with the height. We can't set it to height auto or something like that because basically we'd have a whole bunch of zero-height videos in our pages and I would probably be fired. So a lot of people are really kind of experimenting with this and trying to puzzle their way out of this problem. And they're doing so in a responsive context. So this is made by hand.com and this is a beautiful responsive site featuring a beautiful film series. Even if you're not interested in responsive design, I can't recommend this enough. It's a very short film series featuring some short films about makers and designers in Brooklyn. But because it's a responsive design, you can watch these films in their website and regardless of the size of their screen, those videos resize proportionally. And the reason they're able to do that is because they do a little bit of light JavaScript work to measure the video's dimensions when the page first loads. And then anytime the page resizes itself or you change the orientation of your device, it basically redraws the video using those same dimensions but resizing them according to that first measurement. This is an early version of the Dew Lecture site, a conference series, and they basically took the same approach. Little light JavaScript, measure the video, and then redraw it proportionally. Now you'll notice in both of these instances though, there's a little bit of a slight visual stutter. Well, it takes a second for the video to kind of catch up with the design as it's resized. Now this is because the resize event in JavaScript is incredibly expensive to sample. So it's good to throttle it a little bit. But the challenge is this kind of points to the fact that maybe JavaScript's not the best approach to this. Maybe we need sort of a CSS native solution to kind of do the heavy lifting for us. Well thankfully because we are living in the future, this was solved about five years ago for us in an article for a list of part called Creating Intrinsic Ratios for Video. And this guy, Terry Koblenz, came up with this really amazing approach to coming up with proportionally resizing media in fluid layouts. And his approach was actually, I think kind of brilliant because what he did was he basically looked at videos in pages and we understand that they have certain characteristics, right? Immediate ones are sort of a width and a height expressed in pixels. But if we put the pixels aside for just one minute, those two characteristics, width and height, actually have a very deep and profound relationship to each other, specifically the aspect ratio measured from one corner of the video down to what's opposite on the other corner. Now we can calculate that aspect ratio by taking the height of the video and dividing it against its width. And so if we basically plug those pixels into the formula, we're left with an aspect ratio of about 56.25%, or 16 by nine in cinema terms if there are any film geeks in the house. Anyone? Anyone just me? All right, in the back, fantastic. So what we can do, we're just gonna sort of put that number of the back burner per second. We can go back to our video as it's expressed in the markup and maybe we're gonna size it down to be accessible to small screens by default. It's that sort of mobile first thinking. But regardless of that, you're gonna sort of wrap it in some sort of containing element. I've just used a simple deal with a class of video box. And so with that in place, we can then go into our style sheet and we can take that aspect ratio we calculated and apply it as a padding top to the top of that containing element around our video. So what that does is it creates a kind of ghost box at the top of that container, a padding top that's always gonna be 56.25% as tall as the box is wide. I barely understand math, so I actually had to do a quick demo to sort of figure out how this works. So I went back to the do lecture site and I kind of rooted around in my browser in Spectre. I deleted the video entirely. And I applied this lovely pink background that I spent minutes on. In fact, the time you see is actually generated with CSS. So for all intents and purposes, this is a completely empty block in the HTML. And so now though, when I resize the browser, you're gonna notice that it's so much smoother and that completely empty block actually maintains an aspect ratio, even though there's no content whatsoever in here. I think this is very neat, but this is also why I don't go out very much. I'm so lonely, guys. But anyway, this is just our foundation, right? This is just the stage on which we can set our video. So what we can then do is go back to the CSS and because we set a position relative on the container, we now have a positioning context isolated within that block. So we can just use simple absolute positioning to take that video, anchor it top left in the container and then set its width and height to be 100% of the width and height of that containing element, which has its own unique aspect ratio. So I went back to my browser and I basically deleted all the JavaScript entirely and you'll see that the result is so much smoother. We have some lightweight CSS that basically has an aspect ratio aware stage on which we then sort of stretch our video out. It's a little bit less complexity. It's a little bit less JavaScript to basically achieve the same result and it's actually much more resilient and much more bulletproof. So anyway, this is kind of a simple example of what I think of when I'm talking about laziness and responsive design. It's basically like rather than immediately defaulting to adding another layer of complexity, maybe there's another approach. Maybe there's another solution to that problem that we can sort of explore. And this has been sort of informing a lot of the work that I do on the grid level as well. You know, sort of on the macro level of layout, my responsive designs. A quick example would be from editorially. This is a web application that I worked on a couple of years ago with some friends of mine and sadly they shuttered their doors earlier this year but it's kind of emblematic of what this laziness and layout kind of means for me. So there's this dashboard based view where writers and editors can kind of come together and work on these documents. And this dashboard is basically built with a fluid grid that uses a very simple formula to translate these target pixel widths that were designed in something like Photoshop and express them in relative terms proportional to their context or to their containing element in the design. And basically once you have those two pixel based numbers you can plug them into this formula to perceive a percentage based result that will make you claw at your eyes because it's incredibly unsexy. But basically that's the fundamental relationship between that element and its container and you've now turned it into a flexible element in your design. And we can apply this to other elements like the gutters that separate parts of our grid as well. Those are target pixel widths that can be expressed in relationship to the same containing element. And we're basically left with again another incredibly unsexy looking percentage but what we can do is rather than rounding those numbers off, we can just drop them directly into our CSS and let the browser do the internal rounding for us. Target divided by context equals result. So this is the foundation for a flexible grid but there's always cleanup that needs to happen. And as I've been doing more responsive layouts with more complex interfaces I've been learning to lean on tools like nth child that allow me to sort of step back from kind of like muddying my markup up with a bunch of presentational classes and instead directly address specific parts of my document in a more flexible fashion right from my CSS. So way nth child work is basically if I wanted to address a specific part of my design I could say document cell nth child two to basically apply styles excuse me to the second cell in that grid just immediately. That probably has very limited utility but where nth child gets really interesting is when you say something like nth child 2n. Now the reason this is neat is because 2n basically allows me to immediately address some styles to every even numbered cell in this document. So whether there are 20 cells or 2,000 every even numbered one is gonna have those styles applied to it. The reason this works is because n is a counter starts from zero and increments by one each time so then it's just simple multiplication. Two times zero, two times one, two times two and so on and so forth basically into infinity regardless of the size of this HTML page. So anyway for this particular layout this three column view what I can then do is say something like nth child three n to basically remove the right hand margin from those third cells and basically ensure that every third cell is flush against the right hand edge of the design. And I can also say 3n plus one to remove the floats to clear the floats basically on every third cell but this time starting from one rather than zero to ensure that every three cells basically forms a nice discreet row of my grid to build a three column layout. Now this is an incredibly flexible approach. It doesn't work well in certain older versions of certain browsers like Internet Explorer. Sorry, I never studied theater. But anyway the nice thing about this is that you can apply some fallback style so they still get a completely flexible layout even though it might not be as visually rigorous or pretty. But regardless of how you manage that it's just some simple proportional math and a couple lines of nth child driven CSS to build a completely flexible layout without actually having to munch the markup to sort of describe the layout in detail at the HTML level. You can sort of bring it up a layer to lighten your document. Where this gets really interesting though is when you actually bring media queries into the mix. Now every responsive design that I've started with begins with this sort of baseline design that's small screen friendly by default. There aren't really any layout rules outside of the media queries. It's just one small screen friendly layout of tasks listed from top to bottom of the document. But then as the viewport gets a little bit wider we can look for areas to enhance the design with media queries. So for example as I broaden things up a little bit more I can move to a two column layout at around 31 Ms using nth child, nth child two n and two n plus one. And then as things get a little bit wider still I can maybe sort of mark up a little bit in the mast head or the layout of the mast head when I have a little bit more room. And then move to a three column layout in the body using three n and three n plus one. And so I think you can see sort of where this is going right. I mean without actually having to sort of describe the layout in my HTML at all I can basically then move to a four column layout at around 80 Ms using four n and four n plus one. The benefit to letting go of describing the layout in great detail in your HTML is that we're at a point now with the tools that we have in CSS where we can build grid systems that are effectively infinite. Responsive design isn't about taking a desktop specific design and sort of sizing it down to smaller screens although that's definitely a nice benefit. We can basically build a design that doesn't really have an ideal state. It can exist across a potentially infinite resolution spectrum which is kind of terrifying but also kind of amazing what we can do when we learn to let go of that control at the document level and we move it up just a little bit. Which maybe means that this is an ideal time to talk about the F word more specifically frameworks. Now just to be very clear I mean I think that these off the shelf CSS and HTML frameworks that allow us to build layouts very quickly have incredible utility. I mean for people that are just learning about page layout whether it's responsive or not for people that are working in large teams this takes an incredible amount of ambiguity out of the design process. But to be clear I think that these are incredibly heavy frameworks and I don't just mean from a code standpoint I mean the extra HTML that goes into describing these layouts although that could definitely be a concern. I mean they're kind of conceptually heavy right. I mean they're still very much tied to this idea of a page. That there's somehow this ideal canonical view of our interfaces and then in the document we're sort of like describing how they need to adapt at certain points. And we're always sort of working off this ideal 12 or 16 column grid and then dividing it by three or by four to make it accessible to smaller screens. And again there are benefits there but I wonder if it's not maybe the best solution for some of the challenges we're gonna be facing in the near term. I've been doing a lot of reading recently about the early days of modern animation actually. You know where we had folks like Windsor McKay and Max Fleischer basically who were really at the forefront of trying to figure out what this medium could be, what it could do. They were really among the first people to put pen to paper and then make these drawings move. So they should be commended for their work and they did beautiful, beautiful things but I think it's also fair to point out that they very much feel of their time. Right I mean they almost feel mechanical. It's hard to sort of connect with the work that they're doing. Now this is because they had a tough job. Like I said I mean they didn't have the benefit of talking at conferences about the best practices and page layout blah. But it's really about like they were really at the forefront, they were pioneering and trying to figure out what they could do. But it wasn't until a few decades later that Walt Disney founded his studios that people actually took animation seriously as an art form. Building on the work of people that went behind him, Disney and his team took these incredibly spare but expressive drawings and it's really hard to overstate the effect that they had on audiences at the time. Because once these very simple looking drawings were colored and animated, they felt real. They had this emotional quality on top of the motion that they possessed. There's this line that I love by Mark Davis who was one of the early employees at Disney Studios who said that animation had been done before but stories had never been told before Disney founded his studio. Which I'm pretty sure is the 1940s equivalent of a mic drop and then walking out of the room. But I mean he has a point right? I mean because Disney's work as a studio wasn't technically more impressive than his competitors. Far from it in fact, in a lot of ways it was actually a lot more elementary, a lot more fundamental. But when those characters came to life, when they moved from one end of the frame to the other, they felt real and they felt human. And this wasn't because Disney himself was an incredibly talented animator or illustrator. In fact he was neither of those things but he's an incredibly exacting director. And he's actually cited by a lot of his employees at this time as basically demanding of his staff drawings that possessed a caricature of realism and illusion of life. Which I think is a beautiful line. You know from Disney for all of his faults, I mean that's really kind of poetic. In fact there's this wonderful book that I'd highly recommend reading called The Illusion of Life which was written by two of Disney's original animators, Frank Thomas and Ollie Johnston. And in it they basically tried to distill what it was that worked about Disney's formula. And it went beyond the technical, right? I mean it wasn't just about process or how they executed on these drawings but really it was about these principles that they all used to talk about the quality of their work. Now I don't have audio so I can't really play this video in great detail but these 12 basic principles of animation were incredibly powerful. I'd recommend checking this out at some point. Because the nice thing about each one of these principles is that it was basically shared vocabulary. So as the animators were sort of reviewing some work on a feature film that they were working on they could basically ask themselves if a character had enough squash and stretch as it moved from one corner of the frame to the other. Or did a character's arm properly anticipate the action that was about to happen when they were about to throw a ball from one person to another. In other words, this is a framework but not in a web prescriptive sense of the word when they're thinking about a checklist of terms that need to be hit to actually produce quality work. But it was basically a vocabulary that they could all share, a philosophical framework. One that's so much more lightweight than I think we currently have on the web. And I wonder if we might be able to do the same thing. Can we have a framework that's less focused on how we execute and talk a little bit more about the quality of the work that we're doing, especially as we're thinking about adapting our work to different media and to different interfaces. Because it's absolutely true, we have a lot of challenges working on the web. Thinking about how we need to adapt to different interaction models and different device classes, but I think we're kidding ourselves if we think the web is the first place that's had to deal with this. Print designers have been dealing with this for years. Last year, the Whitney Museum actually just rebranded and they came up with this beautiful minimalist arching logo of the new responsive W that they called it. And then they went on for like five paragraphs to say this had nothing whatsoever to do with the responsive web design. That was some weird geek thing. But it's this incredibly evocative thing as simple as it seems, but it's also infinitely flexible. It can incorporate other pieces of artwork from upcoming exhibitions at the museum. It can also be encountered at various physical locations in the user's day. So as you're looking at all these dozens or maybe hundreds or even thousands of different applications of this one flexible logo. You'd probably be forgiven for thinking that there's some like computer bleeping away in a broom closet somewhere with some incredibly complex algorithm, producing all these pieces of work, but they actually came up with a very simple framework for designing this very flexible logo. The designers basically then went on to say that given any fixed piece of paper, there were probably certain elements that had to be incorporated that the logo had to encompass basically. So given the available remaining space, it was just a simple matter of dividing that open space into four equal quadrants. And that's just a matter of connecting the dots. Top left to bottom right, bottom left to top right. It's almost elegant, right, as simplistic as it is, but they went on to iterate over this to create millions of different interfaces for this one simple brand. This is not a new problem. Karl Gerstner, who was a Swiss designer in the middle of the 20th century, spent a considerable amount of time talking about this very specific problem. And his solution wasn't to think about the constraints of the page that he was gonna be printing on, but rather to build frameworks that could do that work for him. And he has this one wonderful quote that said, instead of solutions for problems, we should be looking for systems that support solutions. For no problem is there an absolute or perfect solution. And there is always a group of solutions, one of which is the best under certain conditions. So in other words, moving beyond these sort of off the shelf frameworks that do this thinking for us, we should develop a vocabulary maybe to talk about how and why we need to be building more flexibly and how these interfaces need to adapt in a more responsive manner. And this conversation's already been starting, which I think is incredibly exciting to see. Nathan Ford wrote this article for a list of parts some time ago, talking about not just why and how our designs could adapt, but also what constituted a well-formed graphic design. Well, that's very exciting. The three words you'd least like to see is keynote quit unexpectedly. It's the best and worst part of my day. Keynote. So what's been really nice to see about that is, he started to have this conversation about basically moving past this notion of these fixed and flexible, 12 or 16 column grids that are incredibly rigid and very regular. And instead, basically moving into something that might be a little bit more ratio driven, that has its own sense of rhythm and its own sense of pace. So basically moving away from this 12 column notion to something that actually feels movement from one end of the viewport to the other. But what I really liked about Nathan's article was this focus on articulating how and when these more content-driven approaches to responsive design need to adapt. And to do so, he actually borrowed a lot of language from graphic design, right? Looking for areas where the design starts to lose integrity. For example, sevens might start to manifest, where there are these unsightly gaps that appear beneath key elements. Or maybe drifts that appear where elements start to become a little bit removed from their related content, where the association starts to get lost. Or where pinches start to occur, which is kind of the inverse, where elements start to collide with each other to create a kind of a confusing hierarchy. These are the kinds of frameworks that we need as we're talking about designing these interfaces that aren't just for tablet, mobile, and desktop, but that really are prepared and ready for the designs that we don't necessarily have and the devices that we don't have on hand for the next few years. In other words, making our designs fit to the devices we have today is kind of the baseline. It's kind of table stakes, really. And we need to be looking for ways to articulate how our designs need to feel at home, regardless of the size of the display, regardless of the interaction model that happens. And so for me, more and more, it's been getting back to this old idea of this network of content, right? Moving past this notion of a page and designing these small little interface pockets, basically, these small layout systems that can basically be rearranged at any screen size to best convey a message. Now, each one of these little layout systems are effectively self-contained, right? They have their own rules and their own needs, kind of independent of everything around them, but they're also loosely bound to and aware of the other elements on the page as well. As a quick example, here's a masthead. I just took this from editorially. So this is a layout system that has its own adaptation requirements. And it looks like a fairly traditional toolbar until you fall below a certain point, at which point it dramatically simplifies itself. It's the same content, it's the same information, but basically the interactions change a little bit. So instead of pull out menus, it's basically takeover panels that might completely overlay the editing experience. But in terms of how we were building this, it was basically a matter of sort of sorting this into a couple of discrete buckets that we could sort of move around the design as it adapted, right? So we started from this simplistic view, and then basically once we had this in place, we could use simple absolute positioning in our CSS to take those five or six tasks on the toolbar. And above a certain break point, just basically shunt them off to the left to the right-hand side when we had a little bit more space. But it's not just about jockeying elements around once we can do so, it's really about taking advantage of the space available to you at any point in the resolution spectrum, large or small. So for example, we could look for opportunities to promote elements out of submenus by default and position them up in the center of the toolbar to make them a little bit more prominent to make better use of that space. Now the other question that I often get when people are looking at my CSS, in addition to why God did you do that, you're terrible at everything, is really, it's like, where do these break points come from? Why 50Ms? Well that's really driven by the needs of the content within this one particular layout system. Because below that 50M threshold, that central piece of text you see on the toolbar starts to get clipped by the buttons on the left and the right. So that makes a natural threshold for us to sort of maintain that simplified view of the design until we get above that. In other words, use media queries not to basically make your designs fit on specific screen resolutions, but to defend the integrity of your content. Looking at the needs of those small layout systems and thinking about what's gonna make them most pleasurable to read and interact with as best meets their needs within that little pocket of your design. Because once you do so, once you actually start focusing on these individual modules, things get a lot more interesting. Probably none more terrifying though than responsive navigation. Because there's a lot of experimentation happening with responsive navs right now, and there's actually no one best practice, which is probably a good thing, right? Because I mean, I think navigation needs to be kind of idiosyncratic. But there are some patterns popping up out there. For example, 538.com, a beautiful responsive site. And they have those sort of pull down menus that appear on wider screens to tease the content in each section. But those are seen as just a widescreen only enhancement. Below that point, they're not critical to the experience, so they just really sort of limit things to the primary navigation alone. Walmart.ca, responsive e-commerce site launched last year. They basically sort of took this off canvas navigation approach, right? So by default on widescreens, they have the navigation apparent to all, but below a certain point, you have to toggle an element to bring the navigation into view from off sides, right? It's like it's waiting in the wings, waiting to be invoked by the user. Editorially actually borrowed a similar version of this on a later version of their MAST head. So on regardless of the size of your screen, you can sort of tap on this top left element to bring in additional tasks and information that may not necessarily be critical to you at first view, but then you sort of bring them in when the user's ready to work with them. So like I said, a lot of patterns, a lot of experimentation happening out there right now, but there is actually one sort of common element that I did want to call out, which is specifically the element that you're using in each one of these navigation elements to sort of work with the nav itself, which is colloquially known as the hamburger. Now the hamburger's actually a wonderful little thing. It's very compact, which I think is a lot of its appeal. It's these three simple bars that are easy to work into your design with Unicode or SVG or what have you. But I'm here to suggest today, maybe that this pattern isn't our best approach. This one particular symbol, in fact, I think we might have a little bit of a hamburger problem, guys. Maybe we need to talk about this. You know that just because this is an established pattern out there right now doesn't necessarily mean it's the best one for our work. Because actually this pattern does actually have, this icon has a very real meaning to it, right? It's actually the Chinese trigram for sky or heavens, which seems like a weird arbitrary choice for tap on this thing and we will show you directions to our restaurant, but you have a very high opinion of your Yelp reviews, I guess. But there's also some suggestion, though, that this symbol might not necessarily be immediately apparent to our audiences, right? Time.com recently did a responsive redesign and they sort of adopted the ubiquitous hamburger. I miss English sometimes, but anyway, on first view of this responsive site, there's this overlay that appears to explain what this icon actually does for you. And if you have a mouse available to you, you can sort of hover it over the symbol for a second and it will also tell you what this icon does. In other words, this is a hamburger that has like seven levels of help text, which I didn't work on this redesign, I don't have any data to support this, but this suggests to me from the outside that maybe this symbol didn't test especially well, which is not necessarily an indictment of the hamburger, but if you're gonna use some sort of icon or some sort of symbol to actually, you know, describe what this functionality is, you know, maybe you should make sure that it's tested. Otherwise, you might be introducing a single point of failure in your interfaces. But I think there's a larger problem here that we need to acknowledge as well. Disney also has a beautiful hamburger and they make very effective use at it, but actually if you sort of interact with it and you get below a certain point and you bring in that off-campus navigation, you're basically gonna find every single link that's ever existed on the World Wide Web. If you were looking for that Lycos page you designed in 1997, I saw it run past, which is basically to suggest that because we have the ability to conceal navigation, I think we need to be very careful that we're not abusing that ability, right? That we're presenting this wonderfully immaculate first view of our interfaces, regardless of the size of the screen. But then they tap on that hamburger and they bring in that navigation and they basically show us all the content that we didn't wanna deal with in that redesign at all, right? So this is kind of a reminder that we need to be designing for mobile first, regardless of whether we're designing responsibly or not. We need to take these screens that are 80% smaller than what we're accustomed to designing for and make them our foundation. Ask ourselves, you know, those hard questions. Does this actually sort of clutter the mobile experience if so, you know, maybe we need to have a conversation about the value it has to any of our users rather than simply shunting things off to one side. Because once we do so, I think we open ourselves up to some really new and more exciting options as well. You know, because we should look for these opportunities to be maybe just a little bit lazy and conserve our efforts for some interesting design challenges that might be around the corner. Because I've been working on a number of them recently for more interactive interfaces and animation has actually been a big part of my work in recent months in a responsive context. As a quick example, you know, here's a circle that I designed recently. Thank you. More specifically, this is four circles. So I've been doing these like really heavy interaction rich responsive web apps lately that have to work on a variety of devices over a variety of network conditions. And so, you know, even for simple mundane tasks, so it's actually valuable to spend a little bit of time investing in animation that can maybe, you know, sort of increase a little bit of visual interest. And I hate to use the word fun, but sometimes it's desperately needed. So this is a sort of an anonymized version of an interface that I worked on recently where you select from a list of four items and then you confirm or cancel out of your choice. Now we spent a considerable amount of time thinking about what this animation scheme could actually be. There was some paper sketching and some lightweight prototyping that happened, but basically it sort of broke down into this three step process, right? So from a list of four options, we basically select one and then it moves into the second position. And then at the same time, we have a confirm and cancel button that appears. And then all that basically just sort of happens along with some animation sexiness. All the kids are talking about it. But the key thing to remember though is that when you're building situations like this, we need to begin not with the animation itself but actually think about the transaction that we're trying to support. If somebody doesn't have the benefit of animations or they don't actually see the interface as you and I might, you know, what is it that they're trying to achieve? Are they trying to read content? Are they trying to select from a list of four items? Well for something like this, the foundation for this transaction, a selection from four items, is really best expressed in terms, not in terms of moving circles around on the page. This is our end goal. And this is our foundation, some simple radio buttons with some foreign buttons basically beneath it to confirm or back out of the choice. So with this foundation in place, what we can then do is actually start to embellish it a little bit, right? We can layer on a little bit more complexity. So for more enhanced browsers, we can basically then hide those radio buttons excessively, set them to occupy as much of their rows as they possibly can and then basically round off all the elements to turn them basically into simple circles. So now we've moved into something that feels a little bit more like where we're trying to end up, we're not quite there yet, right? We have two separate rows rather than all the whiz bang movement but just like the first step of the radio buttons, this is just the next, that's the foundation for the step that follows it. So with this in place, what we can then do is basically check to see if the browser can handle animations, right? We run a short little modernizer style test and if it passes that test, if it's sufficiently capable, then what we can then do is append a class to the HTML element to basically quarantine some additional styles to then lay the foundation for the next stage of the design. So from these two rows, what we can then do is in certain qualified browsers move into that single row layout and position the bottom row over the top. And then we can use simple transforms and opacity changes to basically take the buttons themselves and sort of shrink them down into zero pixel, nothing width elements and so effectively hiding them from view. Now we actually want to reuse that animation for any element that hasn't been selected by the user, which is where the second rule sort of comes into play, which looks a little bit intense but basically all we're saying is that if our form has a class of selected, hide all the elements that don't have a class of checked. In other words, the JavaScript doesn't need to worry about the animation scheme or anything like that. It doesn't move a single element, rather it's just worrying about simple state changes. Has the user made a selection? If so, then it's going to apply a class of selected to that element and also apply a class to the form to signify that there's been some change in the internals. So with that in place, then we can actually finally finish this off, right? We can apply some simple transitions and actually apply some transforms to move elements from their default position into that selected place. This looks kind of complicated, but basically all we're saying is that we understand the second element in the row of four is our terminal position. And then any other element in that list of four basically needs to move by relative units of 100%, along the x-axis, plus or negative. So once that's done, basically all the JavaScript needs to do is apply a selected class when selecting a radio button and it moves that element into view. And because there's been that state change on the form itself, we can then basically move the buttons into visibility, allowing the user to back into or cancel into or confirm their choice. Now, maybe it's the early hour, but I'm seeing a lot of cross-darms in the room because I realized I'm not talking about one interface, but rather three, right? You know, I've started from a very modest foundation into something that looks a little bit more embellished before finally proceeding onto that final stage of the UI. And it feels like maybe the opposite of what I was saying before, right? You know, that I thought you should be looking for opportunities to feel lazy and why am I doing three times the work? This sucks. But the thing is that I think, while this seems like a little bit more effort, I think this is an incredibly lazy approach in the long term because every well-crafted responsive design needs to be device-agnostic by default. And device-agnostic means a lot of things to a lot of people, but Trent Walton, who I mentioned earlier, talked about this idea of designing for a web that's kind of hostile to design in general. Thinking about browsers is kind of allergic to preserving the quality of our designs by default. And that layout, more than anything, is just the first step in the process. We need to be prepared for that slow, volatile network and build sites that basically perform like cars in extreme heat or on icy roads that are basically built to face the reality of the web's inherent variability. In other words, I think this is something you see basically on any responsive design at scale. You know, the BBC have been doing this for ages where they have all these wonderful UI niceties in place like expandable menus and images and secondary stories. But it's also worth noting that this is just one view of their design, because by default, those simple, you know, those expandable menus degrade down to the skip links that bring you to the bottom of the page where the menu resides by default. And then those images aren't actually loaded by default on that simpler view of the design. You still have access to the content, but the experience around that is slightly different. And so this is a serious investment in progressive enhancement, right? They have this basic view of their interface that's served to everyone and then conditionally enhanced up for those browsers that can handle it. And the reason they're able to do this is because they load only enough code to see if the browser can handle it. You know, just cutting the mustard, they call it. You know, so if you support a sufficiently high number of modern DOM features, we will then bootstrap the rest of the interface. But by default, you're left with a responsive design that's incredibly fast and also incredibly accessible. This allows them to let go of that need to perfectly control the experience on an almost infinite number of devices and platforms, right? And instead they can think in terms of broad experience tiers. In other words, I think this is an incredibly lazy approach. I'd like to applaud them for it and also maybe invite you guys to sort of look into it as well. There's this one wonderful concept in Buddhism of this thing called the beginner's mind, right? Who basically says that, you know, whenever we're presented with a new problem or even if it's a problem that you've encountered before, we should try to disabuse ourselves of any preconceptions, right? We should try to approach that challenge for the first time, with the eyes of a child or with the eyes of a beginner. And I think that, you know, this is a wonderful reminder. You know, working on the web every day or even just, you know, being part of a conference like this, you know, we're surrounded by some of the best minds in technology and in design. And I don't know about you guys, but I definitely feel inspired. I definitely feel like a beginner. So I'd just like to urge you guys to maybe go forth and look for those opportunities to maybe do a little bit less in your responsive designs from time to time. To remember the patterns and frameworks can definitely be a help, but also maybe there's snapshots of the web as we understand it today. Maybe a little bit of laziness is what we need instead. So with that, I'd like to thank you very much for your time.