 I'm going to press the next button to see if that works. Woo! Good morning. I am insanely, incredibly excited to be talking today about mobile Drupal. My name is John Albin Wilkins. I've been using Drupal for about six years now. Follow me on Twitter, all that stuff. I've done a lot of stuff in Drupal, but today we're going to be talking about something that's pretty new. And that has some interesting challenges for us. So, the path to mobile Drupal. Techniques, tools, and failure. These are all essential ingredients. Basically, the alternative title to my session was the Wile E. Coyote Method of Mobile Development. Now, I hope you all, everyone in London knows who Looney Tunes is, otherwise my analogy doesn't work so well. But Wile E. Coyote, he's insanely passionate about his goals, right? He wants to get the road runner. He knows exactly what he wants. He's inventive, comes up with lots of different ideas. And the only problem is that every once in a while they explode in his face. But this is exactly the same way that the entire web industry is experiencing mobile development. It's all completely new. We're trying lots of different things collectively. And not everything works, but it's going to be all right. So, the only thing is that I don't have just a second. And of course, we're Wile E. Coyote, right? We're trying to figure things out. So let's talk about the traditional way that you would do mobile development. People have been actually developing mobile sites for nearly 10 years. The first mobile browser was on some crazy Nokia or something like that. Back in the very late 90s. And the way that they had to do mobile at the time was this. The request comes in. You detect what kind of browser, what kind of mobile device you have, and then you redirect to a completely different site depending on what browser. So you would have a mobile and desktop site. The good news is that Drupal can handle this pretty easily. Too many gadgets up here. You can handle all of this stuff with a single Drupal installation with a multi-site setup. And here's some of the modules that you can use, which would actually help you out if you want to go this route, which is the way people have been doing mobile sites for the longest time. The first thing that you think of when you think of multi-site setup, I hope, is domain access. This is a module that was developed primarily by a co-worker of mine at Palantir, Ken Rickard. Domain access allows you to control, to have content that is shared by different domains. So you can have a single piece of content that publishes both to the m.domain and the ww.domain. And this is super useful, super powerful, highly recommended, and it doesn't get enough talk when we talk about mobile development. There are other modules. There's a Wurful module. Wurful is an interesting beast. It's an open-source data collection, basically, where they've gone through and they've found as many mobile devices as they can and they've documented all of the capabilities of each of these devices. So when a request comes in, the Wurful can quickly figure out, okay, I happen to know what the name of this device is, but here's all of its capabilities. And it allows websites to group devices based on capabilities and respond to those differences in capabilities. Very powerful. There's a brand new Drupal 7 dev version of this out. I've actually just became a co-maintainer of it to try and help get it to have better performance. And then we also have mobile tools. There's actually a session by the mobile tools maintainer, Tom, and he's going to be giving a session at the end of the today. And then theme keeping and mobile keeping, these are also really useful things. I'm not really going to talk about them. I just wanted to sort of give you some tips and some options for the different things you can do. So the big thing that we're here to talk about, of course, is responsive design. Where the traditional method was, I mean, it was hard because there was two separate websites you had to create. And most people didn't want to do that. It was the pain in the butt. So, Ethan Murcon, last year, developed this technique, and it's really been a godsend. It has allowed people to think about mobile design in a way that they didn't want to think about before. There's a single source of HTML that literally the layout responds to different size browser screens. And we can see here, this is an example from Hicks Design here in the UK. This is a really great one. The layout is completely flexible. So, yeah, this is the sort of seminal article on responsive web design on a list apart. I highly recommend that you go and read it. It's available for free, of course. And he also actually went and wrote a book that just came out this past June. Really inexpensive. I really recommend that as well. But the three components that Ethan said are sort of mandatory about responsive design is versus a flexible grid. And what this means is that we've been doing grid designs for a couple of years now, but of course they've been fixed at exactly 960, for example. The 960 grid system is a famous example of the grid system. But these are all based on the width of the browser. So, flexible grids, the first part, flexible images. These are images that scale with the grid. And then the third part is CSS3 media queries. Today I'm going to give you sort of some tips about different stuff with responsive design, how you integrate it into Drupal. We're actually talking about big picture stuff. Because at a simple level, responsive design is just a layout technique. But there's some really interesting implications we're going to talk about later. So, as an alternative responsive design, though, a lot of people had some issues with it, especially the responsive images, the flexible images part. Because they said, well, you've got this big image, you're having the browser resize down to small, this doesn't sound like a good idea, right? So, one of the great things about the web is that we have people challenging the ideas that people put forth. This is with the biggest challenge to responsive design and adaptive design. Basically, instead of... Well, it still uses CSS3 media queries in order to do the different layouts. But instead of flexible images and flexible grid, it uses fixed layout sizes. So, these three pictures are the only three layouts at that exact width that you will ever see on any mobile device. This can be really useful for very specific use cases, especially if you have an existing site that you're trying to create to be more responsive. Adaptive design can help you out there. We're going to be talking about the differences between adaptive responsive and why I think that responsive is actually a much better place to start off. So, flexible grids. How do we actually do this? It's actually not that hard. We just use percentages to set the grid size. That makes sense. So, for example here, we've got a grid-wide layout that we've decided to use here and our content. We're going to make that be five grids, and that's this percentage, and we're going to make the sidebar be three grids. At a simplistic level, that's all you need to do. The percentages allow you to grow and shrink depending on what size. Ethan came up with this great formula that's really simple, and he talks about it in his book. Target divided by context equals result. With this formula, you can create and figure out what are the percentages you actually need to use when you're writing your CSS grid style sheets. We've got this eight-grid example. So, in order to figure out what those percentages were up in the top example, I just said, okay, my target is the piece of content. It's the div that I'm trying to figure out right now. And my context is its container. So, here the content column is inside sort of the page, right? And the page is eight grids, and my content column is five grids. So it's just five divided by eight, 62.5, it's that easy. And you can do this with, let's say you had an image inside your content that was three grids. So now our context is the five grids of our content area, and our target is the three-grid-wide image. So three divided by five, and that would give us 60%. So 60% is what you would assign to the width of the image here. Really pretty straightforward. This formula also allows you to convert Photoshop into responsive designs, because Photoshop, of course, is fixed pixels. So, let's say we've got a design, it's 960 pixels. I go and measure and see, okay, my content is 600 pixels wide. I don't know exactly what percentage that is, because Photoshop says 600 pixels. 600 pixels divided by 960, boom, we're done. Super powerful formula, really easy. I just love it. Flexible image is actually even easier than flexible grids. This is, as far as I know, the only thing that you need to have this exact rule in your style sheet, and you have flexible media, right? So we've got image, I'm frame, object, video, HTML5 tag, of course. And you just set the max width to be 100%. So, what that means is this, let's say we've got an image here that's smaller than its container. It'll just be the natural width, right? Because max width says it can't be any bigger than its container. And then for images that are bigger than their container, they get sort of trapped inside their container. So they'll be scaled down to fit inside their container. So let's start talking about CSS media queries. With CSS2, there were media types, right? We all use them, especially like the print media type. And basically, we started ignoring screen and mobile and all this stuff, and we just used all most of the time. And the reason for that was because it turns out that trying to target different classes of devices was a way that CSS2 media types were written. It didn't work so well, right? What does it mean to have a handheld media type, right? An iPhone is way different than an iPad, different than like the 80 billion Android devices that are available. You don't really gain that much information by saying, I want to establish a handheld device. So we very quickly discovered that these weren't that good. And CSS3 then provides a mechanism for us to instead of thinking about device classes, think about device capabilities. And the most popular ones are going to be our max width and mid width. It was CSS3 media query. You start off with the... That is very bright. You start off with the media type from CSS2 and then the parentheses with your actual query, what you're trying to let the browser figure out. And here's an example, max width 768. So if the viewport is 768 pixels or less than any CSS that's included with this query will apply to it. And if the viewport is bigger than 768, it just won't apply to CSS at all. So with Drupal, of course we have .info files where we add our style sheets into our themes. And right there, line 52, we have the all, that's the CSS2 media type. Well, it turns out Drupal already has the ability. It's like a CSS3 media query right there in that place. And it'll work just fine. But it turns out that's actually not that good of an idea. You should really move all your media types and queries inside your CSS files. So instead of doing it at the .info file level, move it into your CSS file. And say, you know, add media all mid width, and then you're really bracketing around the CSS rules that you want to apply to that media query. And the reason for this is because of CSS aggregation. I hope everybody remembers to turn on CSS aggregation before you move a site to production, right? CSS aggregation, of course, takes all of the CSS files and tries to combine them into as few files as possible. And if we use media queries inside our .info file, it will require a separate file for each media query that was used in the .info file. If instead we use all in our .info file and put the media queries inside the CSS files, we can still aggregate all the files into one file. Of course, this helps with performance tremendously. I like this idea so much that I think I'm going to file a patch for Drupal 8 to get rid of the media types and queries inside .info files because they're just not going to turn out to be that useful anymore. So the next thing we're going to talk about are breakpoints, right? What a breakpoint is, is basically, you're watching that animation of Hicks design as the viewport shrank, right? And then there came to be a certain size where suddenly the layout switched around, right? That size is what's called a breakpoint in responsive design. And there are sort of, there's basically two kinds of breakpoints. There's device breakpoints and design breakpoints. Here's some examples of device breakpoints. These are breakpoints that are based on, you know, current devices that are out there. 320 pixels is your iPhone. I mean, portrait mode, 488. 480 is it in landscape mode. 768 is iPad, you know, this direction. 992, sort of a small laptop. And 1200 is just sort of a large desktop. These are based on existing devices and you can set up these breakpoints so that they'll sort of match the dimensions of devices that are in your systems. And the other kind is actually a design breakpoint. A design breakpoint is when you start sort of squeezing your design, right, inside your browser to test things out. And you notice, hey, the nav bar is getting a little too close to the title here. I don't like the way that looks. I should really do something about that when I get to this sort of certain width. And that certain width, that's your new breakpoint. You basically set a new breakpoint to say, there's a spot in my design that I need to change things the way the layout works or change the way, you know, the CSS works so that I'm pushing things apart to make sure there's enough room or changing the size of something, making sure the design is still coherent. And those are sort of the design breakpoints. And really, I wanted to call these something else. Basically, these are unnatural breakpoints and natural breakpoints. Natural breakpoints, these are breakpoints that are determined by your design. These are completely organic and intrinsic parts of your design. And unnatural breakpoints are completely determined by outside things, outside devices. And the thing is that these device breakpoints that I've listed here, they're only good, you know, like this year. What happens when the iPad 4 comes out? I have no idea what the dimensions are going to be, right? The iPad 4 might be out like next year, I don't know. But if you're designing a site and it's going to come out later this year and you're basing it on devices that are out right now, you're going to be wrong. Those devices are going to go away, new devices are going to come in, and device breakpoints, they really are unnatural. So let's look at responses and adaptive again one more time. So responsive design was just flexible grids, flexible images. They didn't really say a whole lot about where our breakpoints should be. But adaptive design is like, there's a certain fixed set of ways that the design will look and they're fixed width. And those fixed width designs really, they do sort of align with device widths. And the thing is that what's going to happen if you start going down the adaptive design route is that you're going to design these layouts that look great on the certain devices that you were testing and the next year a new device is going to come out and you're going to have all this extra space on the left and right of this particular device because your designs just happen to be like, two pixels off or something of the designs that you created. And this device is two pixels smaller than one of your adaptive layouts. So I really feel like responsive layout has a lot more power and it's sort of forward thinking, right? And the other thing to think about with responsive design is start untethering your designs from these devices, right? Your design has intrinsic breakpoints. It has an intrinsic way of how it wants to work for the user, how it wants to lay itself out. Go with it. Follow those natural breakpoints. Follow the way that your design wants to be. Don't worry about the devices because the devices will change. It doesn't matter. Do what your design says to do and be damned with the iPhone. So let's talk about... I should check and see what time it is. Everything's all... I have no idea what time it is. Thank you. That's my phone. Oh well. One of the things... I've been doing web design for a really long time. So it's like 1994. And meta tags were the scourge of web development for a long time there because everybody was just pumping like 80 billion keywords into the meta tags. And I just hated them. But you have to start using some meta tags for mobile design. There's just no way around it. But the good news is that they're not evil anymore. It's not so bad. And the reason why you need to use some meta tags is because... Well it's kind of our own fault actually. Remember what I said, CSS2, media types were kind of crap. So we basically ignored it and always used all. So when the mobile device makers came and said, hey I want all these websites to work on my phone. The problem was that they're 300 pixels wide and everybody's using 960 grid. That's a lot of horizontal scrolling. It's awful. So the trick that they came up with is like, hey, I'll tell the browser that actually the viewport is 980 pixels. That's what the iPhone does. It pretends that the viewport is 980 pixels and then basically allows the CSS and everything to sort of squeeze into the dimensions of the device. But of course if we create a special mobile design, a responsive design, it's still gonna tell the browser that is 980 pixels wide and all of our media queries will think it's on a big 980 pixel size screen and our responsive designs won't work at all. So the solution to that is with some meta tags here. This first one here, the viewport meta tag is the most important one. And this first section of it, basically inside the viewport you have a list of sort of variables that you're defining separated by commas. The first one is width equals device width, right? And that says to any mobile browser that understands this meta tag, don't use what you normally use, you know, the thick viewport size. Use the actual devices width as a viewport width. Our CSS, our web page is smart enough because we have this meta tag in here. Trust us, we'll display it fine. The next section that's also useful here is initial scale equals one. Some browsers will zoom in or zoom out depending on sort of the defaults. Initial scale equals one means basically don't zoom to start with. But you can go ahead and if the user wants to zoom and pitches zoom or zoom out, go ahead and let them, it's fine. But start out sort of one-to-one. And this last one here is something I actually learned just like about two weeks ago. Target density equals 160 dpi. And the reason for this is actually it's necessitated by all the different Android devices that are out there. But it's going to continue to be useful for new devices because all the Android devices have completely different pixel densities, right? 72 dpi, 144 dpi, 160, 240 dpi. And if you set your font size to be, you know, 30 pixels on some of the Android devices, you're not going to be able to read it. It's going to be so small. And on some of it, it's going to be like way big and destroy your design. So Android has set up this target density dpi addition to the viewpoint meta tag that says, okay, if you set this, and you can set it to be whatever you want, but 160 dpi is a good default for Android devices, it'll emulate 160 dpi, no matter what the actual dpi is on the device. And this will make your font size to be consistent across all these devices. And I'm sure that other devices are going to come in and start using this same thing just because actually this original viewport tag was just an iPhone specific thing and now other devices are using it. Target density will become just like that. I'm positive. What are these other two meta tags here? These are sort of similar things. I think this was for IE mobile, and this is like Mego or something. But basically, if you have all three of those in there, they do the same thing, and you'll cover all of the bases for all the mobile devices that are out there. It's good to understand this stuff, but you don't really have to think about it again. Take them in there. The latest version of Zen 5 or Drupal 7 has these in there already. So, browsers that don't support CSS Remedy queries. This is inevitable, right? This is a new technology. It's been around for a while, but it's still relatively new. And of course, there are two types of browsers that don't support CSS Remedy queries. How many people want to guess what the first type of browser is? IE6, you said? It's shocking, right? IE6, 7, and 8, they do not understand CSS Remedy queries at all. They'll just see it and they go, I don't know what that is, and it'll ignore all the rules inside it. I mean, as far as ways that IE6 can completely screw up, that's actually a pretty good one. It just ignores all the rules, right? It could have go, oh, I'm going to apply them anyway. That would have been bad. That didn't happen. Thank God. So it just ignores all the media queries inside it. There are a couple ways you can get around it. This is the one that I recommend, because it's just so damn easy, and it only penalizes IE6, 7, and 8 users. There's a JavaScript shim that you can add called respond.js. And I get it all the way here. It's trying to get the URL and I keep walking in front of him. Respond.js and if you add this inside a sort of conditional, an IE conditional comment, then that.js only goes to those browsers. You can see an example of this. You download Zen and look at the HTML TPL file. It has it hard-coded in there. You can use that in any of your designs. I really recommend it. It's easy. You don't have to worry about too much. So the other type of device is the other type of a thing, and it's called the IE query. It's sort of limited device browsers. This is a sort of mix of just some underpowered new devices and old devices that are just out there. Right? And there's only really one good solution for this, but it's a great solution. It's called mobile-first. And the idea is that since the browser is going to ignore all your midi queries, you need to have at least one layout that's not inside a midi query. You need the mobile design, the narrowest design. The iPhone, the 320 pixels, whatever. Use that first. If that's the default, it doesn't matter if the browser doesn't understand midi queries because it's going to get a mobile design and it's probably going to be the right design. Right? Since we're letting IE 6 through 8 actually read the midi queries using this respond.js, we don't have to worry about them as far as desktop browsers go. If the browser out there is mobile, so just do mobile-first. This is a super powerful idea. Right? Make the default layout be for mobile. And it's probably going to be a single column for the most part. And basically, the thing that's interesting about the mobile-first approach is because it's your default layout, you start to think about your HTML in different ways. You start to think about, well, if I'm designing for mobile, you know, what does that mean? What is... I'm going to press the button one more time. Oh, yeah. It actually means content-first, right? Because your markup has to have the content be prominent. You don't want to have all this extra stuff that they're on your specific page because they want to read the content of that page. So think about your content-first and add on all the other stuff. In addition to that, there's supplemental stuff, right? But it forces you to think about your content-first. Right? So let's go take a look at... This is a typical Huffington Post. It's a desktop design, right? It's huge. It's 1024 pixels wide. This particular article... It's a video article, so like, if I've come here, I want to see the video, right? This is actually an image. It's not the video. So let's see what our typical desktop user has to do in order to get to the video. Start scrolling. See his photo galleries, who to follow, share the story, sign up for some of the other stuff. Social news, popular... I don't know, Huff reporters. Ricky Gervais. I'm going to click on that. That sounds interesting. This is 30,000 pixels worth of scrolling in order to get to the video. Why are you so mean to your users? And the thing is that this is only about a third of the way through this page. It's about two-thirds more content after this that I haven't shown you here. It's just insane. You need to start thinking about... Think about your users again. Think about your content. Focus on them and add in other stuff that's supplemental to that. I'm going to go here. Luke Roblowski. There we go. Two shots. He actually coined the term mobile first. And he said, losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business. And we've really lost sight of that before now. With our desktop designs, it's because we've had so much space, we're like, well, we've got to fill that up. Otherwise, their grid looks kind of like not a grid. I'll add 80 blocks to the sidebar. Yay! Looks great now. We've forgotten about the users. This is a really great post, by the way. If you want to read this blog post on mobile first, fantastic. So, what mobile device should we be supporting? I was going to show you my phone, but I can't find it. Okay. Also, what time is it? I want to make sure we don't go over. Half past. Let's look at about five more minutes. I want to get questions and I want people to have discussions about this stuff. So, this is actually kind of the wrong question to be asking. Because here's a support grid from query mobile people. Shows all the different OSes, mobile OSes, and the different browsers that are on them. This is a lot of devices. And, actually, I didn't show you the whole thing here. So, we got to scroll out and look at the rest of this here. This is crazy. You remember great-aid browser support? You're not going to be able to do this with mobile devices. You're basically just going to have to pick a couple and think about your design responsively and just hope that it's going to hit all these other devices. And when you find bugs, get actual bug reports, go ahead and fix them. But, it's kind of sad to say, and I really, really hate saying this, but one day soon, you're going to miss the days of IE6. The thing is IE6 is awful. It's a devil. But it's a devil we know. Mobile is a whole new beast and there's so many more browser devices. It's going to be hard. And he will lament and wish it was just IE6 again. But don't worry. We are in this together. We're going to figure this stuff out. The best thing is that there are all these other developers here who want to learn the same things you do. And they can help you with your designs. You can help them with their designs. There are lots of people trying to figure out ways to actually sort of do better mobile browser testing. And we'll just have to learn as we go. Yeah, don't panic. One of the powerful things about Drupal is its ability to fail. Fail often because there's lots of different modules, lots of different themes. But the good news is the sooner we fail, the more we fail, the sooner we're going to succeed. I got a picture up here of Hindut 7 ketchup because this is the 57th recipe that they came up with. The first 56 were complete crap and 57 was the one they finally ended up with. So if we want to figure out responsive design, you basically just have everybody in the first three rows, about 57 of you there, can you go ahead and figure that out and maybe 56 of you completely fail or you work collaboratively, one of you will be fine and then everybody else gets that for free. Zero fairies for everybody else because they just learn from you and one failure apiece is not so bad. This is a way the Drupal community works. We work on different things, we try out different ideas, sometimes it doesn't work, sometimes it works okay, we build on top of it. This is one of the powerful things about Drupal with responsive design. We're still figuring things out. We're listening and learning from the greater web development community and we're bringing those things into Drupal. We're presenting our own ideas back onto the web development community. We're learning together, failing together and we're going to succeed together. Let's start talking about some of the things that people are working on in Drupal right now. Image handling. One of the issues with responsive design is that in order to do the scaling of images, you don't ever want to scale an image up. Bigger than it actually is because it's going to look awful. That basically means that you have to have your images be as large as they can be. You have to have your images be as large as they can for your design and then you're always shrinking the images. The issue there, of course, is that you're giving large images to devices that may only ever use the most scaled down version of that image and you're also forcing them to resize it in the browser which takes some performance head. These are a couple of modules that are currently available where people are trying to think of ways to fix this problem to give images that are more efficient for the particular device. The responsive image, this is based on integrating filament groups library. There's inline images with data URIs and basically instead of having an extra HTTP request and that's sort of a network hit which is particularly bad on mobile, instead you inline the images directly into the source code and that's how what inline images, faster images module does. It adds it into the HTML source code and then this other one here, CSS and image does the same thing but for CSS files. These may not be the end solutions that we've eventually all develop or all start using but they're great starting points and these are some of the things that have been developed just in the last six months at Drupal on Drupal 7 and I'm really excited to see them. We started talking about Drupal themes, of course. Base themes are a great place to start and implement some of these responsive stuff because they're a great way to reuse the code and allow people to bootstrap very quickly when they're building their own theme. I'm actually the Zen maintainer, the Zen theme maintainer, some of you know that. I started working on a new branch called the Zenfone X5.x and I'm implementing a lot of new ideas. This is a really huge change from the previous version. It's got respond.js already in it. It's got the meta tags already in there. I'm converting it to HTML5. A lot of that is done, some of it's not done. It uses SAS. SAS is a really interesting really interesting technology. It's a CSS preprocessor so basically it's a super set of CSS that adds in some extra things like variables and stuff and allows you to write your CSS in a much more flexible and easier way and then you take those sort of SAS files and you compile them down to CSS. One of the things that happens that you can set up SAS to do is when you're compiling it from the SAS file to CSS you can compress it, strip out all the comments in there that explains why this crazy CSS is in there. It'll strip all that out. Any empty rule sets that you have and Zen has lots of empty rule sets that's sort of a framework to let you know how you can style different things all of the empty rule sets get stripped out. When using SAS with Zen in particular the CSS that actually gets included in your sub theme is very small because it removes all the extra stuff and you can still leave the extra stuff in the CSS files to help you sort of organize stuff that's going on. I love SAS. This is awesome. Responsive panel layout. So this is screenshot of a website that I've been working on this past week for Palantir.net. We're redesigning our whole sites using responsive layout. And you can see here the different ways that the layout works and this is a node page, right? This image is a field you know, these these highlights and the team those are all fields our client body tag and all that stuff, right? And we're using panels responsive panel layouts so there's one layout that we set inside panel's interface and then we move our fields into the different sections of the panel layout and then when the browser gets resized it automatically changes just like normal responsive design to be all these other different things. It's really powerful and this is one of the ways, one of the predominant ways that responsive layout is going to work in Drupal because another way that we tried was building a custom like node TPL, right? Custom node TPL put that field over there, that field over there those aren't reusable because you have to name the actual field name over there, right? And that actual name is not going to be the same on somebody else's website so you can't reuse node TPLs that have responsive design in them you've got to use some other reusable structure and we tried panels layouts I'm sure there's display suite I'm sure they'll come up with another solution for their system context would probably be something specific to that I'm looking forward to these other solutions but this is the thing we're trying out at Palantir with panels and I'm going to convert these and actually add them into Drupal sorry, add them into Zen and hopefully I'll get those in this week across my fingers but this is really great I love this stuff but of course Zen isn't the only one that's out there there was actually a blog post about terrain this is a sub theme this is a gone base theme and they have some responsive stuff in there I haven't got a chance to look at that but the fact that there are all these different people working on different responsive designs or responsive themes is great there's Omega which does responsive there's actually a session on Thursday morning about this so where can you find out more about Drupal because I've sort of given you some good tips I've given you some guidelines of how you move forward but there's a lot of stuff we don't know so you really need to follow along latest mobile Drupal news so I'm on Twitter I'll tweet about this stuff all the time because I love it Drupal Watchdog this is a new magazine that's just for Drupal issue 2 is coming out it's focusing on mobile Drupal and everybody at Drupalcon London gets a free copy I googled and found a URL we can go and download it now but I'm not sure if it works yet but I'll definitely announce that on Twitter and I'm sure that the Drupal Watchdog people will be telling everybody at Drupalcon London how to download it because they want it in your hands Palantir.net blog posts I work for Palantir.net so I'm going to be talking about mobile design there and then of course subscribe to Drupal Planet because all of the other Drupal developers are sort of aggregated into Drupal Planet and they will talk about responsive design and that's how I found out about the terrain module so of course this is the first session of the first day there's actually a lot of other stuff going on at Drupalcon London so 1pm I've got a core conversation I'm going to be talking about Drupal 8 I'm going to be talking about the responsive content and specifically with the basic page because it's one giant text area how do you get one giant text area to be responsive I'm going to be talking about that I'm going to be talking a little bit about some of you might be interested it's at one o'clock in the other building where the core conversations are two o'clock there's a Drupal module development challenge the topic is completely secret nobody's giving you any hints except for the fact that I've listed it here under this heading the 345 I've set up a responsive design BOF so if you have or you want to collaborate and start talking about different theme development, different module development related to Drupal for an hour we're just going to talk all together it's going to be lots of fun and that's going to be in room 331 and then at 5 o'clock here today bridging the gap between desktop and mobile this is Tom the mobile tools module maintainer and that's his session so all of this is happening just today it's fantastic so I guess I want to open up to questions if we have time which I can't find my phone again what time is it? it's lunch just lunch nobody needs right so who's got questions who's not scared to ask a question there we go I'll repeat the question so the question is Zen has several CSS files there's a lot of which actually I would love to talk about because there's RTL files in there and there's a lot of extra stuff that makes it look like it's not really that bad but there's a lot of CSS files and the question was do we just have to have media queries in all of these different files? well because CSS aggregation will take all these files and make it into one file so it's really ideal to have media queries in each of these files so the nice thing about media queries is that you can you realize that there's something about the node title and maybe comments that need to be tweaked based on a particular breakpoint put the media query right next to the standard CSS for that particular element it makes it easier to find it and see where how this stuff all interacts is the natural place to put it put media queries any place that you need it it doesn't matter that there's a whole bunch of different files other questions? yeah okay so that was a very long question let me try to recap the question was you know he was listening I talked about some different ways you could do stuff and I talked about the fact that you could have you know 56 different ways to fail basically waiting for the media to tell you what the 57th way was and the thing is we just have to figure it out together this is very new either Marcona's responsive book came out in June we're still figuring it out I want this to be a conversation with the entire community and I don't have the 57th answer I don't know what it's going to be and you wanted to talk about images and CDNs what were some of the other image questions? image caching one of the things that I love about Drupal is image styles as they're called at Drupal 7 are really powerful because you can on the fly resize images and we definitely have to leverage that power in our responsive designs and I've got some ideas about how we can have a one of the issues is anonymous page cache so you only get one HTML version but I have some ideas of how we can get around that and have three different HTML versions we can have and still leverage page caching not turn off anonymous page caching because it would be very bad and I know that David Strauss was talking about lower level what what are some of the extra caching stuff that you can do at the server level yeah, APC and stuff like that there are different ways that you can make sure that the caching continues to work with that stuff he's talking about David Strauss was talking about caching different sections of the page and pulling it together at different levels and all of these different performance things in order to do all of this stuff is possible and we're just figuring it out and we need help and the thing is that I would love for all of you to get involved and help and post issues and different cues and different themes and make blog posts because all of us together are gonna find the 57th solution but not me, I'm not gonna find it by myself I won't be able to find it by myself I'm sorry, I don't have the answer TH oh okay got it so he's created a base theme based on Fair enough Zensil is F2 he's created a base theme that's based directly on 320Nup THREE 20 and up oh just okay THREE 20, 2-0 UP so that's another solution I wanna see more solutions like this I went through the 320Nup source code and looked for stuff that I could put into ZEN because it's a great resource fantastic resource HTML5 mobile boilerplate is another great place to find information stuff ZEN added in that sort of funky IE conditional that's wrapped around multiple HTML tags I started to use that instead of IE conditional comments because I think it's really more natural way to develop it's great solutions I should probably let you guys go eat I've got another session after lunch anyway so thank you very much, appreciate it