Reconsideration Requests
Show Video

Google+ Hangouts - Office Hours - 22 May 2015

Direct link to this YouTube Video »

Key Questions Below

All questions have Show Video links that will fast forward to the appropriate place in the video.
Transcript Of The Office Hours Hangout
Click on any line of text to go to that point in the video

JOHN MUELLER: OK. Welcome everyone to today's Google Webmaster Central Office Hours Hangout. My name is John. I'm a Webmaster Trends Analyst at Google. And we have a special guest today, Rupert, who's going to be telling us all about responsive web design. So shall we get started? Are you ready?

RUPERT: I'm ready.

JOHN MUELLER: OK. Should I present?

RUPERT: No. I think we can talk a little bit first. Thank you, John, for the kind invitation. It's exciting to be here. I greatly admire the web trends guys. I'm a webmaster here. I've been doing web stuff for about seven years. I'm currently in prototyping, but for a long time, pretty much all of my output went into production, and hopefully you guys saw some of it. So core for us was accessibility. I mean, you know our mission statement by heart by now, I'm sure. But when people talked about mobile design, it was never really about that for us. It was just about, where are our users coming from and how can we best support them? And we were surprised to learn things like how many people came from PlayStation 3, so just making sure videos were accessible in places like that. So if I had to put a date on my epiphany of mobile design, it probably goes back about three and a half years ago now. So I was a webmaster for a few years on what then was the NORAD Track Santa site, which we did in collaboration with the NORAD guys, and we always looked through the analytics for this. Obviously, had a huge number of hits on Christmas Eve. If you don't know it, you basically get to track Santa Claus across the map as he delivers presents, and the nice thing is kids love it. And so this whole site, the experience ran very specifically. The full interactive bit happened over the course of 24 hours. And so we were always intrigued to see how people interacted with it, when was the most popular hour, this kind of thing. So we made a point, as I'm sure you do, of just constantly looking at the analytics. And the thing that came up was just slowly but surely, it coincided even before analytics did track mobile, but when it did come in, we could see a 2% hit rate, and then second rate, 4%. Well, that's almost within the standard deviation, but was that part of a trend? Could we see this doubling every year? And we actually did. So I think the second year or the third year round, it was 9%, and I think by the time I finished work on the site, it was 50-50. And more than that, quite incredible. The granularity that we would get on the analytics, you could see the time of day that American kids on the eastern seaboard would get up, unwrap their iPads, and then suddenly start hitting the website because you could see this huge jump in iOS visitors looking at the content, and it was just fascinating. That was a really good use case for having mobile support on the site because this 24 thing, you don't really want to be stuck in front of a computer on Christmas Eve or Christmas Day. You just want to maybe have something in your pocket, and you take it out and you check it once in awhile. But by no means does it necessarily mean you have to have a mobile site for everything. There's cases where it's just not useful. If you'd asked me a while back, I may have said that booking flights was one of those instances, but I'm now on the travel team, and the one thing we've found is people actually love to go through and book fights on their mobile, or even if not book them, they like to get the basic information. They may complete the transaction on a desktop site. There's less and less of a marketing site that doesn't have about half and half mobile and desktop browsers now. And so we are fairly pragmatic in the decisions we make because we know there's implications on the amount of work that your developers will have to put into generating these sites in the first place, but almost more importantly, the maintenance. What we found, even here at Google, if a site is difficult and fiddly to maintain, it just doesn't get updated very much, which is a shame. If you want visitors, you want fresh content and you want to make it as easy as possible to get fresh content on there. So I'm not as rabid about mobile first, maybe as some people, because I have to live with the consequences with what I write and what I update from that point on. But over time, I've got a few pointers. What I thought I'd do is just give you a couple of quick examples of some sites that I've worked on and tell you the thinking behind them. And I've got a document which I can share with you all later which just gives a few CSS tips to some of the common gotchas that break layout for mobile phones just now. And then open it up to questions, if that sounds OK.

JOHN MUELLER: Sounds good.

RUPERT: I'm going to break to breathe and drink. Any questions just now?

JOHN MUELLER: Not yet, I guess. That's good.

RUPERT: Hope we're still broadcasting.


RUPERT: So I'll tell you what, exhibit A, if you would like to bring up Picasa please. So this was actually one of my first mobile websites. When I say "mobile," with the kind of sites we did, we pretty much made the decision that we weren't going to go down the route of having separate pages for mobile and desktop. This is just going back to this pragmatism thing. It's just the amount of overhead to maintain these things and then having non-canonical-- am I saying that right? I know we have to say that a lot. When the URLs are different and somebody on a mobile shares with somebody on their desktop and it looks different, people don't know. So this was something that had to work on both. And the key thing for us was we've got a download and it's potentially a 35 meg, I think even more than that now, for the desktop client. And we certainly didn't want mobile users finding this page and attempting to download this on a data plan because when they get a $100 bill, they'll be complaining to us, and we don't want to put them through that angst. So the basics here was that button changes on every platform it finds itself on. So originally, we had a little bit of JavaScript that does a thing you're not supposed to do, which is actually sniff out a user agent. Maybe would you like to view the source on this?


RUPERT: And then somewhere down the page, if you just scroll up, just right there in the middle-- up, up, up, a bit further up, and then if you can highlight this section here, the three, more or less. So you can see just in the standard markup, there's three separate download links. There used to be one for Linux. Unfortunately, we've discontinued that application, but there was a separate one for the Mac, the PC, and because we don't have this product on mobile specifically, we just have a link to Google+ which is effectively our photos product for Android, and you can also download it, of course, for iOS. So that was a simple fix to a very specifically mobile problem. And so while we did this with the JavaScript. OK, let's give it a go. Let's make this page responsive. And so there's a couple of very simple things we do in this page which you know and love by now, I'm sure. Maybe go back to the view and just resize the browser, and I hope you see this in the Hangout. We have these three columns at the bottom, and surprise, surprise. They linearize. They go into one column and the topography changes a little bit as well. And so this is actually quite a pleasing thing for mobile. Then the other thing we did, the only other major change, it was the first time I did this. We had a double resolution product logo because I think when this came out, the Nexus 1 was the new hotness, and this had this outrageous, I think it was 640 pixels across, which was unheard of at that point. It was the original retina display, and all of our product logos just looked horrible on it because you could see the pixels but you couldn't see the pixels anywhere else on the screen. Now, coming back to the pragmatism, there's a lot of stuff online and there's a lot of different techniques and approaches you can do to swapping in high resolution images for mobile because of these high dots per inch displays. I tend not to do that simply because anything that's a JPEG will get re-sampled nicely bicubically. It smudges of bit but it's OK for photographic stuff, kind of like the images you see here. So you're hard pressed to see the pixels the way the anti-aliasing is done when you export these from a graphics package anyway, so I didn't feel the need to do it there. But I will quite often have larger files, usually double the standard desktop resolution for things like product logos, and what I'm increasingly doing now is scalable vector graphics, so quite a lot of SVGs. And they're wonderful because they're tiny file sizes. They're text files, so you can even hand edit them if you like. You can link them onto your page as if they were images, but you can also have them as path tags on your page and even change them on the fly with CSS, so there's a lot of flexibility there as well. So that's my approach to the images. If they need it, we can double the resolution on some, and here it's just projected to half the scale on the desktop site. But effectively, the way the pixels and the viewports work, you get it at the high resolution on the mobile. So looking at my notes just quickly, my computer's gone to sleep. Of course it has. I think I've got caffeine on this one. So I think for us, this was the early days of our mobile support, and so because we knew this was going to be a thing and because the fastest growing segment of our traffic was mobile, we decided, OK, we'll put it into our basic style sheet. And so predominantly, the kind of websites I used to work on, they were marketing sites for products, or sometimes they were marketing events, things like this. We made a decision just to keep things consistent. We have a Maya CSS stylesheet. It's not external, I'm afraid, but you're very welcome to look at it. It may be a little obfuscated, but it's basically our version of Twitter Bootstrap. It does a typography, it does a grid for us. And so the reuse of it on every site we launched was quite useful because as we added support for more browsers and more fixes for things that may have broken mobile display, we could just fix it once and all of our websites would get the fix rolled out automatically. So again, coming back to this pragmatic thing, that was easy for us because we took a decision to start building from the ground up this mobile support into all of our ongoing pages. And to be honest, we didn't make existing sites backwards compatible. Whenever they got a scheduled refresh, they would use the new style sheet and they would have this mobile support just automatically. So I think that was probably a good example. I'll give you a real history lesson here. If we go back, I think, something like 22 or 23 years, did you get the-- we can just search for it, maybe, and you can follow along at home if you like. This is worth looking at. There's a site, and if you just search for the very first web page, this is something Tim Berners Lee made in his office in CERN in Switzerland a long time ago. And if you ever get to CERN, yes, everybody tries to see the Large Hadron Collider, but attempt to go. You can see the original web server and you can also see the room with a plaque outside where the very first website was made. The first website. I think it pops up as CERN, and there's a link to that.


RUPERT: Yeah, that's it. Perfect. So if you re-size this, amazingly enough, all these years ago, and some fairly clunky code in there, but it was mobile friendly. And so the take home for this is HTML always was. If you've got a website that doesn't work on the mobile web just now, then I'm afraid you've done it to yourselves. And we've all done it because before stylesheets came along, we were dropping content into tables. So when we wanted a desktop publishing style grid, we would put it into the table and we'd prop open columns with invisible pixels to force this rigid layout. They did not lend themselves well to, say, netbooks when it came out. So even before we had mobile browsers, people with lower spec machines. There was a point where I think my computer was so old, and the websites were now setting themselves to 800 pixels width, and I couldn't see them in 60 million colors with my one megabyte graphics card. I resolutely stuck to 640, but then I was having to scroll horizontally. So I grew to loathe horizontal scroll bars. Basically, when you see that, it's incompetent web design. I'm not sure I can really put it any more bluntly than that. So my mantra as I was exploring some of this mobile friendly stuff was if there's a horizontal scroll bar anywhere and you didn't intend it to be there, then you broke something along the way, so try and fix whatever it was that was broken. So hopefully, none of us have got any legacy code that's still using tables for layouts, but what we probably do have is tables by any other name. When you see divs with classes or column or a header and things like that, we've probably made tables. The beauty of that is they're not locked into place quite like nested table cells were, and so what we do is linearize with a style sheet. I'll show you some code samples for that as well. In fact, now is probably a good time. Let's get some code. So I think there's one that's shorter, the one with the pictures of the book cover on the top.

JOHN MUELLER: That doesn't work. This one?

RUPERT: Nope, the other one.


RUPERT: Yeah, that's it.

JOHN MUELLER: All right.

RUPERT: So I have done some presentations internally. I used to have a responsive design road show that I would take people around. The core of it was actually a few simple additions to a style sheet that you could quite often put into an existing site and fix because it was usually just one or two things that would break the layout of a site. And quite often, it was an image that was inappropriately resized or a sizing that was probably specified kind of wrong. So I think if we just go section to section in this, I'll just talk very quickly through this. So the first one here, the viewport, is incredibly difficult to explain. When I ran my workshop, I used to have a cardboard cutout. I think I had a Cornflakes packet and I cut a little hole in it and moved a picture of a web page back and forth behind it. It was the closest thing I could get to explaining this, which is difficult. But all of my research and the entire afternoon I spent just trying to wrap my head around it, I just came back to this little nugget, which is this viewport meta tag. And that is the thing that stops you getting a teeny, tiny website scaled down, shrunken, as if you were viewing a desktop on a phone. You don't see that very much. It was championed by the iPhone when it launched, which had a fantastic browser. The Safari browser on the iPhone was absolutely wonderful and it showed websites like you'd never seen before on a device, but it scaled them down in a way that nothing was readable. You had to tap in, read it, tap out or tap back in again and move it around or scroll it. It was kind of fiddly. And when you're having to scroll up and down, left and right, it's so easy to get lost. You don't want to do that. So scrolling should either be just horizontal or just vertical. And frankly, people expect vertical. This is the code that allows you to default to this on your phone. So basically, you get it at a larger font size. Your 13 pixel font, for example, on the desktop would be coming in at 26 pixels probably, but about the same size as the text would appear. I don't know what is it. I'm looking at something that's probably five millimeters high. It would be five millimeters high on the web page, too. Now again, always with a caveat. This has the potential to break a site because if you do not have what some people would call a responsive layout. I would actually-- there, you can read the heading below. I tend to call it a liquid layout just to avoid confusion. If you fixed your website to a size that something's jutting out over the side, then your mobile browser will come up with these graded horizontal scroll bars that are the death of all good things. So if we scroll down a little more, these are the ways to do it. And so I would say if you remember one thing from this whole presentation, it really is this one here. When you specify a width, it really never should just be a width. It should be a max width. And so you have the flexibility built in there. That's the equivalent of what people would expect from a 978 pixels body, but it scales down when you get less than that. I'll show you a little adaption for images a little bit later, which gives the best of both worlds. And the corollary for the height is don't have a max height. Have a min height, and the reasoning for that is it looks nice when you have columns across the page. You want them to be consistent. You want them to align to the top and the bottom. People usually do that by giving a height to a container. The trouble is if you live and work in a German speaking country like we do, you'll be amazed at how long winded some of the German phrasing can be. And so what you thought would look great for everybody turns out to only work in the succinct-- possibly French, certainly English, Italian and German not so much. The min height fixes that as well. So the next section, the percentages for column widths. And again, there's an alternative to this as well. This is the core of what liquid layout is. If you can at all possibly give a dimension, give it in something that is responsive like this. So don't give it in fixed pixel height, although with fonts, fonts tend to allow you to scale pixels with a basic zoom level on your page. The early browsers didn't. I think IE was quite stringent, and it was technically to the spec, but they've relaxed on that. But there, if you do the sums on this one, we've got potentially, this would imply three columns at 32%. You've got 4% left over, which is your gutter, but you remove the gutter from the rightmost column. This is using a last class. You could use last child or first child, I think, is more widely supported. But the absolute certain way of doing it is adding a last class, which kludges up your HTML a little bit, but it's there if you need it. A nice approach to this, actually, is to use the column count CSS property. So there are actually nice tools for this that don't require you to put a bunch of junky markup in, and you can scale it with media queries, which we'll go into as well. So you can go from four columns to three columns to two columns to linearized in this very fluid way, in a way that is much harder to do with divs. So I'd also encourage you to look into column count and column gutter, but on the understanding that not all web browsers will support them. So if we can scroll down again. Now, the scroll bars. The image for this I like to imagine is imagine you're walking through a supermarket front door-- you know those sliding automatic doors you get-- And almost comically, you're carrying a two by four plank with you. And you can't quite get through the door, and the doors shut. And lo and behold, they've clamped down on your plank and they don't close anymore. That's what tends to happen with a lot of our layouts, and images are the planks in this instance. So you can make everything else liquid and fluid, but if the images don't resize, then you've got a broken layout. And this is why I say use the viewport carefully and check as you go, because the chances are if you're still getting the horizontal scroll bar when you go down, it's more than likely something you've either forgotten to give a max width on or an image which is not going to behave quite like you'd hope it would. So the solution here is if we put a max width of 100%, it can only be as big as the column. This will allow it to find its native resolution, and if the container gets smaller than that, it rescales the image down with it, which is great. Again, there's always something. You think you've fixed one thing and water comes out the other hole and you've got to put your thumb over that one. So the box sizing thing. Again, this gets a little bit complicated, but this is something I'd say in the early days, IE got very, very right. I've got a great picture of a cat. Imagine if you were a cat. The example here is the current model is such that if a cat puts on weight, gains padding, if you will, then the size of the cat gets bigger, and so you need a bigger cat carrier to take it on a plane or a train or something with you. A coffin, on the other hand, you can add padding, all that silly, silky, frou frou stuff that goes on the inside and you pay through the nose for. You can add as much padding as you want. The coffin doesn't get any bigger and a guy digging a hole in the graveyard knows there's a standard coffin size hole he has to dig. And so you don't have to suddenly start shifting other people's gravestones just because you added some padding to a container. So I think that's about as visually as I can put it, and apologies to the recently bereaved. Box sizing border box will do that. It measures the container based on the most outlying element, which is usually the border, and then the margin goes outside of that. But in terms of if you're trying to create a grid-like layout, then this is most certainly than the type of box sizing you want to use. So again, the next one. This, for me, was the way around. You used to get a lot of clear fixes in there, and it always felt wrong to me because chances are, you're running HTML in there and a markup solution to a layout problem, it just smells bad, and so this is a way of usually avoiding that. If you've got content that seems to have escaped its container, probably what's happening is it's floated. And then for some reason known only to the holders of the mighty consortium rules and specs, containers will fold up around folded content. And so you might have a nice background color or a border which will just disappear. This is particularly the case when we have floated columns that may be in another container. This just basically fixes that. And again, sorry. I've got a more detailed version of this I can show you. This illustrates the point with a broken layout. But if you're having real issues with juxtaposed elements or things lying on top of each other, quite often, putting an overflow hidden on some of the container elements will fix that and you won't need a clear fix. Now, media queries. This is pretty much what everybody takes responsive design to be. I would say it's only part of it. It's possibly only half of it. I think the rules we've seen previously will deal with most of it, and with those percentage width columns, that will actually get you through most of the scenarios you'd want to support on a mobile phone, just your word might go a little low on some of these super narrow columns. Media queries are basically like a JavaScript if then statement, and they're usually built around viewport widths. And so you would, say, have a query for something, your desktop page. And for us, it would be 978 pixels or above. And then at the bottom end, you'd have something, like the standard one we use is a max width of 480 pixels or below. Chances are that's probably a mobile phone. And so it's at that point you want to do things like hiding download links for executables or possibly changing some images on the fly. Now, it really depends on your content here. Just, again, always about a pragmatic. The famous quote on this is just resize your browser until the layout looks bad and then that should be your next break point. And so for us, initially, we had put a break point in a 768 pixels and we'd trigger this mobile view. It meant people with all these lovely, high resolution iPad displays were getting a reduced mobile view, which seemed wrong. I think there's no problem with getting a full on desktop site on an iPad. And so we switched that down to 767. So below that, you would have some sort of linearization take place, but iPad and above looked fine. So for us, what tends to work is 600 pixels and below usually takes in most of the mid-size tablets or the more portrait stuff and something, [INAUDIBLE] generation of the Nexus 7, some of the Kindle stuff, the Amazon Fire tablet. Actually, I really like that form factor and I invariably lead them in vertical mode, and sometimes, having three or four columns in that is just a bit too tight. So whether or not you go to full linearized, your decision based on how your content looks, but it's maybe not a bad idea. And then the catchall for us was 40 pixels and below. That's invariably smartphones, and so that's where we really strip stuff down to the basics. So when we say, what do we do for the mobile, again, if you did one thing, it would be this. Anything that you were using as a container to emulate columns of some description you would get rid of the float so they would just go plunk down one after each other. The display block would force it into full width mode is 100%. This is about the braces approach, but that will basically break out any nice grid layouts you have, assuming that you're building around divs or LIs. Invariably for us, we're navigational and so this also linearizes navigation, at which point you might want to fold that up into a togglable tray at the top. But that pretty much does everything we would need to support things in the smartphone. And then you can do maybe more elegant things, like playing around with some of the button sizes or things like image choice for backgrounds and stuff like that. Next section, please. So that's the other one we've got, and as you can see from this, we're referencing two photos. One is a standard one, which we use for the generic container, which for us would be the default desktop, and then the second one we're triggering below 600 pixels. It would be a smaller image because there's no really reliable way to figure out if somebody's on Wi-Fi or on a data plan. But on the assumption it's better safe than sorry, we tend to give them smaller assets, even if the dots per inch are higher on the screen, because you don't really get the benefit, as I mentioned before, for JPEGs. So the beauty of this is the way the conditional comments resolve themselves, a mobile client or the Nexus 7 and below because of the max width of 600 pixels, they will never load the photo.jpg asset. They will go straight to the photo small. You could have an image on a page and hide it, but even if you have a Display None on an element, it's actually loaded in the background. This is a way of having it not even load as a resource. So the whole aim of this is to save somebody on their data fees. This is the way to do it. And I've found that increasingly, nearly most images I've put down, you can do so many clever things with images in the background of a container. You can size it differently depending on the volume. You can have the container act as a cropping device or to rescale the aspect ratio, all sorts of interesting stuff, or vignetted or interesting borders and stuff. So I really like having images in here unless it's very specifically content. Maybe it's some kind of a diagram and you absolutely have to have it print out as it should be. Then in that case, it's safer to have it as an image. Next, please. And there, again, just a last little clip there was say this was non-critical content. You could just hide it completely. And again, you see there because the background image is none, none of the proceeding images will load for the smartphone, whereas display none, it would. It just wouldn't be displayed. So this is a preferred thing. This is something we've only just recently, actually. A colleague of mine had told me that he'd been doing some work on one of our crisis response sites. I dont' know if you've seen it. Let's have a quick look. I think you can search for this, Person Finder. There's many good charities seeking donations for Nepal just now. I'd certainly encourage you to check into that. This is a site we use whenever there's a natural disaster. People, of course, want to find where their loved ones are and just hope people are safe, or report having found somebody so that separated families can just know what their next steps are. And so I was surprised this site-- well, as you can probably tell, it's not had much of a redesign recently. There is a big redesign underway and it should look a lot nicer, more up to date. But what we found was the layout was very grid-like and if we go to the I Have Information About Somebody. Just for the sake of argument, we'll do a test. We're not actually submitting anybody just now, but this will give you an idea of what would happen. We're presented with this double form page. In fact, we can just click on the [INAUDIBLE]. So this is a form people would come to, and what would happen when the smaller viewports, the first section of the form on the left hand side looked almost perfectly in line with it. That would actually display on most phones, but there was just no indicator that there was anything on the right hand side. And particularly with many of the modern browsers, they don't even show scroll bars just to keep them off, so there's no visual signifier of this content being there. So we just had a very simple, quick overhaul on some of the CSS. And so if you resize this now, you'll see that there's just a straight linearization. That second part of the form now drops below, and so anybody on their mobile will be able to go through one by one. Now, I know there's many, many accessibility issues on this form as it stands just now, and they are being fixed at the moment, but that will be coming soon. If we go back to the document I shared, we had actually looked at this. If you have an earthquake, chances are your broadband is not going to be working so you're going to be restricted to data and it's imperative that you support all these phones. Let's face it. A lot of places where these crises happen tend to be developing countries. These don't have the same infrastructure or the smartphone user base, and so there's a lot of feature phones out there. It absolutely is right that they should be able to access this content as well. Now again, this is on the pragmatic side. I think we could be more elegant about this, and I think we will be in the next launch of this. But the solution for feature phone ran a whole bunch of overwrites to the CSS that did the layout and the fancy typography. We just wrapped it all in a media all, so it's the most generic media query you could imagine. Basically, anything you put in there, that query is equating to, does this device support media queries? If it does, chances are it's a smartphone, [INAUDIBLE] smartphone, CSS in there. If it doesn't, the quickest way to make a website mobile accessible is, as we've seen before, all HTML is accessible and liquid. We only break it with the style sheets primarily, and so this stops that happening. It doesn't stop the person downloading the style sheet, but it was a pretty small style sheet in the first instance, so it wasn't seen as critical at that point. Again, the final gotcha in this is believe it or not, IE 8 and below do not support media queries, and so they have something rather handily, conditional comments you put into the HTML. And so you would have to have any of the CSS that would have appeared in the media query above for smartphones and more up to date browser, you can link to it as an external thing. It's a little bit fiddly because you have to maintain another resource, but it's a solid way of maintaining feature phones and getting them the basics. But like I said, we did this in a hurry just to meet the Nepal thing. If in doubt, just be pragmatic and get something out rather than wait for it to be perfect. There's some links here. I will get this page out to you. These are some of my favorite reading materials. It's a little while since I updated this. There's probably a lot better stuff out there, but I'd certainly say anything on the list [INAUDIBLE] is great. Smashing Magazine does some fantastic resources as well. I think a couple of these are links to those sites. Keep reading, keep learning, keep experimenting, and above all, keep testing on your browser. Maybe we can go back to the Picasa website just quickly. I'm sure you've all done this, but if you Command Alt I on your Mac keyboard, I guess that's Control.

JOHN MUELLER: That's Inspect Element?

RUPERT: Yes. It's Inspect Element dialog. And one nice thing about the Chrome browser is we've also got-- perfect. Thank you, John. So what we can maybe do is if we toggle here. I personally like the Inspect Element toggle left and right. And then if you just go here, I don't know if you saw that over on the right hand side at the top of the element inspector, there's a tiny little icon of a phone, and you can trigger all sorts of interesting things. For the most part, when I'm editing my CSS, I'll just resize the window and that gets most of it, but if you want a closer emulation of a phone thing, you can select various models and just make sure it looks absolutely right across the board. Let's see what it looks like on an Apple phone. Oh, interesting. That looked to me like--

JOHN MUELLER: It's reloaded.

RUPERT: OK, right. That was the old view when you didn't have a viewport on the web page. It's like a miniaturized version of the web page. This is what people should be getting. But the other nice thing about this is you can emulate really bad data connection. So there's a throttling here that you can-- we're very guilty of this. We have nice, big screens, we have a very fast network connection here, and so we just assume that this is how the world views our site, and it's just not the case. And so forcing somebody to develop in this mode, when they're reloading this page over and over again, they will want to make sure they do everything they can, which is reduce the file sizes and reduce the file counts. The less server pings you do, the faster the page will load. So again, look at sprites. SVGs are nice because you can actually write them into the code yourself. There's a whole bunch of ways you can speed up page latency. But reducing server pings is probably more important than reducing file sizes in that regard. I should have a great flourish for a finale, shouldn't I? Let me look at my notes. There was something. Again, one thing I'd probably suggest, don't think of this as another millstone around your neck. I think one of the great advantages of this, when you start thinking about mobile, it really forces you to consider what is at the core of what you're trying to do. Let me come back to the video. It really is, how can we best serve our users? When you give a designer a bunch of screen space, not everybody believes in white space. They want to use it. They're paid to put pixels on there, and they tend to do that with abandon. And the mobile, you don't have that luxury, and so you really have to think about the core of what a site does, and that's never a bad thing. So revisit your first principles. Get your Photoshop guide to mock it up on mobile first and then think how you can meaningfully add or enhance that core experience for the desktop audience. I know a few people now that when they're going to book aircraft, won't go direct to the desktop version of some of these web pages. They'll go to the mobile version because you don't have the clutter and all the other sales pitches on page as well. So really, really do think mobile first and it will improve the experience for everybody across the board, not just your mobile users. So hopefully, it should be a win-win. Any questions?

JOHN MUELLER: So we have a bunch of questions in the Q&A. I'll give you a chance to take a quick drink. Thanks a lot to Rupert. That was really interesting. Lots of information to digest. Luckily, it will be recorded, so if you didn't catch the one or other thing, feel free to check out the recording afterwards. Let's see. Some of the questions here. What are some of the most common mistakes that you see when going mobile friendly?

RUPERT: I would actually say it's too many breakpoints. When you resize a page down, you see the amount of work and effort that's gone into there. I think you can make a rod for your own back with that kind of thing. It doesn't have to look perfect. It just has to be readable. For us, obviously, something like the Google search results page, we want that to be really solid across everything. I think that's mostly done by liquid layout. I think people can go overboard with that, and it sort of tends to come from agencies. They want to show off a little bit and it looks great, but you can spend so much time on that where there's probably bigger fish to fry, just with your site hierarchy generally. I'd certainly suggest navigation can get tricky. When there's a lot of navigation links and you're scrolling through somebody's navigation, that can feel a bit awkward, so I'd watch for that. And as well, there's the famous thing of the big, fat thumb. They reckon that, I think according to the iOS specifications for apps, they want everything at 44 pixels. We try and encourage everything to be 50 pixels wide because I routinely see my fat fingers click on something on a website and it doesn't quite know what I clicked and it zooms up that little thing for slightly more detail to click on. If that's happening, and you might want to look at adding more padding to your links. So that the example of something I use quite a lot. Whenever I'm doing a layout or a navigation I'm building, it's usually in a list item of some sort. And rather than spacing them out with margins around either the link or the list item, I'll put a padding on the anchor element. And so the hit area becomes much bigger, it's easier for your thumb to get it first time. But it's also easier-- there's something called Fitt's law, F-I-T-T. There's some good visualizations on the web that's worth looking up. But the bigger the target, the faster you can get to it with a mouse and click on it. So that's another one of these examples where your initial thought was fix it for mobile but it's better for everybody, too. The frustration for me now is not sites that no longer have mobile views because most of them do, it's actually bad navigation. And if you have tons of things that you can't even fit on one screen, you might want to start rethinking some of the hierarchy or the architecture of your site because it's not going to be any less confusing for desktop users either.

JOHN MUELLER: We have one question about page speed as a ranking signal. I'll skip over that for now. Sorry. Or maybe I'll just do it really quick to give you a chance to breathe in between. So I guess the question is, is page speed today a ranking signal, and what should we do with that on mobile? So at the moment, we only use page speed in situations for desktop pages where a page is really, really slow to load. So think of something that takes multiple minutes to actually load in the browser. That's something we try to separate out and say, well, this is really, really slow, and if we have any reasonable alternatives, we'll show those alternatives instead in the search results. So that's kind of the separation we make at the moment. For mobile, we don't make that separation so much. I can imagine over time, maybe we'll find a way to include that in the mobile rankings also. As we see that more and more sites are actually really good mobile sites, we can say, well, there is actually a clear differentiation and users expect to find something that works fast and snappy on their mobile phone. So maybe at some point we'll do that, but at least at the moment, that's not something that we're doing. Let's see here. We have one about images and page speed insights. Skipping over the page speed insights part, in general about images, when you see tools recommending making smaller images, you suggested one option of having a normal image and a smaller image. Is that the state of art, I guess?

RUPERT: So looking at this, talking about the smaller images, they're too small. I'm going to interpret that as meaning they're pixelated or something. There's some interesting research. People have actually gone out, they've taken very large pixel size images and massively compressed them, and then you show them on the screen at a third or a quarter of the size, and apparently, they come out really well. So there are ways of having smaller file sizes. I think the trouble with that is it takes more of a bite out of your RAM because it unpacks it to the full size image, but most machines are OK with that these days. But are some workarounds to that. If it's a lot of line art, now is maybe a good chance to look into SVG because they're always pretty small and they can be as high resolution. They're basically resolution independent and will always look perfect on whatever device they will display on, which is fantastic. But if it's a JPEG, you could look into that technique, just really big images but with very, very high compression. That might bring the size down for you if I understand the question correctly. And if I don't, just please follow up in the questions and we'll look into it.

JOHN MUELLER: Is it enough to be responsive or should a website focus on having separate websites, for example, a separate mobile site?

RUPERT: So I guess we kind of covered that. For us, the decision was always, just for the sake of maintenance and ongoing investment, we'd rather put one site together and have it look OK on both. I suppose an interesting case study on that was something like the BBC news site, which tends to be my news source. For a long time, they had these separate versions. Just recently, maybe three months ago, they started trialling and then moved everybody across to this responsive thing. I think partly, their take on that was most people were also viewing it on a tablet or a phone over Wi-Fi at home, but it's also great as an expat. It's a touchy subject, but the amount of advertising on that site was just getting kind of crazy, and it was the same stuff over and over. And if you resize the browser down a little bit, the images are bigger, ironically. You get beautiful images. So I resized the browser down, and I actually now prefer the mobile layout on my desktop, and so that to me is an advantage. They decided to put them both together, and I've now got my choice of my preferred layout, and I actually prefer the mobile layout for the BBC news, which is a beautiful site and well worth the look. Because they're publicly indebted, they've got a real commitment to accessibility. They really lead the way in accessibility in Britain as well.

JOHN MUELLER: What's the difference between adaptive and responsive web design?

RUPERT: I'm going to let the genie out of the bottle here and say we had to look this up because we really had no idea. It transpires I've possibly been using these terms wrong. For me, I'd always said liquid layout and responsive and responsive isn't just media queries. The percentage layout for columns and things like max width of 100% or min height, that, I guess, is what some people would call responsive, and so that just automatically flows into the right shape or form for the viewport you give it. Adaptive appears to be this thing where you have media queries, and so some websites, the Boston Globe was the famous one that originally went full on media query. They've got a lot of them and they're worth a look. I think the idea being that you may never have a flexible layout. You would just have a new set of layouts as you scale the site around. I kind of don't like that so much because you're never really using all of the space for the liquid. You figure out how big your central, usually, column is going to be, and then as you scale down from there, you're still using the full width so it feels like you're making the best use of some of these pixels. But if you have something really design layered or some sort of dashboard view or something, then realistically, you maybe don't get the same fine control with responsive or liquid, and so rejigging the overall layout with adaptive or media queries is probably where you'd want to go. So for me, the distinction is between liquid layout and just changing the overall layout in perhaps a new grid that forms with a media query at different viewport sizes.

JOHN MUELLER: All right. Let's see. We have a longer question here. Let me just read it. "Instead of changing the position of links in our navigation via JavaScript, we have those links multiple times in our source code and use HTML and CSS to mark them as Display None or Not, depending on the screen size. Is that a problem? Is that a good practice, bad practice?"

RUPERT: So I think what we do in our sites, we take the navigation, reformat it below a certain height, but there's a requirement for JavaScript to do that. What you have there, again, if I understand correctly, is nice because it sounds JavaScript independent. I don't have any problems with that. I guess when we index them, I appreciate there's double links to everything, but screen readers certainly wouldn't have a problem with it. So it doesn't ring any alarm bells for me. That to me seems like a perfectly pragmatic approach, so I wouldn't have an issue, but I can't imagine it would be penalized.

JOHN MUELLER: No, that's fine. From web search, that's fine.

RUPERT: Whatever works for you.

JOHN MUELLER: All right. Here's one about SVG. Talking about high resolution images, when using vector SVG, does Google index content inside them?

RUPERT: I think it'd be very difficult to index, wouldn't you?

JOHN MUELLER: Yeah. So we pick them up as images and we treat them as images, but if there's text within the SVG, then that's not something we'd be able to index separately as text. It would just be a part of the image.

RUPERT: And again, just in terms of accessibility, if you're taking text content, making it invisible to search, you're probably making it invisible to screen readers as well. So if you want a special look or a font or something, there are web fonts for that kind of a thing. I'd encourage you not to hide text in either canvas elements or SVG files, and I would reserve it for the more illustrated thing. I suppose icons, sometimes you'd want to have-- but I'd try and have any text content in markup if you possibly can.

JOHN MUELLER: All right. Let's take some questions from you guys. What's on your mind? What kind of responsive questions can we help with?

AUDIENCE: I have a general question, just in terms of the current development. How many sites out there does all the advice you were just talking about, code, et cetera-- how many sites does that really affect, people building their own sites versus people using WordPress, Tumblr, et cetera? So basically, loads of people out there have what they have-- that's it-- versus the percentage that are building things from scratch.

JOHN MUELLER: I don't know. I mean, of course, the more people know about these things, the more they could do it. I think there's certainly kind of a separation happening where people are just using CMS systems and just picking one of the default layouts, and other people like really working on their website, making specific pages. I guess within Google, there are some aspects that we do use more or less the standard CMS for the content, and other things, we do code the pages themselves, right?

RUPERT: Yeah. We have an internal system that we use for content management and it just exports out using our standard style sheet, so we're lucky in that regard. I think anybody now, pretty much any agency, would give you a liquid layout, but if you call it responsive, basically, they can charge you more. It would be unusual that you'd get a site made now. My funny story in that was dentistry is incredibly expensive here, so I tend to barter a filling with a mobile friendly website with my dentist. The designer they had got very protective over that and quite defensive, and it was kind of apparent that she didn't know how to make a response website. I was very open to helping. If somebody starts backpedaling when you're talking to them about stuff, maybe that's the time to find a new agency or a new designer because everybody should have these tools in their toolkit by now. It's very well documented and it's no longer, should we support it? It's just, well, of course, you should. And so anything new that comes along, I'd be amazed if it didn't have mobile support for free. There's plenty of resources. The one that I use sometimes for friend's websites is Twitter Bootstrap. There's many other layouts available, so it's not that difficult to find this stuff out there. I think we've wandered from the question.

AUDIENCE: Good answer.


JOHN MUELLER: All right.

JOSHUA BERG: John, I'm doing responsive design for a new site that's an e-commerce site. Anyway, the biggest challenge that I'm seeing is choosing the right aspect ratios for the images because on the front, the client would like to have quite a variety of images. So we've got the full size at the top, and then in the second row, there is a wide image next to a square image, and then next down, there's another wide image, and then we've got two double size images. So when you start to work with that in mobile, it becomes very challenging because when you turn it, the small images become the big images, et cetera. They stack, and so it's very difficult to figure out what they should be. I mean, do you have any particular recommendations on that score? I mean, is it too confusing just to have so many different sizes of images?

JOHN MUELLER: I think that's why they pay you the big bucks, because if it were easy, then they would just do it themselves. But I don't know if you have any advice, any tools that you'd recommend using to make it easier.

RUPERT: Well, I guess we had exactly that issue. I had a grid system I was using for the cultural institute we had, and sadly, the website we made is no longer live. But we had a grid that either had squares or we went from a one by one aspect ratio to, I think, three by two, something like that. And so as you rescaled, they linearized and they all went to the same aspect ratio. And we took the effort to re-crop those at the resolution we'd expect them to come out, but there was certainly an overhead associated with it. So I think maybe something that could work there would be if it's just a small object, you get so much flexibility with using this as a background image. And so something I'm doing, actually just for an internal site, we have these product icons and they look great in grid view. When you linearize, the grid items basically become wider, at least initially, before you go back down again. And so we have it inside this colored block, so the icon is quite small but the block resizes around it. The icon doesn't change. And if we wanted, we could add a gradient or a vignette type effect using a an inset box shadow or something. So it's back to that flexibility thing. If you need a full width thing, there are container sizing properties you can use as well. I'm a little rusty on this, but you can either contain it. There's different ways of doing it. Look into background image sizing. There's a bunch of different approaches you can use. So that would give you the option of taking just one image, resizing it either above the vertical space you've got or the horizontal space, but you'd fill whatever aspect ratio you've got with a complete image. You would just be cropping a little bit of it to do it. But that would be the way of using one image multiple times at different aspect ratios and different resolutions. It's very expensive to animate. We did find our CPU was going through the roof because we were animating these things as well, so there was that slight performance hit, but that was early days. But we had a whole bunch of transitions. We were discovering the joys of CSS animation and we probably did slightly more than we should have, but you've got to have your fun, right?

JOSHUA BERG: Also, I have a number of sites that use a different image for mobile, so instead of being wide, it crops down. What you mentioned about having a mobile separate site, the maintenance of doing stuff like that is very challenging.

RUPERT: Yeah, and it's a cost to the business. If it isn't maintained, it doesn't matter how glorious it looks, but if nobody can face launching any new content, well, that hurts your business. So there's possibly a reason to push back there a bit, too.

JOHN MUELLER: [INAUDIBLE], I think you had a question as well, right?

AUDIENCE: I did. You actually answered it when you were giving your presentation. I'm trying to think if I can sneak in a question about this new True View feature that's come out.

RUPERT: I'm glad you mentioned it because I have no idea what it is. Please tell us about it.

AUDIENCE: OK. Well, I barely caught it as I was coming in here. I got it on my other screen. "Introducing TrueView for Shopping, a new way to promote your products with video."

RUPERT: I don't know.

AUDIENCE: So "TrueView for Shopping allows you to showcase product details and images, along with the ability to click to a purchase from a brand or retail site, all within your video ad. It's available for TrueView in stream video ads on YouTube, and since we know that 50% of views on YouTube come from mobile devices, we've made sure that it works seamlessly across mobile phones, desktops, and tablets." And there's more, but I'll put the link in.

RUPERT: Do you work for Google?

AUDIENCE: No. I study it fastidiously.

RUPERT: That sounds pretty good, actually. Thank you for that.

AUDIENCE: I guess I'll learn later.

RUPERT: You never stop learning, do you? Yeah, I use Feedly now. Our reader went away, but I've got a feed of the list of things I keep track. A List Apart, Smashing Magazine are two of them, but they tend to be more development based. I know that there are a few good blogs that cover a lot of this stuff as well, and a lot of the stuff that John's team comes out with as well. Keep an eye on that because you can't afford to let your skills slip in this game.

AUDIENCE: Right. It moves too quickly.

JOHN MUELLER: All right. One last question. Anyone?

RUPERT: We covered everything. That's great.

AUDIENCE: I'll ask a question. I think I know the answer anyway because it's the same on mobile as on desktop. We just moved to responsive, and a lot of the stuff we added, when I was checking with our developer, he said, I can only do that if I duplicate it somewhere else on the page, basically, so there's two versus of a picture or two versions of a paragraph for different sizes. I'm not a coder so I don't know the technical aspects, but I assume from an indexing standpoint, that's not a problem, having the same content twice. Google would just ignore one version of it and it's not duplicate. It's not a problem at all.

JOHN MUELLER: I mean, we try to figure out which content is visible anyway and focus on that, so if one by default has a Display None, then that makes it easier to focus on the other version.

RUPERT: I'll be honest, though. That doesn't sound right to me. I'd be interested in looking. That sounds like somebody's doing the old sledgehammer to crack a walnut there. Maybe there's a misunderstanding of how the responsive works, or maybe they're so tied into a layout that they're basically. If you've just got the desktop page followed by the mobile page on the same page and you're flipping between them, that's not really helping with your maintenance. You are maintaining two code bases, effectively. So I would probably gently, over coffee, just a little nudge and a question.

AUDIENCE: It may be because-- John knows about this anyway-- we kind of rushed to get a version up because of other issues, so we didn't redesign the site yet. It had to fit within the existing look and feel. We had try and get it done in four to six weeks instead of starting from scratch. So it may well be that's it, but we're in a kind of unique position in that sense. When we completely redesign, we'll obviously start again. So it may have been that, but luckily, this is recorded, so I'll show him this later anyway. But it's also built from scratch. It's not a template of any kind or anything either, so it may be [INAUDIBLE].

RUPERT: I don't envy you. These kind of reverse fits are just horrible, particularly when it's old, undocumented code and half of it probably doesn't do anything. You just don't know what half. You have my sympathy.


RUPERT: It'll be great when you remodel, right? Can't wait until you relaunch.

AUDIENCE: It won't be the first time.

JOHN MUELLER: All right. So we've come to the end of our time. Thank you very much, Rupert. It was really interesting.

RUPERT: It was a pleasure.

JOHN MUELLER: Great having you here. And thanks for all the questions and comments as well. I'll copy the rest of the questions out and see if there's anything we need to reply to in the event listing. And otherwise, wish you all a great weekend.

RUPERT: Happy Friday.

JOHN MUELLER: Bye, everyone.

AUDIENCE: Thanks. | Copyright 2019