 Let's talk about DevTools and what the team has been up to in the last couple of months. So first, I'm Paul Backhouse, one of the pals. And I'm the advocacy lead for DevTools. So I give my voice to DevTools, collect input and feedback, and tweet and do whatever else, and be on the stage. And I also do the outreach for AMP, the accelerated mobile pages project. Now, we've been talking about performance a lot in the last couple of years. We've done a lot of performance improvements. We're going to continue to do so, lots of the front end up story, really, to improve the speed of your pages. But today, this talk is not about performance. This talk is about something we discovered makes more sense in this context, which is actually building websites. This is the thing that people do with DevTools as well, actually building websites. And it turns out, one of the audiences that does that, in particularly, are designers. So designers, we didn't really focus on designers when building the DevTools before. But it makes a lot of sense, because they've been doing more and more CSS. And a couple of services that we've seen recently showed us that most of the design work, most of the prototype work, often happens in DevTools, which was surprising to us. Because we thought that most web developers would do changes in HTML, et cetera, but not so much to designers. But it's actually a really powerful tool. But it mostly stale your nail melts panel, and we want to make sure that the DevTools work for that crowd. So what we've also discovered is that a lot of the UI was really cluttered if you look at it from a design perspective. We thought we could do better than that. And so the first thing I want to show you is a couple of improvements that we did in the UI in DevTools. So three things I'm going to talk about. First is how we're making DevTools a joy to use. How we're making it really simple and easier. The second one is how authoring becomes a really big story in DevTools, and how we make that fast, intuitive, and really fun. And then finally, something for the debuggers and JavaScript developers with us is more JavaScript control, more tools to make your debugging flow much better. So let's start with how we're improving the UI. So if you do work on a product that grows, and grows, and grows, and you put in more stuff, and more stuff, and more stuff, DevTools are quite complex nowadays with a lot of magic, lots of good tools in it. But sometimes a user interface can become a UH, which stands for user interface. And we don't really want that, right? That's not what we're trying to do. So in order to prevent that, we hired Max. Max is our new full-time designer. For the first time in history, we have a full-time designer working on DevTools and improving everything around DevTools. And you can also already see the fruits of his labor in many different places. So let's go through some of them. But first, let me show you how far we've got. So we have 2009 on one side, we have 2050 on the other, and there's a dramatic amount of small improvements, small and powerful improvements that went to the DevTools. So a few of them. Well, one thing that is new, you might have seen, is the new main menu. We don't clutter the UI that much anymore, but we have docking now in the new main menu, much easier accessible than before and much simpler than having a long press. We have all the important tools that you only use sometimes, like inspect devices, network conditions, sensors, and settings and help all in there for you to access whenever you need them. And then we also made it possible to reorder tabs. That's been a feature that's been long requested, and we finally got it. Not only that, but we also reordered the tabs by default. So we brought them into the position they make sense, where they use the most. We discovered that the console tab is on second place in usage after the element panel. So we put it in its second place, which just made a lot of sense. And then we also added an overflow menu to the area, the drawer, where a lot of the overflow content sits in. So if you do a global search, we put that into the drawer next to the console as a closeable tab, because it's not something you want to have around all the time. Now we put more and more stuff into it. We made the story more consistent, and we added an overflow menu to always come back to what you wanted. And then we also improved the context menus in a few places. For instance, this is the new context menu when you right-click on the DOM panel elements. And it gives you a lot easier control over what you want to do. Copy outer HML fonts and something we didn't have before. Just copy the node. You don't need to do any special magic for that anymore. You can immediately trigger the active state or focus state right from there. We still have the other place in the style panel, but this is a lot simpler than it was before. So we get that even with those improvements, and we continue doing them, there are still times where you will be completely lost. There are times where you will think, OK, where did I talk ago? What just happened? And that's OK. We're here to help. And if you've seen the main menu already, you've seen that there's a new help icon. And that help icon leads to our new homepage. That new homepage is not just a facelift to the old homepage, but in fact, it is heavily rewritten, so it becomes action-oriented. So a lot of the guides and tutorials that you find on that site are specific to a problem. They're trying to solve a performance problem? Sure, here's a couple of guides for that. So that's really how we build up that page. And then also, if all hope is lost, if you really can't find anything and you don't want to dig through the page, you can still always get in touch with us. We started tweeting a few months ago on the Chrome DevTool title, and it's becoming really successful because people realize that we actually answer and reply. And we also tweet a lot about the latest achievements in Canary and what the team is up to as soon as they come in there. So that's that. That's some of the UI improvements recently. Those were just over the last couple of weeks, but there's been a tremendous amount of UI improvements in the last couple of months. Some of them you probably don't notice every day because, well, a lot of it is changing every day. But there's quite a focus for the team. So let's move on with how we're making authoring fast and do it in fun. Now, here's a page I've been working on recently in my spare time, and I want to prove it. I actually want to create a dark version of it. I thought it would be nice to play with the ambient light sensor and make it a dark version. So what do I do? Well, I have to pick colors. And I don't know about you, but I'm not terribly confident in picking colors out of blue. Maybe some designers are that are very familiar with color theory, but I'm not. So usually, what I do is I go to a website. I search for a palette that looks nice. And I don't really often find what I'm looking for. I mean, oh, I go to some color wheel or whatever. But I thought we could do better than that. So what we did here is, first of all, we made it really, really easy to add in color if there wasn't one already. So you don't have to type in background color red and click on the color picker anymore to open it. We added two buttons that immediately add foreground and background color. And now you're seeing the new color picker that we've worked on. And what this new color picker includes is not just a way to pick random colors, well, because that's not what I wanted. But instead, for instance, it also allows us to pick something from the page. So hey, I see some color that I found in the header that I really like. OK, I pick it right there. This was a feature that a lot of people didn't discover. Because we didn't have that little eyedropper icon before. And ironically, I mean, it was always on, but people didn't discover it because it was always on, because they didn't click on it first. So that's one way. But then you can also do so with a new color palette. We've added the material design color palette through the color picker to allow you to choose from colors that designers have chosen. And I'm really glad that some designers that spend lots and lots of weeks going through every little color and tweak it, spend more time on that than I do, make that choice for me. Now, we didn't just ship with the base colors that you see here. Those base colors are nice, but they don't work in every context. In the case of my background on the page, they don't work. I want to have a very dark color. So instead, we also ship with the shades. And the shades come up if you long press on one of the colors. So you can long press on the colors and pick whatever you need to. In this case, this color I think works really well for me. So finally, I obviously also have to change a few other colors, for instance, the header here. And to do that, we made it really easy to discover what I need to change. So if I now hover over this selector rule in the style panel, all of the other elements that would apply that to the selector are actually highlighted. And now I can choose the color with confidence that I'm picking the right selector. OK, I think this works again. And finally, the text color. Before, I actually just had to, for contrast reasons, I just had to measure what I thought was right. But now we have this new line that you're seeing on the color picker. It's still an experiment. It's coming up relatively soon. But this new line is a color contrast line and gives you an idea what contrast works best for accessibility reasons. This is really powerful because I before had no idea what color is a good color when my eyesight isn't that strong. So this is a very great way to make this happen. So that's color. Let's move in to mobile. So I was in that situation quite a lot. I've been in that before. So you basically, you work on a product. You work on it for many, many months. Obviously, you develop on desktop computers because they have your build system, whatever. And it makes it really easy. But then your boss, one day before Lounge, asked you if you tested on mobile. And you're like, maybe. Well, we did an improvement here last year, which is the new device mode. Device mode comes up if you click at the icon next to the inspect element icon. And it brings up mobile emulation. So from here, you have a UI that you can select the device from, select network, throttling, and emulate a lot of the characteristics of a mobile phone. So that was a good start. We also had media queries in there, Zoom, a lot of interesting things. That was a good start. But there was one thing that I just couldn't pinpoint I was wrong with it. And we finally could pinpoint it, which is it's sort of backwards. Why are we starting with the desktop website when all the traffic comes from mobile in the first place, when most people discover your page on mobile first and then maybe use the desktop afterwards? Isn't that kind of backwards? Shouldn't we be building mobile first and then go up? Well, it turns out that's not a new thing. In the responsive design world, that's been the thing they've been preaching for a long time. Just focus on the mobile website first, use progressive enhancement, and then scale up and use media queries to actually build the desktop side out. That's not a new story. But somehow, our workflow was stuck in the past. The Chrome DevTools were still heavily focused on desktop and had an opt-in mode if you wanted to debug for mobile. Now, I'm very pleased to announce that this is changing. We are building a new device mode for a new mobile first world. So, well, I mean, you could freak out now, like, are you freaking kidding me? Are you shoving that eye in my face and have it always on? Is that really what you're doing? Because then I'm going to leave. OK, so this is not what we're doing. That would be a supreme amount of trolling. And we're not going there. Now, instead, we dramatically simplified the story. What we have here is a new device mode. It's on my own page right now. But as you can see, it's just one line that extends to the main menu. And it gives you control of a responsive design. We just started on desktop. Now we're in responsive mode. But we can also emulate a certain device that we want to. So in this case, for instance, the Nexus 5x. And edit any and add any custom devices to it if we want to. So in addition to that, we now have Chrome within the device. So now you can emulate how it would look like on the keyboard, as well as in landscape on the keyboard and with the actual Chrome of the device. And all of it is centered. So it's really focused on the responsive design story. And if you're working a page that has a lot of media queries, you can also enable media queries, like in the alt mode, in a much lighter way, and focus on them. Click on them to actually preview how it looked like a different media queries. So as you can see, the device mode icon is not in the inspect element area anymore. It's not there anymore, because mobile is now the default in DevTools. Now, what does that mean in other places? Well, first of all, for throttling, for instance, you haven't seen throttling in here. And there's a reason for that. Because we thought, OK, in this new world, everything in DevTools is focused on mobile. So why shouldn't we put it where it makes most sense? And it made most sense to us in the network panel. So because it's always important to test how your site looks like on slow connections. For instance, if you're working with a service worker. So we put throttling in here. And the network throttling profiles can be configured in the Settings panel. So now, I had to slide up last year at Google I.O. I'm going to bring it up again. Mobile emulation is not the same as an actual phone. It's important. We made the story pretty powerful, in my opinion. But it's still not the same. If you're debugging something like performance, we still can't really emulate that on the actual desktop emulation. So for that, previously you had to go through Chrome Inspect, which was a completely different window and gives you access to remote debugging, to actually remote debug your pages on a phone. Now, we thought we could do better than that and actually integrate that into the rest of DevTools as well. So now we have an experiment going that actually does that. So as you can see already in the new main menu, we had Inspect Devices, and it now brings up a dialogue within DevTools. You don't have to go to another page anymore. You can continue to stay on page. Now, it's pending authorization. I click on it on my phone and say, yes, I want to agree. And now it's connected. And I can debug any of the pages I have opened on my phone right there. So I think this new mode makes it a lot easier to work with actual devices. All right. Moving on from device mode. Let's talk about something else. Here's a rule of thumb I came up with. The rule of thumb goes, a visual design practice is out of fashion when browser vendors have added a way to do it in CSS. That sounds a bit obtuse, but it's sort of true. I mean, if you look at border radios, CSS gradients, as soon as we got CSS gradients unprefixed and basically spacked in every browser, there was flat design, and people were like, well, it's not that cool anymore. And border radius was the same thing. I mean, as soon as we had border radius, everyone was like, off it, and the trend was already moving on. So what's the point in doing new stuff if everyone is not using it anymore? Well, the good news is that this time we've been faster than the trend, which is great. Finally, this feels good. So what I'm talking about is animations. But when developers think about animations, they often think about those kinds of animations. Animations that really do not improve the experience a lot. I mean, sure, it makes stuff wiggle, but I'm not really getting how that improves how I'm using my page. What's wrong about you? But there's probably some purpose, but I haven't found it yet. But if you do animations correctly, they actually focus the state of change. So they make you focus, make the user focus on an actual change that's happening on the page. And that's really, really powerful, the transition that you're animating, as well as actually hiding from the fact that something is loading, like a loading animation. Or you could do both at the same time, like we did on the old Google IOR website, where you can see now, if you click on another link, it's both a transition that changes the state, but it also hides the fact that it's loading more stuff. That's the best-case scenario. So what did we do here? Well, we added a new animation inspection mode. Is this running? No. Here we go. Should be running. And now it's running. So this is actually, this is a very interesting site, because this is the actual spec that's used. It's the motion spec that the Chrome team created to work out the animations in Chrome for mobile. And now what you get here is if you inspect an element, this keyboard didn't really work well. So now I inspected the keyboard, and I want to change the easing. I bring up this new cubic easing editor. And I change it to any kind of value and defaults. I can change the lines, as you could see. And I can make sure that easing works much better. So now if I click back to that animation, you can see that the keyboard eases in much nicer. But as you can see in this demo, there's a lot of complex animations, like this one, like the menu animation or the animation where I open the tabs. Those are composite animations. So how do you focus on those composite animations? Well, that is where the new animation inspection comes really nicely. So you can see once I go through those pages, it constructs groups, sort of tap groups, in the animation panel. And if I click on them, it replace the animation that is just captured. Yes, thank you. And now I can scrub on that animation. But again, it's a composite animation, right? So we kind of realize that you want to look at that in context of your page. So you can scrub. You can make it slower. You can drag around. You can debug any, any state, right? And one thing that's upcoming that's really cool, we're putting some more work into this, and that's completely ready, but it's the actual ability to change things in this mode. So now I can actually change things around. I can move the delay. I can change the duration of the animation. I can obviously change the easing in the styles panel because I click on stuff. And now, as you can see, I changed it in real time right there on the page. So what I haven't got for offering. We've got a new improved user experience. We get animation inspection, and we get the new device mode that's always on. OK. So one thing that I have to mention is that some of the features are so new that you should be using Chrome Canary. Now, some features like the UI are already in there. You can use them in the work, but features like the animation inspection are still behind an experiment. Now, it's relatively easy to enable those experiments. Just go to Chrome Flags, enable DevTools experiments, click that relauncher browser, and then you have in your DevTools settings a new tab called Experiments, where you can toggle any kind of experiments that we're currently working on. And it would be great if you could do that and actually give us feedback if we should do something better. So that was all good and great if you're building websites with DevTools. But what if you're doing front-end ops? What if you're sitting in a control center and focus on performance improvements, et cetera? Or actually debugging JavaScript? Well, we have some stuff for you, too. We have a few new JavaScript things that are really, really nice. One thing we've added is inline variables while debugging. So we now show what gets evaluated on every line once you're stepping through the code, which is really handy because otherwise, you would have to hover over the variable first, dig in there, see what it is. But now you always see the context you're in and the current valuable value in the debugging flow. We also added proactive compilations. So now if you do a change while debugging to see, OK, maybe this loop works this way, we actually show you that you did a semicolon error and there's a bug in the parsing of your code without you having to continue running it and just discover it afterwards. So this is a nice little improvement. And then we also added something that makes working with a lot of stacks in frameworks a lot easier. So you see there's a lot of stuff here from Ember. Now if I click on black boxing in the settings, I can black box the library that I'm working with. And now the stack frames are hidden and I can focus exclusively on the code I don't want to look at. So in this case, for instance, I did not kill JQuery because I want to see the JQuery code, but I could obviously remove JQuery as well. And in addition to that, we also made it easy to do so with the events. So now if you see I clicked on an event in here, but it really didn't go to the right code. Now I add framework event listeners as a checkbox, and it goes directly to the line I specified my event in. And then we got something for more advanced usage, which is object formators. Object formators allow you to do this. So it allows you, if you have custom objects of any kind of sort in your framework, in your transpiler, you can make them look differently in DevTools now. You can make them look a lot nicer than before. So before, you have to top, which is how it would have looked like before. But now you can style them and map them up in a way that they lock in a really nice way to the console. That's object formators. And now, finally, I mean, Jake will probably come up here and I was like, well, isn't this a service worker conference? What's the deal? OK. Well, yes, we have something with service work as well. So this was service worker before. This is how I was working with service worker in this old world. I went to service worker internals, same as with inspect devices. It opens a new page, and it's really disconnected from the DevTools. And also, it is focusing on all of the things that are happening across your browser, not just the current service workers that you want to inspect. Instead of that, we actually moved it into a rich resources panel. So now, if you click on Resources, you have this new tab called Service Workers in there. And it's a lot easier to work with them right there on your page. And it's only showing you the service workers that are relevant to you, allowing you to do a few cool things like forcing an update, simulate push, inspecting the worker right there. There's still some UI tweaks that we can make to that thing, I'm pretty sure. But I think it's a great step forward. So now, we've got making all things a joy to use. We made DevTools fun to use, and we gave more power to JavaScript developers. But there's actually one more thing. There's one thing that is not quite ready for prime time, but I don't want to talk about. We rarely do this to give a sneak peek of something, but I'm just so uncomfortably excited about it that I wanted to show it to you guys. And that's the layout mode. Now, the layout mode is that what you see is what you get editor for DevTools. And if you're like me, you might cringe a little, and that's OK. Because you remember this kind of scenario where what you see is what you get is sort of a maybe. Maybe I get what I see. And that was the scenario with many of the tools that I grow up with that generate a lot of garbage code in the background, and you have no idea what's happening. So what was really important for us was a couple of design iterations that made this different. First one was if you look at a classical, what you see is what you get editor. You get hide and wit controls. But how often, when you're doing a website, do you change the hide and wit of something? Well, you could change it on an image, sure. But mostly, you change paddings and margins. So we spend hundreds and hundreds of iterations to come up with a model that actually works for paddings and margins. This is not the model that we're using, but it's just a design iteration that we're playing with. We also want to make sure there's no black magic going on. So we're not generating garbage code in the background. And we always have you look at what's generated right there. So with that being said, here's a preview of the layout mode. So if there's a new little icon, I click on it. It becomes sort of a select. And I can click on anything on the page. And it brings up controls to change the padding and margin. Now, as you can see, when I'm hovering over it, you get these little stops, the walls, that signal in which direction you can drag and which one you can. Because everything on the website is highly dynamic. So you want to change the direction the right way. Now, all of this matches up. So if I scroll wheel, I can change the actual rule. I can change the rule that I want to edit. And it changes all at the same time, as you could see the menu now. And same thing here. I click on the paragraph. I take the margin or padding handle. I change the rule by using the mouse wheel. It flashes up in a style panel. And I change it right there. And it changes the one below as well. So it's a really, really simple way to change what you're having on a page. It saves it directly back to the style sheet that you're having on a page. You can then take that style sheet, bring it back to your editor, whatever you want. And the handles look very, very different than what you're used to, I'm sure. And the reason for that is simply that we want you to focus on the content. We didn't want to have a bunch of handles on top of your content, so we moved them outside. So this is just a preview of the layout mode. And there's a lot more to come. We're still working on this quite a lot. But we're looking for your feedback. And now, next talk is going to be Paul Lewis and Paul Irish afterwards talking about what we did in DevTools when it comes to performance. So not all is lost, if you will. We're looking forward to performance. Thank you.