How We Designed Chrome – Designer vs. Developer #20


DARIN FISHER: And the team at
Google that started on Chrome was actually– we were
all working on Firefox. MUSTAFA: When you ask
people, what do you want? It’s always they
want more and more, but they never use those things. And it’s really hard
and a quite brave thing to say now 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, and
Firefox was fighting it, and the developer tools were
becoming quite prevalent, and 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? DARIN FISHER: 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 beginning of 2005, the idea was to work on
making the web better, and one way to do that is 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 build
our own browser. And that was a big,
complicated decision, because we had already been
going down a certain path. So looking back, I think
there are a number of factors. First off, we thought we
could do a really good job, so that had to be true. But also there were a lot
of things about browsers in those days that I think
created a frustrating user experience. Going back to 2006, 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. 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 X. Could we use preemptive
multitasking? Could we take advantage of
actually multiple processes on these systems
for web browsing? It seemed pretty–
like, actually seemed possible if
you were thinking about a browser from scratch. MUSTAFA: In terms of the UX of– again, it’s like going back
to the beginning of browsers or the browsers of that time. It reminds me a bit like
Search before Google. Search was basically
portal sites, and the search input
field was like the most least important thing. But then Google came along. It’s like, no, no, that’s
the wrong user experience. When Chrome came about, it
was quite radically different. Because I know you
remembered 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 installed Anythink. [INTERPOSING VOICES] DARIN FISHER: In
fact, 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 these great
absurd screenshots of people whose browsers
had like five toolbars and there’s not a lot
of room for the content. 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 a proper way to do toolbars or sidebars. We really didn’t want
extensions or you could really– you know, using up screen
space when that screen space, the 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. And even the UI of
Chrome itself, we tried to keep it
very minimalistic. 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. And what does that mean? It’s got to have the
most amazing features. It’s got to 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. And we tried many
different things. Putting tabs on the side, 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 that what actually
we were doing, and what really would
set Chrome apart, is that it was a browser
that just works better. Like, creating software
that’s not frustrating is actually hard to do. And I think users appreciate it. And so started to
think about it and what does that really mean for us. It was like, all products
should be simple. Try to come up with
an elegant UI choices. Keep it simple. It should be performant. But 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. Par for the course those days
was you click to close the tab and you might see a
beach ball on Mac OS X, or nothing happens on Windows. You start to see
the “application not responsive” prompt. 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. Those are examples of responsive
UI that sometimes when we talk about
performance, speed, we mean, like, how well did
it perform on a benchmark? But a lot of times
it comes down to, was the experience smooth,
responsive to the user input? 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 Ss. 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. 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, our
browser more secure. And finally, it helped
a lot of stability. We knew that starting from
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? We based the browser
on– not on Firefox, we based it on WebKit, which
was what in 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. Modern web standards
driven by Firefox were just becoming a thing. Internet Explorer has had
a lot of quirks about it, Internet Explorer
6.0, a lot of quirks, especially thinking
about like flow– out with the flow. MUSTAFA: Focus model. DARIN FISHER: Yeah,
the box model. All these things are
very impactful to like how web pages are built.
If a developer was testing a lot with Internet
Explorer, theirs 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 this very. And so it was a big
challenge and a big fear when we launched
Chrome, is it going to just crash all the time? How are we going to manage that? So we put a lot of effort in. And in fact, that same
issue informs 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 “does it work” conundrum. MUSTAFA: We always taught in
software development and UX, add more features, because
more features means more value. So I mean, was there a pushback,
or was there like a fear, maybe we’re taking away too
much from the browser UI? DARIN FISHER: We
certainly, I think, we 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 going into it that
we would probably throw away things that aren’t good. That was the, I don’t
know, the mantra, if you will, like, let’s
just try a lot of stuff. And if it doesn’t work, it’s OK. 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 different–
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. MUSTAFA: Looking
back, what would you say were the best
decisions you made? And also– a two-part– what
would you regret in terms of, like– DARIN FISHER: Oh, yeah. MUSTAFA: –things that you did
that you’d wish you hadn’t. I mean, you can [INAUDIBLE]. DARIN FISHER: So
I’m an engineer. I was definitely an
engineer at those days. And I feel really
good about some of the decisions we
made as an engineer, from an engineering focus. You know, we really
put a lot of– we talked a lot
about how important it was that we were
building a product, not building a platform. I mean, 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’ve 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, you know, 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, 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 as 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. MUSTAFA: Yeah. DARIN FISHER: And later
on, things like Android came along, and iOS– MUSTAFA: [INAUDIBLE] DARIN FISHER: –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 help me build that product across
n different platforms. And that came afterwards and
I think that was actually somewhat healthy. In 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. I don’t need to be extra– we don’t need all
that extra modularity. And now we find
ourselves wishing we had maybe done a little
more forethought on that. MUSTAFA: What would you
say the decisions that were made that were
actually really good to the success
of the browser? DARIN FISHER: 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 that the content area of a
tab, 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 develop– users kind of this expectation
that things inside the tab behave like web pages. But building that not
using web technologies meant that some things
are subtly not right. Selection behavior wasn’t
there, context menu’s not there in the
same– you know, just things were
subtly different. And 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. MUSTAFA: It just felt natural. DARIN FISHER: 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. And so then we came to
discover that, like, 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 a tab. And then we avoid this sort
of uncanny valley situation. MUSTAFA: When Chrome
came out, there was a designing for best
viewed in Internet Explorer 6. And 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 crime 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. DARIN FISHER: Oh, yeah,
that’s a great question. I think that there’s a
couple of different things that happen with IE6. So 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 that we 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 one, 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 the old design. 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
they would do differently and they ship it that final way. 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 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 in API, but we hope to do that in a way
that stands the test of time. SPEAKER: 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
a vote designing in that way again.

Be the first to comment

Leave a Reply

Your email address will not be published.


*