 And the team at Google that started on Chrome was actually we were all working on Firefox. When you ask people what you want, it's the way they want more and more, but they never use those things and it's really hard and quite brave things. They know we're going to strip stuff away. There was internal talk about how Chrome was built and I think back to that time where Internet Explorer was the dominant browser. Firefox was fighting it and the developer tools were becoming quite prevalent. Safari was just released I believe and Google decides to build a browser. So how do you start in that environment where there's so much competition? Chrome was released in 2008, but actually we started on it in 2006. And the team at Google that started on Chrome was actually, we were all working on Firefox. When I first joined Google at the beginning of 2005, the idea was to work on making the web better. One way to do that is to work on making browsers better. So we started out as a team working on making Firefox better. A year and a half into it, we made the switch to actually building our own browser. That was a big, big complicated decision, right? Because we had already been going down a certain path, right? So looking back, I think there were a number of factors, right? First off, we thought we could do a really good job. So that had to be true. But also, you know, there were a lot of things about browsers in those days that I think created a frustrating user experience. You got to go back, going back to 2006, you know, applications like Gmail, Maps and YouTube and so on, these things were becoming popular and other folks were building complicated web applications like this. And your typical browser in that day, if you were to leave Gmail running overnight, you come back the next day and your browser would feel pretty sluggish and bogged down because of just the weight of these applications. And so way back then, we had the idea that it would be really nice to split up the browser into multiple processes, right? Operating systems had gone through a revolution from the days of Windows 3.11 to Windows NT and so on, where preemptive multitasking was the thing. OS 9 to OS 10, could we use preemptive multitasking? Could we take advantage of actually multiple processes on these systems for web browsing and seem pretty, like, actually seem possible if you were thinking about a browser from scratch? Yeah. I mean, in terms of, like, the UX of, again, going back to the beginning of, like, browsers or the browsers of that time, it reminds me a bit like search before Google's. Like, search was basically portal sites and the search input field was, like, the most least important thing. But then Google came along and was like, no, no, that's the wrong user experience. When Chrome came about, it was quite radically different because I don't remember if this phrase is content, not Chrome. So just making that kind of UX decision of, like, you know, because it was all toolbars, and I remember it was like, you install anything. In fact, back then it was very common to find a user with Internet Explorer and they had installed multiple toolbars. So it's not just one toolbar but multiple toolbars. And there's, you know, it's great, absurd screenshots of people with, you know, whose browsers had, like, five toolbars. There's not a lot of room for the content, right? So one of the things with Chrome, this content-not-chrome idea, was to really remember that the whole point is people want to engage with the web application, the website, the web content, and the browser should just try to get out of the way. Just facilitate helping you use the web. And so even when we designed the extension system, we resisted the idea of having a first-class way or proper way to do toolbars or sidebars. We really didn't want extensions over eagerly, you know, using up screen space when that screen space users really want that for the content. So we designed things like extension buttons. That would be the primary access point and tried to guide things in a way that would preserve that notion. Even the UI of Chrome itself tried to keep it very minimalistic. You know, we spent a lot of time in the early days thinking, if we're going to introduce another browser, it's got to be so awesome, right? And what does that mean? It's got to have, like, the most amazing features. It's got to, like, have a whole new take on browsers. It's got to be radically different UI. Surely that would be the reason why we're doing this, right? And we tried many different things. Putting tabs on the side, you know, fancy user gesture kinds of things, mouse gesture types of things, I mean, none of that really felt right. And through that process, we came to realize what actually we were doing and what really would set Chrome apart is that it was a browser that just works better. Yeah. Like creating software that's not frustrating is actually hard to do. Yeah. And I think users appreciated it. And so we started to think about it and what does that really mean for us? It was like, well, a product should be pretty simple, right? Should try to come up with elegant UI choices. Keep it simple. It should be performant. Like I said, browsers have a history of being janky and not well-behaved. And the user has an expectation when they click on something, especially when it's the Chrome of the UI and when it's the browser UI, they click on it. They say, close this tab. It should close right away. Yeah. And part of the course of those days was you click to close the tab and you might see a beach ball on macOS 10 or nothing happens on Windows. You start to see the application not responsive problem, right? But in Chrome, because we went with this multi-process architecture, we were able to guarantee that if you click close on the tab, it's gone. Yeah. And those are examples of responsive UI that sometimes when we talk about performance, speed, we mean how well did it perform on a benchmark. But a lot of times it comes down to like, was the experience smooth, responsive to the user and what did it actually do what the user wanted it, when the user wanted it, that kind of thing. So simplicity, speed, we also put a big focus on security and stability. So we had these four S's. Yeah. And that was the thing that we just repeated to ourselves. If you're not sure what to work on, work on one of those things. Yeah, absolutely. Work on making a simpler design. Work on making it more performant. Work on making it more secure. And really with security, we mean making it so users feel safe on the web. They feel in control of their privacy. They understand what's going on. But also that the system is protecting you from malware and so on. And again, our multi-process architecture not only helped us make something more performant, but also something more secure, a browser more secure. And finally, it helped a lot with stability. We knew that starting scratch with a browser, that might actually be the biggest concern. Is it going to just crash? Because how do you exercise enough of the browser in your testing to know that you've got it right? Yeah. We based the browser on, not on Firefox. We based it on WebKit, which is what at those days that was Safari 2.0. Safari 3 had just come out. And WebKit, Safari was known to not necessarily be the most compatible with the web, right? Modern web standards driven by Firefox were just becoming a thing. Internet Explorer had a lot of quirks about it. Internet Explorer 6.0. A lot of quirks, especially thinking about like float out with floats. The box model. Yeah, the box model. All these things were very impactful to like how web pages were built. If a developer was testing a lot with Internet Explorer, there would be the quirks that they would code to. If they were testing a lot with Firefox, we'd see that. And with Safari, it was like, well, probably they weren't testing with Safari. And so it was a big challenge and a big fear when we launched Chrome, is it going to just crash all the time? Yeah. How are we going to manage that? So we put a lot of effort. And in fact, that same issue informs like our choice of the user agent string. If anybody's seen the user agent string of Chrome, it's kind of hilarious because it mentions every browser ever since. Chrome came along and that was part of navigating this whole like, does it work conundrum? We always taught in software development and UX, add more features because more features means more value. So, I mean, was there ever pushback or was there like a fear maybe we're taking away too much from the browser UI? We certainly launched originally Chrome without any extension support and even the bookmark manager was revised quite a bit, post the initial beta, things like this. So we intentionally went with a very minimal approach, but we also really encouraged the team to try a lot of things with the idea that knowing and going into it, that we'd probably throw away things that aren't good. That was the mantra, if you will, like let's just try a lot of stuff. And if it doesn't work, it's okay. We just throw it out. It's not the end of the world. We don't have to ship everything we try. I think that was really liberating and really helpful because there were a lot of folks on the team who had interesting ideas and it's empowering for people to try stuff, but it's also appropriate that we don't just say because we built it, we should ship it. Looking back, what would you say were the best decisions you made and also the two-part, would you regret in terms of things that you did that you'd wish you hadn't? Also, I'm an engineer. I was definitely an engineer at those days and I feel really good about some of the decisions we made from an engineering focus. We really put a lot of... We talked a lot about how important it was that we were building a product, building a platform. Ultimately, this is a product that carries the web platform, but what I mean by not building a platform is that sometimes there's a temptation as engineers to go off and build framework and tools for creating the product that you're actually there to create and we really resisted that a lot. Tried to make sure that we focused as much of our energy on actually building a browser, which was very helpful to make sure that that's what we did. So, for example, we said, first, we're just building a Windows browser and that meant let's just use Win32 straight away. All the Microsoft APIs, not looking for any cross-platform toolkit framework to build our UI. Yes, one day we'll bring this to Mac. One day we'll bring it to Linux and so on, but for now, we're just building a Windows application and when we went to finally build a Mac product, a product for OS X, we told some of the engineers at Google, we said, hey, do you want to come work with us? We'd love for you to build the best browser for OS X and we want you to approach it the same way that we approach building for Windows, which is all the UI should be cocoa, it should all be native, and we want you to have the freedom and flexibility to both embrace the native operating system primitives but also move quickly as those primitives change as the OS evolves. So let's build a Mac-focused product again with this idea that we're building a product on a platform for building browsers. But what ends up happening is you do this and we did the same thing with Linux, what ends up happening as you do this is we start to realize we are coding the same thing three times. And later on, things like Android came along and iOS and Chrome OS, and so our world got a lot more complicated and what we ended up doing is there was this arc from the singular, I'm building a product to I'm starting to build platform things that helped me build that product across and different platforms and that came afterwards and I think that was actually somewhat healthy and a bit, to a certain extent, I kind of have some regrets that we built Chrome so much as a monolithic product. So while there is some code structure that's healthy and good and there is somewhat of a layer cake, if you will, there are some cuts that some extra layers in the cake that should have been there. And now we have a lot of complexity because we didn't make some of those cuts earlier. We didn't modularize necessarily as much as we should have. But again, I think that came from that focus on we're just building this product. We don't need all that extra modularity and now we find ourselves wishing we had a little more forethought on that. What would you say the decisions that were made that were actually really good to the success of the browser? So design examples and engineering examples, there was this one concept that came up very early which was, and we wrestled with this a bit, so the content area of a tab, right? We started with the idea that there are some... we will actually have some browser UI that lives in the tab. So for example, when you open a new tab page, there's some content shown to you, suggestions about things you might want to do. We started out building that natively and we started to find ourselves discovering an uncanny valley because developed users have this expectation that things inside the tab behave like web pages. But building that, not using web technologies, meant that some things were subtly not right. Selection behavior wasn't there, context menus not there, just things were subtly different. So we scrapped that and we built the new tab page using web technologies and now it fit better. We didn't have all those little, niggling little bugs. It felt natural. It felt natural, it fit with the product. On the flip side, we had some dialogues and some of those dialogues, mostly they were built natively, but a few of them were built using web and they never felt quite right. So then we came to discover that let's be opinionated about this. If it's a dialogue, it's done natively and if it's in the content area, it's done with the tab. Then we avoid this uncanny valley situation. When Chrome came out, there was a designing for best viewed in Internet Explorer 6. It's interesting you say that at the time WebKit was not the priority of web developers. Now we've shifted 10 years later. We're seeing best viewed in Chrome or best viewed in WebKit browsers. So there's this constant fear that we're possibly entering back to the past where if development stops, then users and the web technology becomes stagnant. Oh yeah, it's a great question. I think that there's a couple of different things that happen with IE6. First off, Microsoft stopped evolving the APIs and we're not stopping evolving the APIs. Our mission is to make the web better and so we continue to invest in that. And the way we invest in that is it's very important to work with the standards community, the other browser vendors in particular and web developers so we get it right. One of the dangers of shipping an API if you're the only browser shipping it is that you might come to find that there's a better way to do that API. A better design. And then the end result is we'll be tempted to ship the new design as well, the better design. But we'll have trouble leaving behind so now we'll ship two ways to do something. Or in the worst case, three ways to do something. If you look at CSS gradients, you will see there's multiple ways. And this comes from this phenomenon where a browser ships it early, then they learn that oh gee, I wish I'd done it differently. And then they ship it that way too and then oh gee, I wish I would do it differently and they ship it that finally and so you end up with a multitude of ways to do things and the web platform gets really complicated and we don't want the web developer to be thrashed by all of that. We want to keep it simple and make sure the APIs work well. So we want to do a good job and that means spending time with other browser vendors, spending time with web developers, learning, understanding all the use cases and being very deliberate in the standards process. But we should still be able to ship something finally and sometimes we do have to take some calculated risk. Sometimes we are the first browser to ship an API but we hope to do that in a way that stands the test of time. You're looking for pain points and you're trying to understand why it is that people have these problems so that you understand their mental model and you avoid designing in that way again.