Transcript

00:00:00 - Speaker 1: So we think a lot about how do you give agency back to people, but we think about if this is your web browser, this is your operating system, this is your home on the internet, how do you feel agency over Hello and welcome to Meta Muse.

00:00:16 - Speaker 2: Muse is a tool for thought on the iPad. This isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins, and I’m here today with my colleague Mark McGranaghan. Hey, Adam, and a guest, Josh Miller. Hello. Thanks for being with us here today, Josh. You’re an accomplished entrepreneur and also have a background in both the startup world with Branch, which I think later became part of Facebook, but also you’ve done a stint in government with the White House, if I’m not mistaken, and nowadays you’re working Obama White House just want to clarify that.

00:00:51 - Speaker 2: Fair enough. And now you’re working on the browser company, which is super interesting. Why don’t you tell us what you’re doing there?

00:00:59 - Speaker 1: Sher, thank you so much for having me. Honestly, I feel like I’m at Whole Foods right now doing my grocery shopping routine, listening to this podcast. So, uh, really awesome to hear that intro live and grateful to be talking to you both.

My name is Josh, uh, working on the browser company.

As the name might imply, we’re oddly fascinated by web browsers. We feel like we spend a ton of time in web browsers in 2020, too much time, maybe, and as we were looking at the kind of arc of web browser technology, it felt like the interface of the web browser and the jobs it did for you. It was fairly stagnant and honestly was just curious about why and what else it may look like. So there’s a group of about 10 of us, uh, in a room together, well, I guess a metaphorical room together experimenting pretty widely about what a web browser reimagined for 2020 might look like. So figuring it out as we go along and really happy to be here. So thank you for having me.

00:01:54 - Speaker 2: We’ve had a lot of informal chats through Twitter and other kind of conversations, but where maybe I really felt like I got my head around what you were doing was when your colleague Nate Parrott came and did a little workshop for the ink and Switch crew to show us the experiments you’re working on, and that was very. Interesting partially, you know, just to see inside the machine and what you’re doing, but also because it seems to me like you’re really taking what I would call a research approach. I think you are a startup or a venture funded startup. Is that the correct characterization?

00:02:23 - Speaker 1: Yes, that’s a correct characterization. I agree with that statement.

00:02:28 - Speaker 2: But even so, it seems like this approach you’re taking these very throwaway experiments while you figure out what your initial product is going to be as opposed to the maybe the more classic mode that I’m used to, which is you start with an idea that you love, you build that until it’s clear that it’s totally unviable and then you pivot to something else when you’re forced to.

That’s a different approach.

So when Nate demoed to the switch crew and it was really interesting to see those experiments, but he said something. In particular, that gave me an idea for a topic here, which is, he said, OK, we’re not innovating on the browser engine. Things like JavaScript run times and how the HTML is rendered and all that sort of thing. There’s been incredible technology developed on that in recent years. You’re innovating on the interface, all the stuff that goes around that core engine. Can you expand on that for us a little bit?

00:03:17 - Speaker 1: Sure, of course. First, worth noting. I am one of many people on the team, so I appreciate being the representative, but you know, everything I say, I’m trying my best to speak for everyone else doing the real work back in the office.

In terms of innovating on the interface, I think the thing I want to touch on first was your comment about the R&D and experimental approach, because in some ways, that’s the core of our product philosophy.

Whether or not it’s correct or not for us or others. I think with our first company, Branch, we’re 20 years old. Didn’t know what we were doing. We still don’t quite know what we’re doing, but we know a little bit more. And in our first company much more focused on let’s whiteboard everything, and then let’s mock up three directions, and let’s narrow it down to the best answer, and that will be the best answer and let’s go build that. And I think from our experience and maybe just our dispositions as creative folks, very much believe in that no one has any idea of what they’re doing. And in many ways, some of the most interesting innovations may sound like a dramatic word, but the most interesting progressions of interfaces and software products we’ve loved and we’ve built have sort of been accidental or if not accidental, we never intended them to be that big of a deal or that part of the product or that part of an idea to be that interesting. So from a philosophical perspective, our view on product iteration is bias towards experiments, quick experiments, hacking. Experiments, be intentional about what you’re trying and why, but be open-minded and succumbed to the fact that you don’t really have any idea what’s going to be meaningful and what’s not. So I think that’s generally our orientation, which I should note, we think is great for our specific prompt and our specific team. I don’t think is the only way to do things. And so for I just want to represent that as one viewpoint and one lens which we take to the product problem.

00:05:02 - Speaker 2: I was just gonna support your sort of we don’t know what we’re doing and that’s fundamental to innovation. I like the Einstein quote, which is, if we knew what we were doing, we wouldn’t call it research. So I think of it as a discovery process that doing something new that no one has done before fundamentally means no one can know what they’re doing and you kind of have to embrace that a little bit, have this beginner’s mind, this humility, and just realize that it’s, it’s more of a treasure hunt than a Engineering project.

00:05:32 - Speaker 1: Yeah, I have one story on that note from a mentor of mine when I was 20 maybe. I really looked up to Evan Williams.

He was the co-creator of Blogger, you know, really the publishing platform that in many ways popularized what we know is the concept of blogging.

Then he went on to co-create Twitter. Obviously we know the impact that Twitter had on publishing in the world, and then went on to work on Medium, and I idolized him in a way when I was 19 or 20 because what passion for a single problem and what from afar looks like he had it all figured out. It was just over the arc of time, he was gonna come up with all the good ideas and just came out of him effortlessly and when we were 19 or 20, I had the lucky fortune of Getting a meeting with him and convinced him to kind of mentor us and invest in our first company branch and invited us to come work out of his office in San Francisco after he left Twitter and was sort of in R&D mode. And we viewed this as this aha moment. We were working on this new publishing platform. It was gonna be a different thing, and we had the Godfather, the genius, the expert that was just gonna tell us how to make it the next big thing, cause here’s the person that knew everything about publishing. And in our first meeting together after we moved to San Francisco, I laid out this 6 month plan with a bunch of questions for him of is it the right plan. And he stopped me, he said, Josh, I hope I didn’t get your hopes up. I have no idea what the right answer to these questions are. And actually, quite frankly, let me give you some advice. I’d be aware of anyone in Silicon Valley that purports to have the answers to questions like these, we’re all just making it up as we go along. We’re all just trying our best. So, let’s keep talking about this. I’m really excited. But I don’t have the answers and no one does. It’s obviously one worldview, but it was a very humbling, informative experience to hear the co-creator of blogger Twitter and Medium say, I’m just trying my best to making it up as I go along. And I’ve continued to subscribe to that worldview and philosophy as I’ve had a little more experience building software. It’s not the only one, but it’s definitely the one that I believe in.

00:07:31 - Speaker 2: Yeah, I can see why that would be really powerful, and there is clearly a skill, a talent, a whole world of capabilities for effectively searching for something new or a better way of doing things, improved technology and improved design, what we’re kind of broadly calling innovation here. So it can be tricky when I do describe this kind of process to others or you hear someone really successful like Kevin. Williams talk like in the story you just told that it seems like, well, we’re just making it up as we’re going along. It doesn’t mean that there isn’t a skill there and a structured way to go about this and discipline that’s needed and that there’s, you know, certain teams that can be really great at doing that and others that struggle more, but it’s a different mindset than this visionary top down. I just woke up one morning with the future in my mind and now I’ll spend the next 10 years building it according to that plan. It’s a very different mindset.

00:08:25 - Speaker 1: I think that’s totally right, and I think I describe it as a spectrum, and either end of the spectrum, in my opinion, is too far, and so one end of the spectrum, as you described, top down, we know the answer, we just have to build it. Other side is, we’re just aloof floating through the world, hoping to stumble across the next thing. I think every team that I’ve known that is extremely effective at interface innovation and Development has their own part of the spectrum, but I think in my experience, I’m curious to hear from you, Mark and Adam, is our teams that are very principled in what they are building for and why they’re building it and opinionated at that highest level motivating factor. So as an example of the browser company, I’ll share two hypotheses that end up becoming thematic buckets for experiment. One is our view is that if you look at the browser in 2020, it’s actually more like an operating system, not in the technical sense of the word operating system, but it’s no longer one of many applications on your computer that you go to momentarily to surf the World Wide Web and track down information. You’re doing all of your work in the browser, all of your apps, all of your documents. And so that’s a hypothesis and a principle, which suggests a certain type of opinionated experimentation and exploration, even if the exact implementation is something that we believe we don’t know and we’re gonna have to find out. I think another one is we think a lot about digital spaces as being analogous to physical spaces, and you think about a living room or a bedroom or an office, and those rooms are supposed to make you feel a certain way, and they may look different, even if they, from a utility or features perspective, all have chairs, you sit in them, you can exist in them. Generally speaking, they make you feel a certain way. That’s not as low level as we have a feature idea that we know is gonna work, but it’s not so vague that we could just build anything and count it as progress. How do you think about this Muse? I’m curious what your principles are. So I mean, first off, it’s worth stating, I know you invited me on this podcast. I’m on this podcast right now cause I am obsessed. With everything that you’re building at Muse, and ink and Switch as well. And I’m inspired by the way you do product development and interface innovation. It sounds like directionally, we’re pretty aligned in the way that we build things, but how do you think about somehow narrowing down the scope of what you experiment on while also leaving open the possibility that you actually have no idea what’s gonna work?

00:10:54 - Speaker 3: Yeah, well, first of all, thanks, Josh. I do think what you’ve described reflects the attitude that we have at Muse and ink and Switch.

This kind of goes back to the previous episode where we talked about principled products where I do think you can’t expect to get there with pure brownian motion, you know, just randomly bouncing around. You need some sort of principle, vision, direction, valence, something that kind of tends to pull you and the team together in a unified way in some direction. I think that can take different forms. It could be principles, it could be this kind of postulates, it could be hypotheses, it can be an end goal that’s important to everyone. You just need something that’s kind of pulling people together. Another comment I would make is this idea of balance between theory and practice is also reflected in the literature on technological development in general. If you look at how things have improved in our material world, this is a point that’s made on the Roots of Progress blog by Jason. I’m sorry, I forget his last name, but Jason Crawford. Jason Crawford, there you go. Thanks, Adam. He makes this point that if you look at an empirical matter, innovations that have happened, they tend to be from groups that have been kind of bouncing between the realm of theory and practice, and both of those inform each other. And so I think that is reflected in how we work on software at Mu and Inc and Switch where we have some theories that are developing over time, and we have some experiments, some tests, some engineering, you know, field work, and Those kind of go back and forth, and you can’t expect to get very far just on one of those two legs.

00:12:14 - Speaker 1: One thing I’m curious about that we’ve thought a lot about, and I’m not sure we have the right answer, is I’ve seen some teams where the principal or guiding light is a hypothesis about what’s possible with software, or what’s possible from a product.

Some people call it jobs to be done. I think other teams articulated in terms of a target demographic. Uh, elementary school teacher, a back end developer in Silicon Valley.

I’m curious as you think about Muse, what I find so inspiring about the product is the tool for thought aspect that can be melded to my own instantiation of tools for thought and what I want to think about. I can imagine that direction is also difficult at times to know who you’re building for. How do you think about that balance between what and why, who, and I’m, there are other vectors I’m not covering. How do you think about that?

00:13:07 - Speaker 3: So there are some direct answers I can get to that. Maybe I’ll actually give Adam the chance to kind of articulate the specific things that we think about there. But I would also point out that I don’t think we can actually always expect to be able to articulate what’s drawing us in a particular direction. This is a kind of Hayekian idea where you Yeah, the hunch thing is a big part of it.

00:13:26 - Speaker 3: Yeah, just because something can’t be written out in words or articulate doesn’t mean it’s not there in people’s implicit knowledge. And so that points to another. The thing we very often use to draw us in directions, which is the energy that an individual person has for some idea. And that often just ends up being a quite good predictor of promising areas.

00:13:43 - Speaker 1: I’m so happy to hear that because I wasn’t sure if I was going to share that part of our process, because it’s true to us, but I don’t know how quote unquote good it is, is we are so motivated by the energy and emotion of the team, maybe to a fault, but I think, you know, I previously worked at Facebook and I think that a lot of large organizations, they’ve codified their approach to product development.

This often may look like a design document that has a goal, problem statements, set of assumptions, input data, and you almost have to justify what you work on in a relatively formulaic way, which I think is extremely effective.

Again, I think there are many ways to build products.

We find ourselves a lot, oftentimes all of us are the plurality of us coalescing around a single idea or direction. And oftentimes, as you point out, it’s hard to justify it empirically, and it’s just something feels right, or we’re energized by it.

In the early days of the browser company, we’ve definitely been driven a lot by that.

It’s felt great so far, but it’s definitely a different posture that I’m sure has pros and cons, but I’m excited to hear that Muse works that way as well, because we found it to be really fun and fulfilling.

00:14:48 - Speaker 3: Yeah, and to be clear, you often have this raw data that’s influencing these opinions. So we have some use cases that we have in mind. We have some archetypal people that we’re working for, we have some technology theories, and those end up influencing the directions that we’re personally excited about pursuing. It’s just that you can’t always expect to be able to formulaically in close form, describe, given these inputs, here’s the function that determines where you should go next. Totally.

00:15:13 - Speaker 2: Mark and I might have talked about this before, but I think of the active entrepreneurship and product creation, which to me the building the company that builds the thing and building the thing is one unified whole, but there to me it’s about half and half or for me to be satisfied with the result. I think it has to be this balance of practical business needs to have customers and solve a problem they have in a way that’s useful and fits into their life for.

Price that they find fair and that you have a reasonable distribution channel and all those business fundamentals, you have to have that, but then it’s also an act of expression, artistic expression. There’s something inside me that I want to express, something meaningful that I have to say, or me and my colleagues, part of the reason we’ve banded together is we think we have a thing to say together, we share some values or some sense, this hunch, this drive to make something that doesn’t exist in the. and I think that part of it, it really is like an art project, like painting a painting or writing a book or or something like that.

You just have a thing you want to express, but part of the fun, intellectual challenge, satisfaction, but also hard part is actually balancing those two things together.

And so it does mean on one hand, for example, following that energy that you’re both describing that feeling of like this seems right, there’s something here, let’s pursue this. That that building what’s in your heart is the way that my colleague Ryan sometimes put it. I think you have to do that, but you can’t do that at the expense of building a business that has those fundamentals, or you can, but you know, that works until the VC money is gone and then you won’t get more of it. So I think it’s that balance between the two that’s what makes this act such an interesting act of creation.

00:16:53 - Speaker 1: I think the discipline that balances this very well at their best are architects.

So for example, we’re working on collaborating with the architect David Adjay. He designed the Museum of African American History in Washington DC and if you look at the building, it is very much an artistic expression.

There’s a story behind it. You feel Adjay’s personality in the building, you feel his heritage and the heritage of. People he’s commemorating in the building.

And you better believe in Washington DC at a publicly funded museum, there are some budget constraints, and there are some ADA rules to comply with, and there are bathrooms to build, and so I don’t yet know, and I don’t know if I’ll ever know how they do it, but I think architecture, not only for the analogies between digital spaces and physical spaces, but I also think for the mixture of practical realities.

Jobs to be done, combined with artistic expression and emotion and personality.

I’ve always admired how the greatest architects seem to tread those very, very well.

00:17:55 - Speaker 2: I see a lot of parallel there as well. I’ve read a number of architecture books less because I want to ever design or build a building and more that I see these really strong parallels and on one hand, yeah, you’re trying to express something beautiful that is art or can be, but at the same time, your building has to stand up. It can’t go down when the earthquake hits. People need to move through it. People have physical dimensions that need to be accommodated. Air needs to flow through, light needs to come in. Right?

00:18:19 - Speaker 1: You need HVAC. HVAC’s not pretty.

00:18:22 - Speaker 2: Yeah, exactly. That brings to mind.

I’m looking at some images here of the museum you mentioned of course I’ll link that in the show notes. It also brings to mind. I saw this fellow, Danish fellow Jark Ingalls, I think.

The name speaks some years ago and the Netflix show Abstract had featured him in an episode, and he’s a really good example of almost avant-garde, very kind of forward thinking to the point of being quite weird sometimes with his designs, but also really Sort of challenging the status quo and again, same thing listening to him talk about each building and sort of what he was trying to express through that and how that fit into the time and the cultural moments and whatever else felt very close to some of my motivations when I start companies and build software.

00:19:05 - Speaker 3: Yeah, and also to connect this architecture topic a bit to interfaces, it reminds me of the book A Pattern Language by Christopher Alexander. So this is a book that basically catalogs patterns and architecture from the very small to the very large that Alexander had observed as being successful over decades and hundreds of years of people interacting with buildings. So the very small scale it might be that people really like to have shelving at waist heights. That’s kind of where you conveniently put stuff. At the very large scale, it’s like your city should have greenery accessible to people within, I don’t know 10 minute drive or something.

And the patterns in the book are very interesting, but also the way that he arrived at these understandings, which are basically about interfaces between people and buildings, is observing, it’s kind of this like archaeology of what has actually worked over the many years that people have interacted with buildings.

And I think it’s interesting that with software, we’re now getting enough data where we can do that, and instead of having to invent things from first principles, we can say whenever people use software. They really want to like cut out stuff and like put it somewhere temporarily and hold it. And that’s something that it’s really important that software does. And you don’t need to invent that idea from first principles. You can just observe that people want to do that all the time. I think there’s a lot of opportunity in there that can draw on this kind of pattern language type thinking.

00:20:15 - Speaker 1: I think that’s a great connection and making the connection back to interfaces again, a thing we and I have struggled with is When do you reinvent the wheel? When is it worth questioning the interface, given that there are these patterns in the physical and digital world that over some number of years, decades, we have proved work extremely well and evoke a certain type of feeling or action. When do you question them and when do you accept them? So in our first company Branch, you know, being 20 reinvent all the things. You have a follow button, we have a watch button. You have vertical comments, our comments branch to the side. And it felt like, because it can be so exciting and tempting to question and reimagine interfaces because they are spaces and touch points that we encounter so much in our day to day life. There is an excitement to the novel, and there’s an excitement to the new.

But as I learned, and you’ve probably learned, I think the more advanced or accomplished product designers are the ones that know what to focus on, and they know what are the highest points of leverage in the interface, or what are the parts of the interface that are. broken and deserve reinventing.

And so one thing common conversation we have at the browser company is, should we be reinventing the wheel here? Is this the right place to focus on pushing the boundaries? Again, I cannot purport that we have a good answer to those questions yet, or that we’re experts on this topic. But I do think it’s a temptation and a talent to know when do you rely on Christopher Alexander’s-esque observations about patterns that are wonderfully human, and when do you question whether or not we’re doing things the right way.

00:21:58 - Speaker 2: To even ask the question, when do we reinvent and when do we go with the known pattern is the right place to be.

I think there’s a natural tendency certainly goes with youth. I was there as well at age 20 which is you just want to blow up the status quo because that’s like in your spirit at the time. That’s what young people want to do.

And definitely entrepreneurs, I think, are by their nature, people that like change, novelty, new things, shake it up, try something new, blow it all up, and then you have others who Maybe you’re more stasis oriented, like to conserve, protect, go with what’s working, tradition, that sort of thing.

And I think the art is to learn to step back from either of those tendencies wherever you may naturally fall and instead try to analyze where is there opportunity, where is there something that society can really benefit or individuals could benefit from a reinvention and a rethinking versus we have a known pattern that works and, you know, stick with that.

00:22:55 - Speaker 1: On that note, earlier in my career personally, I think I fancied myself more of an artist. I’m giving myself a little hard time and being a little self-deprecating, but I think I viewed things like revenue strategy and business model and market structure as being things that corrupted the creative process and the innovation on interfaces process.

And I spent two years working at an investment fund. Observing the sort of startup technology landscape from a venture capital perspective. And one of the things that struck me is that some of my favorite products from uh innovation on interface’s perspective actually fundamentally took advantage of business model innovation and misplaced incentives in generating the product experiences that I, from an emotional perspective, fell in love with and changed my experience.

We’re actually driven from looking at where companies Incumbents were making money saying, wait, that seems a little flawed or perverse, and extrapolating from there. And so I think even that’s interesting to say, even if you care about feelings and emotion and the way buildings hit the street, sometimes to know where to focus can come from something that could be as boring to some as, well, how’s the incumbent making its money? What incentives does that cause? One example from Facebook, Snapchat, one of its core innovations, was opening to the camera. And, you know, it’s hard to imagine that. That was a huge deal. Talk about interface innovation. It broke every rule in the playbook of social networks.

00:24:27 - Speaker 2: I was actually going to cite that exact one, which is in the Snap S one, they actually articulate this pretty well, which is they consider the camera in the phone to be the most important interface, and they lead with that on absolutely everything from their little snap codes to the fact that the apps open straight into that. And it’s more obvious now we live in a world where smartphone cameras really are this cruel. crucial input device alongside touch screens and keyboards and whatever else, but probably at the time you’re talking about, that was quite a shocking idea.

00:24:58 - Speaker 1: Yeah, and I don’t purport to suggest that Evan Spiegel was motivated to put the camera first from a business perspective, but if you have an incumbent like Facebook who monetizes through showing ad units in a news feed right when you open the screen, structurally, they are not incentivized and it will be difficult for them to compete on that vector.

We think about this at the browser company. As you mentioned earlier in the podcast, Chrome and the Chromium team specifically is responsible for insane technological progress on the browser front, and we’re building on the backs of that and grateful for that.

From a business perspective, Chrome is useful to Google because it’s lead generation for search ads. The more you use their web browser, the more you use the internet, the more you’re gonna do searches on Google. The more searches you do on Google, the more ads they can show you. And if you talk to their the Chrome team members, they’ll even explain the genesis of the Chrome team was not that they wanted to go into the browser market. They just thought Internet Explorer was so shitty with all of its IE toolbars, that it was making the internet experience poor. And if the internet experience was poor, you’re gonna do far less Google searches. And so that’s interesting and at the time that was novel. Flash forward to today, Google and Chrome are not incentivized to make a more feature rich. Powerful web browser that stretches the definition of what a web browser is, not because they’re not capable, not because they’re not creative, but their incentive structure from a business model perspective is one in which they just want you to type little searches in that URL bar as much as possible. So if you open 40 tabs, that’s 40 potential Google searches, and so it’s not that clean as anyone that’s listening to this podcast that has worked at a large organization like Google. I’m dramatizing a bit, but again coming back to interface innovation. And where do you know where to focus? I agree that often that comes from energy, often that comes from principle and product hypotheses, and oftentimes it might come from looking at the market structure you’re competing and say, where is everyone else weak, where are they incentivized, and what sort of perverse side effects does that lead to?

00:27:04 - Speaker 3: Yeah, this is actually a big part of the ink and switch and muse origin story where we had observed the economics of the industry were very heavily rotated towards a social slash advertising and be enterprise sass, and those were the most obvious things to make. economical and so the lion’s share of work in the industry was being put behind those to the exclusion to our mind of classic creative computing for individuals. And so we saw an opportunity product wise that was like you said, kind of created by the economic dynamics.

00:27:34 - Speaker 2: I think it’d be interesting to return to the item you brought up earlier there, Josh, about the kind of operating system, the web or the web browser is kind of a set of operating system primitives that sort of exists separately from the host computing operating system.

I strongly agree with your characterization there that the web is kind of its own OS and in fact OS. It has a really specific meaning in terms of kernels and. Vice drivers and things like that, but I think of it more as the operating environment or the way in which the mental models and the set of primitives that you interact with.

So on classic desktop computers, that’s things like copy paste, files, mouse cursor, maybe on Mac OS you have the menu bar at the top or on Windows, you have the start menu in the lower left, and then the web and the web browser has its own set of those core primitives that includes URL. includes something like the back and forward button, maybe something like tabs was a major interface innovation that came from the sort of Mozilla Firefox early days, and I see a similar thing for Muse as well, which is for Muse I see something similar, which is I in many ways envision Muse as kind of being a reinvention of the file browser, something like the Mac OSinder or even. stretching back to the DAS days, something like Norton Commander, the files, I think are this cornerstone primitive in how we interact with computers, particularly how professionals interact with computers, but in many ways they’ve kind of aged to the point and become very static in a way that they haven’t really made this jump to, for example, the mobile world very well. And a lot of the way we think about Muse, or at least I do, is as taking this set. Of things that typically are part of the operating system, essentially how you manage your digital stuff which is expressed as files on a file system, but bring that into a mobile touch, you know, more visual interface. What can we bring forward that works really well about files and then what are things that maybe we want to leave behind and embrace more modern elements that have been brought to us from, for example, the touch environment. So I’d love to hear what you see as being the areas your team is either currently working on or just most excited to innovate on in terms of the browser as a set of operating system primitives.

00:29:51 - Speaker 1: Sure. So we think about the answer to that question really is a series of observations, and really the observations that guided us wanting to start this company. Some of those observations include, if we looked at our Mac OS docs and we looked at the quote unquote local applications we use the most, obviously they were all internet-based, but they were also all built on Electron, which meant they were secretly just Chrome, which means we were running 7 versions of Chrome on our computer instead of just a single browser. So that was interesting.

00:30:20 - Speaker 2: And just for listeners that might not know it, Electron is kind of a container that lets you run a web application as if it was something native to Mac OS or Windows.

00:30:31 - Speaker 1: And it’s an incredible technology in the sense that as a budding group of developers, you get a ship a cross-platform application that feels native to the operating system without writing native code. And so grateful for Electron, we’ve prototyped an Electron. It’s a great technology.

But as you’re pointing out, we actually ran this early experiment where we launched the Notion app. We use Notion. I love Notion. The company runs on Notion, so this isn’t a criticism, but we launched the Notion Electron app, the local quote unquote Mac app, and then we built a prototype of our browser which was just the pure internet. There was zero browser Chrome, and we loaded Notion in that, and you put it side by side, and it’s almost indistinguishable which one is the Mac app and which one is the local app. That doesn’t suggest what we’re building, that doesn’t suggest how to make a better browser, but it just struck us as an observation as, huh, hmm, that doesn’t seem like it makes a ton of sense.

Another one is, if you think about Mac OS, you talk about the file system. A large reason operating systems exist is to help us manage our files, and that files mean more and more things, but all of our stuff.

I observed again. Just for me, I feel like I live in a post upload world. My files are all permalinks, random strings of characters that I enter in my web browser. I have Figma URLs, I’ve notion URLs, and so on and so forth. And so even from a file and folder perspective, I’m looking at my desktop right now. I got nothing but a conglomeration of screenshots that I wish would go away and I didn’t intend to be there. All of my files are in the browser. And so on and so forth. So I think, you know, I was a sociology major in college. I’m inspired to work on technology and software and interfaces, not because of the technology, but because of the people. And so I think as we just observed how people are already using their desktop computers and how they’re already using web browsers, it just invoked a series of questions and observations that, again, we’re trying to answer, we don’t have answers to yet. We may never answers to, but just struck us as almost cultural shifts in how we use technology that may just maybe may warrant a new browser interface that could look more like an operating system. But at the end of the day, my wife, my mom, my niece, I don’t think they care at all about the word operating system. And so we also think a lot about what are the metaphors or what’s the right way to talk about the scope of our work that is not just geared towards people on this podcast.

00:32:58 - Speaker 2: Could you give us a hint of some of the stuff you’re working on? I noted here on your recent tweet of comparing kind of a browser to a figma canvas. Obviously things of spatial zooming interfaces are of particular interest to me. I think again your colleague Nate there tweeted some short videos that he used at that. You want to speak to that or give us another example of what sort of things your team is doing to try to push the boundaries or to try to improve what a browser experiences for a power.

00:33:27 - Speaker 1: Sure, I think first and foremost, I’ll plug Nate Parrott, a designer on our team who, one of the things he does, which I love, is we share, I don’t want to call them failed experiments, but past experiments that we learned a lot from, but weren’t quite right.

00:33:42 - Speaker 2: The primary output was learning. Yes, exactly.

00:33:45 - Speaker 1: That’s what we talk about those. Exactly.

So if you’re curious, I think better than my terrible radio voice, I check out Nate’s Twitter account and he shared a series of these, and we’ll continue to share more.

I think that just building off of the canvas prototype that you reference, what Adam’s talking about is we prototyped a view of a web browser, which is, imagine all of your web pages or tabs, lay down, if you spread out a big white sheet of paper on the table or desk in front of you, and each 8.5 and 11 piece of paper that you plop down on it was a web page, what if that was your interface for navigating and interacting with the internet and your web browser? Because it was tweeted, it did not quite work, but I think, you know, one of the themes that that touches upon is an observation we made about the way we use web browsers is when the concept of a web browser was originally popularized 25 years ago. The internet was a document network. It primarily revolved around retrieving and finding and reading information.

00:34:45 - Speaker 2: Sure, well, I mean, it was invented by a physicist working at CERN that wanted a way to share his research with other researchers, right?

00:34:52 - Speaker 1: And it was wonderful.

And however, in 2020, I’m doing everything in my personal life in the web browser. I’m doing everything in my professional life in the web browser.

In my professional life, for example, that can mean focusing on a specific task and writing a long document and not wanting to be interrupted. It could be going on a rabbit hole late at night.

Probably some of the topics we’re talking about today. I’m gonna go Google them later, and 8 hours later, I’m gonna end up in some random Wikipedia link.

And given the breadth of parts of our Life we turned to the web browser for. And given even within those parts, the different modes or moments that we rely on the browser, it just seems silly that every incumbent browser was a one size fits all. The window never changes, the tab bar never changes. It’s all the same all the time, completely consistent and unchanging. Which could be correct, you know, the counterargument to this perspective is that there’s some solace or comfort in the fact that you know what it’s gonna look like.

Our view is, if you take the analogy to the real world, sometimes you want to read in your bedroom, sometimes you want to read in the living room, sometimes you wanna host a party in the dining room, depending on what You’re doing and what part of your life and the time of day and how you’re feeling, you might want different spaces.

And so what would that look like in the web browser if there was no Chrome whatsoever? What if there was nothing? It was just a pure web page.

What if you had 28 web pages tossed onto a table and you could move them around and see them spatially? What if there was a view to, you know, manipulate 13 at a time and take bulk actions and move things around and export them and I’m kind of making this up as I go along. I’m not suggesting that our final product or current product has all these things, but that’s an example of starting at the top level principle, how we end up going down, down, down to prototype that might be, what would FIMA look like if it was a web browser, for example.

But what about a use? I think you are tackling an equally broad and large surface area. So how are you? in recent days prioritizing what you work on.

00:36:51 - Speaker 2: It’s hard. My experience has always been if you’re working in a company you’re on a product that has a lot of possibility, it’s very fertile territory, and the biggest problem you have is in fact being pulled so many directions because there’s so many great things you could make, or as I think there’s a quote somewhere that’s great startups die of indigestion, not starvation. We definitely feel that in MS, there’s so many directions we want to go from new kinds of content type, video and tweets and lots of other things we have on our list, but there’s a whole other track that has to do with kind of collaboration and sharing, whole other track that maybe has to do with kind of programmability, whole other track that has to do with much more powerful kind of spatial manipulation and non-spatial manipulation, and it’s all really good and all potentially really valuable and You know, that’s even combined with the small things that users are asking for, at least once you, you know, are to the stage that we’ve been at for a little while now, if you have a pretty solid user base and they’re using it for real things in their daily life and there’s a steady stream of bug reports and small feature requests and things like that. So it’s tough to find the right thing and keep your focus, but you really do, especially with a small team, you know, we’re 5 people and don’t really plan to expand beyond that foreseeable future. It’s so critical.

To come together, consider all the options, but then pick a thing and say, we’re gonna do this for a little while because we think this is a really compelling space. We like to kind of time box that. We’re gonna spend 2 months going really deep on one theme, see how far we can get on that, and then step back and, and see what we’ve learned.

00:38:20 - Speaker 1: Yeah, and it’s worth noting for us at least, as much as it’s fun to talk about these heady directions and observations, and it’s earnest and genuine.

At the same time, if my team was here, they would point out that some of our favorite features and honestly favorite themes of directions have come from very quote unquote uninspiring simple couple hour feature development that actually turned out to feel a lot better than we thought.

I’ll give you one tangible example. We multitask a lot in our browser, as I’m sure everyone on this podcast does, and we prototype the ability to click a tab and drag it and drop it on another tab and automatically create a split screen mode that you can move the dividing bar left and right and kind of adjust the view of the split screen. Drag and drop for split screen, not inspiring, no one’s gonna come work for us because of that. And it was fucking fantastic, and one of our most used features, cause guess what? What do people do today or some people do? They open a second window, they resize both windows and do this dance where you pull that corner up and that corner up and so it may not be part of a connection to architecture or anything that gets us really excited, but turns out it’s damn useful and the fact that it was that useful, even if it was that small, suggested a kind of direction to keep exploring. So I think it, it would be honest, most honest to also mention that it doesn’t always come top down from themes. Actually, I found more successfully it comes from tiny little features and extrapolating, like, why did that feel as good as it did? What does it suggest and you go that way?

00:39:57 - Speaker 2: Yeah, well, I think the bottom up extraction of the pattern and that there is a bigger theme there that points to an underlying need that maybe you could double down on.

It’s not, hey, we just made a small random thing and it happened to work, maybe sometimes that’s it, but probably someone on the team followed a hunch or did something according to what they saw from user behavior. It worked out way better than expected, and then you can stop and reflect on why.

Why did this work so well? Why is a side by side of two tabs? Why is that? Key to how people use the web and what can we learn from that and maybe there is a bigger theme we can work up to from there.

00:40:30 - Speaker 3: It’s funny that you mentioned fluid multitasking. This is something that we’ve studied a lot in ink and Switch and Muse because our user research has shown that’s very important for the creative process.

It is an overwhelmingly common thing that you do. You have a few documents open, you want to read them and put them at the same time.

But notably, it’s still an unsolved problem on iOS.

You basically can’t really do good multitasking on the platform, even on the big i. Ads. You can sort of get these sort of split screens, but they’re not fluid and they’re really hard to bring in, and they kind of go away when you’re changing them and they come back. That’s also interesting because it, uh, it’s, it’s very much dictated by the platform. So on the web, or web-based platforms, it’s quite straightforward to add a horizontal split and to fluidly move it. It’s kind of built into the engine, whereas an iOS, as it is kind of a platform thing, and if you want to do it in a way that would incorporate multiple apps you need, basically the platform’s help. So it’s a different beasts.

00:41:16 - Speaker 1: Operating systems rearing in their head.

Yeah. One thing I’d love to get your guys' advice on, uh, since I have you here, is we had an experience recently where we prototyped direction that we were super excited about, didn’t work, clearly didn’t work. There’s some things about it that we liked, but all in all, considered it uh let’s move on.

Couple months later came back and had this inkling that maybe some things had changed in our product that might suggest this feature would work again.

Tried it again, and I think specifically took it to a much higher fidelity than we had previously, and all of a sudden, I think it’s the coolest thing we’ve built so far, not to tease too much, but the larger question is, as a team that experiments widely and quickly and iteratively and is not afraid to take the research process, which means tossing stuff out.

Any tips for how do you know when it didn’t work because it’s not gonna work, and it didn’t work because you didn’t take it far enough to master the fine details that as we know from our favorite software products truly matter.

It’s just this experience, which was an accident, and again, I don’t think we did well. Makes me wonder what else we’ve missed just because we didn’t take the extra week to do that extra design polish or animation or rev on a slightly different iteration that we were so close, but we gave up because we took the wrong conclusion. I know these are very broad questions and so, you know, maybe there’s a specific example that comes to mind, but I think that’s the risk of being a team that doesn’t take to high fidelity and to user ready production code with every iteration is that some really great ideas need that in order to work.

00:42:56 - Speaker 2: Also a really tough one. I think it is largely an act of judgment or even taste, probably something you develop with experience over time, but yeah, I’ve been in that exact position many, many times and Yeah, maybe people point to that. I can think of high profile examples on that.

This is more the product level than the prototyping level, but maybe it’s a larger scale version of the same thing. Why is it that Slack was this breakout success when we already had hip chat and campfire, and most people would just say Slack was just nicer, it was just better executed. They just took it a bit further and Really put that extra polish on it. And you could point to some features or whatever, but it just had this higher degree of craftspersonship, maybe more love put into it, more attention to the user experience. It turned out group chat is this incredibly useful and central thing for many and most teams. Yeah, Slack just kind of broke through that boundary.

Another one for me that’s like that is back when I was first living in San Francisco and realized pretty quickly that a car, private car ownership was not the way to get around, but public transit was weak and whatever else, and I eventually realized taxis are a pretty good way to go when you need to get across town, but it was really hard to call one and I thought, why doesn’t someone have an app to do this? Why can’t I just press a button and summon a car to my house and I can use the GPS on my phone to know where I am. And then I was delighted when I came across someone actually in the Ruby community who was building this exact thing.

I think it was called Taxi Magic, and they hooked into the dispatch system and they would summon a taxi for you. And they even had a little map that tracked where it was. And I used it for a good while because I really wanted this product to exist, and I really believed in it and they did pretty well, but ultimately it was just kind of not a great experience and the taxi would get lost and it would take a long time or the address wouldn’t be right. And so I tried to stick with it. Then Uber comes along and they just nailed the experience completely, partially because they weren’t using the dispatch system. And that was for me and clearly lots of other people, this revelatory moment of like, wow, it turns out calling a ride from your phone is really, really great, but they didn’t execute far enough or they didn’t take it far enough to find that out.

00:45:03 - Speaker 1: One example for me that I’ve been thinking about recently is I had this moment with superhuman. I’m not sure what listeners think about superhuman, but I have found it to be a better email experience for me, putting aside the cost.

I work in email in an unfortunate amount, so I probably am more attuned to the little details and bells and whistles, but I was just floored by how fast I felt, how productive I felt using it, and my colleague turned to me and enumerated how every feature I was describing has been in Gmail for like a decade or something.

And somehow superhuman tied it together in a way, I don’t know if this was marketing, if this was design polish, if it was interaction design, if it was, I mean, who knows, but I think it’s another great example I’ve been thinking about of it’s not just about building the correct features, it’s tying them together in a way and with a level of polish that I don’t know, has that special quality to it.

And so it’s one thing to think about a production email client that you’re charging $30 a month for, but how do you know which need that extra level of polish in order to kind of break through and which things like there’s some features we’ve built where it’s, this is just so damn broken that it could be ugly, and People would flock to it.

And I think those are some of our most favorite beloved products were ones where you see V1, you’re like, that was the first version of Acme Co. but it turned out itself such an acute need that we didn’t need that last mile. But I think superhuman relative to Gmail is an example of where, like, wow, Gmail had it. I guess they’re doing fine. We shouldn’t feel too bad for Gmail, but at least at a personal level was a snooze is not new, it turns out.

00:46:45 - Speaker 2: Another piece of your anecdote about building something, not working, setting it down and coming back later, and then finding it does work. That’s something I’ve experienced a lot in my career.

00:46:57 - Speaker 3: Adam, isn’t this one of your Hiroku rules?

00:46:59 - Speaker 2: Uh, could be. I have to look it up. Yeah, certainly we talked there about throwing things away and that sort of thing, but timings, timings. That’s what it is.

00:47:09 - Speaker 1: Speaking of timing matters, yeah, I’ve been really curious at a personal level, and I think this applies to you, Mark.

How the both of you ended up trying to innovate on interfaces when previously working on a company like Hiroku or I believe Mark, you were at Stripe previously among other jobs.

Not that those products did not have great interfaces, but I assume the podcast about why Hiroku worked or Stripe worked would probably be a different number of topics than the ones we’re discussing today. So I find it really fascinating and interesting that both of you have gravitated towards Muse and the interface challenges you’re working on. Curious to hear what, if anything changed, if I’m thinking about it the wrong way, if, you know, how did you two get here from where you were before?

00:47:52 - Speaker 3: Well, there is more in common than you might think. So those are all basically tools, and there’s a lot of generalized tool thinking that goes into all three of those companies, I think, as well as obviously, you know, building software companies.

But yeah, then in terms of timing for me, I mean, a lot of it was, I had fully experienced the world of enterprise, and there’s a lot of great stuff there. And obviously it was how I started my career.

To be really honest, I just wasn’t thrilled about looking at Gmail and Google Docs for the rest of my professional career. I just couldn’t see myself being really excited. About it.

And at the same time, Adam and team were working on ink and Switch, where they had kind of the other piece of that puzzle. They saw this opportunity for developing software that’s about enabling people’s creative potential. And that really resonated with where I was at the time. And then of course, I loved working with Adam before at Hooku and I definitely want to do it again.

00:48:39 - Speaker 2: Yeah, I feel like there is a pretty strong connection to, yeah, work you did at Stripe around say APIs as well as at Hiroku. Speaking for myself, I certainly have gotten from a lot of folks that it feels like a non sequitur to go from cloud developer tools to call a productivity iPad app.

And there is obviously some big jumps to make there. There was a lot of education I had to give myself. In order to learn about building apps on a mobile platform by comparison to the web stack that I spent a lot of my life on.

But to me, there is a really a through line and a connection, which is it is about tools and enable people’s creativity and productivity, and that just gives me a thrill. And I would say at Hiroku, a huge part of that was the interface. We had to build a lot of infrastructure. Make the interface that we wanted, but I knew that I wanted this idea of servers and configuration files as being the main way that I get my software in front of my users and needing to go fucks with those every single time I want to ship a change to them didn’t feel like the right interface anymore. So I think of Haruku as primarily a whole other interface, and that of course also led us down this path of command line tool. And this kind of term developer experience, which I don’t know if we invented that, but I think we had a lot to do with popularizing it, which is the idea of, OK, just because you’re building an API or a command line, those things are very technical tools and very technical interfaces, but you can still bring the user experience design ethos that I think at the time, now we’re talking 15 years. Back was kind of on the rise with maybe more consumer products, but then you can take that same thing and say, well, developers are people too. They like nice experiences. They like tools that are easy to understand and use that serve their needs well, and they like different kinds of experiences, text-based experiences and keyboard-based experiences, and they’re comfortable learning technical things that maybe a lot of more non-engineer users would not be comfortable learning, but You can bring those same principles to bear there. So I think of Haruku very much as an innovating on interfaces and the tools for Creative people company, and then Inkot Switch was a research lab that worked on those things as well, and now Muse is, it happens to be on this other platform and have this other kind of business model, maybe even a different kind of target user, but fundamentally there is that through line that ties it all together.

00:51:03 - Speaker 3: Yeah, and back to timing. I didn’t understand this when I first started working with Adam and team at the lab, but it was definitely a big influence in deciding to go off and do Muse.

Muse is really riding a particular technology curve.

So if you look at what has happened and especially consumer and gaming, which drives a lot of the individual level of technology that we see today, you could basically plot the size, density, refresh rate, and responsiveness of touch screens over time. And if you Kind of draw those dots out a few years, you see something like, we should have a kind of small desk size touch screen that exists, and it’s quite good. And in that world, what is the software that powers it? And it definitely wasn’t a big phone. It wasn’t a desktop transliterated onto that thing. And I wasn’t convinced it was the iPad is currently existed then several years ago. I felt like you needed something quite different, and we saw a particular timing opportunity with Muse to go and try to build that.

00:51:59 - Speaker 1: I think there’s also something interesting about, I love the way you talk about both of your stories is actually there being a through line, and they’re not so different as portrayed. And I also think there’s something interesting about the merging of worlds and perspectives.

It’s one thing we’ve thought a lot about because if you had told me I was going to work on a desktop web browser in 2020, 5 years ago, I would have laughed at you.

And actually, quite frankly, the origin story was the browser company was supposed to be a web browser for work specifically and an enterpriseas tool, and I actually gave the idea to my now co-founder and former co-founder Hirsch, and I said, I think it’s really boring, but I think it’s a great idea. You should go work on it. I’ll fund you. And that was the original intention.

And then as I started collaborating with him from that original relationship, I realized that the web browser was one of the only pieces of software that is in the middle of the Venn diagram of tools and apps that my mom uses, my little niece uses, I use. The web browser is.

Almost the most consumer tool out there. And I hadn’t really thought about it that way before. And, you know, we’ve hired people from Instagram and Snapchat and take a very consumer lens.

So I think what you would say, our desktop web browser, we probably rely on more for work and getting things done than fun time on a Sunday these days. So anyways, I just think there’s something interesting in both of your stories and how you arrived at Muse and what you did before, as well as kind of how we think about the browser company, which maybe some of the more interesting interfaces we’ll find out, arrived from multidisciplinary teams that bring the intersection of different experiences that others may see as not compatible or different, but actually there’s an interesting through line, as you said, Mark, that ties them together in some way.

00:53:42 - Speaker 2: Josh, do you feel like there’s a theme or a narrative arc in your career, you know, going from social media space to government to now reinventing the browser?

00:53:54 - Speaker 1: It’s definitely the sociology major in me.

I was a pretty poor student, so I wouldn’t say I’m a good sociology major, but I’m a people person.

I literally was sitting back 90 seconds ago thinking, man, the internet is so fucking cool that I met you guys through the internet, reached out cold.

We’re now having a podcast, having a topic about something that I would love to geek out more, but I don’t feel like I have an outlet to do it.

And so what drew me to technology is like this podcast is happening right now and how cool is that? And I think I am driven by people and what we do and what we do together, and That’s what drew me to, you know, I also did urban studies and urban planning in college. I just like the meeting places of people and the ways in which we come together, and I think the internet’s one example of that. Public policy and our government’s one example of that, and the civic Commons, a web browser is one of those things, and so I think that’s the through line for me personally.

I mean, I’ll tell you a quick story about the way I even got into technology. I was interning for my senator. I did random internships. Definitely never thought about technology. And then a professor from Harvard came to guest lecturer named Robert Putnam, and he wrote a book called Bowling Alone. And Bowling Alone is about social capital, and the decline of social capital and these kind of meeting points in the real world where you bump into your neighbors and fellow citizens, and what that is doing for society. And I was just floored by it. And I went up to him after and I said, Hey, Professor Put. I’m Josh. What should I do with my life? And he sort of said, I don’t know you and I have no idea, but if you liked my book in this lecture, there’s this entrepreneur in New York who started a company after he read my book and he was inspired too, so you could go work for him. And that company was Meetup and that entrepreneur was Scott Heiferman, and I went to intern at Meet Up, and the first day at Meetupp, I went to an all hands, and Scott got up on stage and gave this impassioned lecture about the internet was bringing us together and we were turning away from banks with Kickstarter and it was bringing us together and we were turning away from universities and it was a little idealistic, and I’m not sure it played out exactly right, but it was damn inspiring. And I, he took me to an event called the New York Tech Meetup, which, man, 8 years ago was a bunch of people in their 20s, mostly getting on stage and being like, I built this for fun, check it out. And there was no anything other than that enthusiasm, and so I think for me personally, it’s even the way I arrived the technology was through meeting spaces like meet up and meetups and yeah, for me the through line is people and what we do together and I think This podcast is a great example of that of how we got here.

00:56:40 - Speaker 2: I actually like that so much. I almost feel like that should be our closer, but I wanted to ask what other major topics we should make sure we don’t uh leave off.

00:56:49 - Speaker 3: One thing I wanted to be sure we touched on was the topic of scripting and extensions. So we’ve long been interested in the ink and Switch lab with this topic of end user programming, people customizing their own computing, things like that. And there’s also this great history in the browser of web extensions, Greasemonkey, people fiddling with everything, and that seems like it could be up your alley, Josh. I’m curious if that’s something you and the team have thought about.

00:57:13 - Speaker 1: This topic gets me so excited, unreasonably excited, so I’ll try and keep it short. I had this formative moment where, again, I’m a sociology major and so I’m not the most technical person in the world, but I remember one of the first times I used the inspector in Chrome, and I realized I could delete that damn annoying Twitter sidebar with all the trending like I can delete it. I can edit the internet like I can make it, I can make that go away. That’s a thing I can do.

And it was this moment where if you’re an engineer, you know that, but as a plebeian over here, I have been taught since day one, more or less that I live within the spaces that people create for me, and I’m beholden to their buttons and to their flows. And so at a personal emotional level, that was like wow.

Now obviously there are a lot of things that web apps like Twitter and Facebook do to make that very hard, but I think the concept of Greasemonkey and user programming, whatever you want to call it, fascinating. I think I would take it up one level though.

And I think we think about in terms of agency, which if you go back to the metaphor analogy to physical spaces, and you think of the web browser in 2020 is almost our digital home because of the time we spend in it, we all live in the same home that basically looks the same.

At best, we live in prefab houses where you can pick like one of 5 variations and you get one of 3 countertops.

That doesn’t feel very human. That doesn’t feel like it acknowledges the unique personalities and spirit and needs of every individual in the world. And so we think a lot about how do you give agency back to people.

Scripting is one way to do it. It can also be somewhat exclusionary. I think there are tons of avenues you can go down to give people agency.

But we think about if this is your web browser, this is your operating system, this is your home on the internet. How do you feel agency over it in the same way you feel agency over, I like the little lamps that I’m looking at behind you, Mark, like you got a spirit and style and agency over that room, you should have that over your computing tools as well.

00:59:11 - Speaker 3: We’ve thought about this scripting and extensibility question quite a bit in the lab, and honestly, we found it pretty gnarly because there are several things you probably want in a system.

You want the system to give the user agency, as you said, but you also want it to be pretty fast so that you can have high performing, high quality software. You want it to be secure so that the users aren’t getting their data or systems compromised, and you also probably want some amount of consistency across the platform so people can develop for it in some coherent way.

And there’s a bunch of existing systems, but they tend to compromise on one factor or another. So for example, Unix is scriptable with C, but it’s a total, you know, wild west on the security front. And the web is scriptable with JavaScript to some extent, but that has performance challenges. iOS takes away the agency leg, but gives you all the other things. And so we haven’t found a good way to get all these at the same time. So I’m wondering if that’s a problem you’ve grappled with in the context of giving users agency in the browser.

01:00:07 - Speaker 1: You have to grapple with it. I’m not sure we have a great answer yet, but I would say one of the ways we think about the browser in general is trying to come from somewhat humble perspective of we’re not the end all be all.

Our goal is to not build the only and the best browser for everyone. And if anything, our theory is that actually what’s missing from the browser landscape is that all the browsers look the same, and they all do the same things, and there’s very little variation.

But the internet is such a diverse place in terms of the people and needs and all of the above, that we need more diversity in our browser tools and capabilities. And so I guess what I would say is in this theme, I think what exists is tools that are more restrictive today, and they’re for a good reason often, right? So I don’t think there’s nefarious at tent. I think it’s often the name of the things you’re talking about, especially in Chrome, keeping you secure, speed, exactly what you said. To us, I think what’s missing is further down the agency side. Now they’re trade-offs, as you say, security, performance, etc.

However, I think one of our philosophies is, if you are transparent and you’re communicative, trust people to make the best decisions for themselves, right? So if we tell you, hey, be careful in this regard, or just so you know, this is gonna happen, giving people the option, I mean, that’s what agency is. The whole theory of agency is that you should have control over which set of trade-offs you care about.

Now, I don’t think this can apply across an entire. Your browser product. I think you definitely want performance, you definitely want security. You definitely want consistency and interface. And so I think even if you believe in agency and you believe what’s missing from our software tools, especially in the browser space, is giving more agency at the risk of security at moments or privacy moments. I think they’re natural limits, but I think it’s all about being forthright and transparent about the trade-offs and giving people the option to decide which tools they use and when. Again, I know it’s very broad, but I think again going back to the like, I want to delete the Twitter sidebar, is that gonna break every few weeks with certain Twitter release cycles? Yeah, why don’t you let me know that, and maybe I can fix it if it’s so valuable for me, versus what I think most people say is, man, we can’t perfect it. It can’t be a delightful, perfect experience and thus we’re not gonna build it. Who are you to decide what I need and what I want? Now, I think that’s where the chrome extension landscape comes in and serves this need another way. But I think what’s missing right now is tools that push the agency side more. And I think one example of this, it’s only slightly further, and it’s not what you’re talking about, is notion. And I think it’s still far in the spectrum of lockdown control, not a ton of agency. Anything’s a page. Put pages within pages. Put whatever you want in a page. It’s like, it feels so freeing in a way that, as you know, notions actually not that free, but almost felt revelatory to use where it’s like. Yeah, you know what? Fuck this layout. You know, I wanna put a database in there. Like, let me put a database in there. Like that’s really cool. And I don’t care if everyone wants to use it. And I’m sure Air Table’s a better equivalent of that specific block, but maybe people don’t want the best database ever. They just want a database on this page. Let them do it. So, I don’t know. The risks, and I would love to hear your skepticism about that or pushback or things that you would encourage us to think about as we kind of go down that route or explore that route further.

01:03:29 - Speaker 2: I certainly think that the tradeoff element and let users decide, even letting users decide what trade-offs they want to make is a trade-off, and I think this is something that is part of the discussion, particularly in the tech world now, because you do have folks maybe that have been in computers a longer time, someone like me that grew up with them, we’re used to this great deal of agency because the whole thing had this very DIY sense to it, and computing tools have gone so much more mainstream. And now the things that make them more accessible is taking some of those choices away from people. So when you get the lockdown phone, whether it’s iOS or even Android has very aggressive sandboxing and sort of the mobile operating systems are very, very limiting on that agency side by comparison to classic desktop computers, and that’s really a feature because the average person that’s using a smartphone for the first time or even just in their daily life, that doesn’t have the Time and desire to invest in learning all the things about the trade-offs they will get if they can, you know, run arbitrary scripts, for example, it’s actually better for them, or at least the market seems to indicate that it is better for them to be able to get this lockdown device that doesn’t allow them choices. Then there are people who do computing things for a living or want to invest that time or they have needs because they’re power users and they need powerful tools and they need to customize those. for their needs, for their work or for whatever needs they have, and then they’re annoyed and frustrated at the feeling of being dumbed down for the sake of security and walled garden stuff and even something like performance. So I think that’s, yeah, the trade-off can be in the choice for a trade off as well.

01:05:09 - Speaker 1: One idea that we briefly considered and I’ve since tossed, but I’d love to get both of your feedback on because it relates to this is. What would it have looked like if we built a browser that was more of a platform that let anyone make their own browser, and not anyone make their own browser in terms of my mom, but a lot of the work we’re doing, we have an infrastructure engineering team.

My first startup did not have an infrastructure engineering team. There’s a lot of work we’re doing to allow ourselves internally to innovate on the browser and on the interface level. What should tabs look like? Should there be tabs? Where should they go? What color should it be? And we’re gonna make a series of opinionated decisions. Some of those opinionated decisions may involve giving users agency over the decision and the output, but it’s still an opinion. What would it look like to almost offer a browser as an infrastructure platform or service where you can make a new browser, you can make a Slack browser, and we’ve abstracted all the complexity, so you gotta make your ideal browser, make a brows.

Those are for architects, go for it. Who cares if 10,000 people use it? It makes you happy and that’s enough for you to make a small business.

I’m obviously sharing this level of detail because we decided it’s not in the spirit of what we want to do. But I’m curious, do you think that that’s a good idea? Should we be an API driven company and we’re striped for web browsers and let the web browsers flourish and the browser for everyone and all the colors and all the shapes, or is that a step too far in terms of agency?

01:06:31 - Speaker 3: No, I mean that kind of circles back to my original question, right? So there are two ways you can think about how you get more stuff on all these axes.

One is you can make different trade-offs. So you can choose 7 on performance, but only 2 on security or vice versa, depending on what you want. And it’s good to have different people choosing different things. But there’s also a sort of production possibilities frontier to borrow a term from economics where, given the technology that we Have broadly defined.

There’s only so far extreme that you can go in all different directions at one time.

That’s kind of what I was alluding to is if you really want to go high on performance, you have to compromise something else right now, for example. But you can develop new technologies.

So, for example, rust gives you basically all the expressivity of C and all the performance of C, but it’s much more secure. And that Required a big technological investment because before you had to make some trade-off there if you want to get see like performance with safety and to use, you know, for example, a higher level programming language that was much slower.

So what I think we need in addition to all these experiments with picking different points in the space is something that actually expands the space.

So you’ve described it as one way, as a platform for writing a new web browser, but you could also say in the same way that, you know, a web browser is. of analogous to an OS, you can write an OS that gives you an expanded frontier or a new programming language or a new runtime. You know, they’re all kind of variants in the same theme of technology that gives you a, a bigger expanse of space to choose from. And I think that’s a really important research project. I’d love for us to do something like that in a lab or to help someone do it independently.

I think it’s a really important problem.

01:07:57 - Speaker 1: In and Switch browser collaboration. You heard it here first. Muse browser coming 2022.

01:08:04 - Speaker 2: Well, if any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museapp.com via email. We always like to hear your comments and your ideas for future episodes. Thanks for coming on to talk browsers with us. Josh seems an area of mutual interest. I suspect we could fill at least another episode on interfaces and operating systems and browsers and more importantly, the people, which is frankly why we’re doing it all.

01:08:31 - Speaker 1: Thank you so much for having me and just like I met you as a stranger on the internet, you’re to meet all of your listeners at some point too, so thanks for having me.

01:08:39 - Speaker 2: All right, see you guys later.

01:08:41 - Speaker 3: See you, Adam.