Seemed fitting.

-Mark

Our original 3-month goal was to investigate what a browser designed in 2016 would look like.

(Of note, this is different than exploring what an implementation of the web’s platform should look like — see Project Quantum and Servo for that.)

In those three months, we experimented with lots of different parts of the browser: from the way you navigate, to the way you save things from the web, to the very way in which the front-end for a web browser is built.

Now that the initial project is over (in fact,was over a few months ago…), it is time to look at if and how we move forward. The Engineering Update for Tofino post by Joe Walker is live, and posts from the product and UX teams will follow, but at the high level this is what we learned:

• User testing our concepts ahead of even completing a prototype was extremely valuable.
• Boy howdy do normal users have hard time with non-conventional browser interfaces!
• A User Agent Service is a good idea. We want one in Firefox, like, yesterday.
• Writing a new browser UI in React is flexible and easier to develop in than XUL. Mixing XUL and HTML in a single product/interface was harder than we thought.
• Electron is great for prototyping, but some work is needed if you want to build a full browser.
• Getting out of our Firefox developer bubble and engaging with new open source teams and projects was great. So much awesome feedback and energy!

So what is next?

The ideas behind the user-agent service and a React UI sound good on paper, but do they work in practice, and are they useful to Mozilla? The User Agent Service is designed to store a broader set of data than Firefox Sync can currently handle, but we’re not sure if can it scale up with large volumes of data or if it’s as flexible as we need.

There could be lessons from our React based UI that we can take into mainline Firefox. To that end Dave Townsend is going to be starting with TabBrowser and seeing if there are things that Firefox can learn and we’re going to continue to evolve what we’ve got to be more workable.

We’re going to continue using an environment that makes it easy to prototype fast. We’re not wedded to Electron (far from it) but the fast prototyping aspects of that have been really nice.

It’s also becoming clear that the name Tofino doesn’t really work with what we’re doing now; What we’re working on now is less of a product or user experience exploration, and more of a set of technologies that need testing out, so we’re renaming the group to the Browser Futures Group.

We’re working on a roadmap.

Tofino is dead — Long live the Browser Futures Group.

A brief aside: We briefly called this team the Browser Research Group, and asked for help picking a new name. The internet provided! Background: Naming things is always hard.. so a brief clarification is required because I agonized over using the word Research. The timescale of our ‘research’ is short (months rather than years) and what we’re doing is closely aligned to the goals of the Firefox product organization — i.e. building and shipping a popular browser. The team does not do the kinds of research Mozilla Research in our Emerging Technologies group does, things looking years ahead like Rust and Servo and WebAssembly. Calling the team the “Browser Innovation Group” felt even more awkward. Got a better name suggestion? Comment below!

(Re)defining the Tofino Project was originally published in Project Tofino on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last time I posted, I talked about Content Blockers. We ended up making one, and the world didn’t end. Yay! Blogging helped me sort it out in my own head, and that helped identify a path forward at work. So I’m going to do some more blogging, because I’m kicking off a new project which triggered a bunch of soul searching about products, innovator’s dilemma in particular, and what taking risk feels like. Maybe talking about it will help me sort some of this out. So, here we go.

Let’s jump right in and say yes, the rumors are true, we’re working on browser prototypes that look and feel almost nothing like the current Firefox. The premise for these experiments couldn’t be simpler: what we need a browser to do for us —both on PCs and mobile devices — has changed a lot since Firefox 1.0, and we’re long overdue for some fresh approaches. It’s worth noting that we have a ton of work underway on our flagship product, Firefox, that’s all about evolving the browser experience. Not to mention the huge bet we’re making this year that we can get the biggest changes to Gecko we’ve ever attempted (e10s) to land so that Firefox is on a healthy, competitive footing for years to come. But it’s not enough, when someone has a totally different idea they want to explore.

We’ll blog on the Project Tofino Medium channel about the project itself, but what this and subsequent posts are mostly about is thoughts on what the business of doing “innovation” at an organization that has a lot to lose feels like. It feels hard. Up to this point in my 20 year career (20 years? right?!), I’ve never experienced anything quite so “textbook innovator’s dilemma” as my last year at Mozilla. Let me explain. What’s probably not surprising is that the team that builds our browser has a lot of great insights and ideas about how people actually use browsers and the kinds of problems people have that aren’t currently solved by anybody’s browser product. Also likely not surprising is that said team would be stoked to build an entirely different kind of browser focused on solving those problems. Focus. Freedom. Yes! What’s not intuitive to anybody that hasn’t experienced the backside of a very successful product run is that creating something new and different is incredibly difficult. Every little decision can bring crushing stop energy. At an academic level, this is fascinating. Everyone’s read about this in books. When you live it, it’s very personal. The reason new things at old shops is difficult, mostly, I think, isn’t because people are bad, or stupid, or actively sabotage new projects or any nonsense like that. It’s largely because doing anything that might conceivably impact the current product creates unavoidable tension. Nobody likes tension, so you replace it with that self-created stop energy. Innovator’s dilemma is a real thing.

For example, the prototype we’re feeling good about right now is built with Electron and React, not Gecko and XUL (our go-to technologies for building browsers). For a small team starting out pursuing a new product concept it’s a great choice — Electron is a wonderful tool for us to do prototyping with — but a simple decision like picking the right tool for the job becomes an epic FUD generator when it could be perceived as threatening to the existing product. Immediately, you worry. Does it signal we don’t believe in Gecko? What will the platform team think? Will they believe us that the project has nothing to do with technology selection, that’s what browser.html is for? What if web developers think we’re abandoning Firefox, and Gecko? We’ll lose on web compat, and nothing will work in Firefox! Consumers will abandon Firefox in droves! We’ll lose our influence at the W3C! OMG the web is dead! I’m not making fun of that. I’ve had all of those thoughts. And spent countless hours thinking about how to deal with the others that will inevitably have them too. Before you know it everybody involved is spending countless hours worrying about about outcomes that we aren’t in control of anyway. Not having an awesome Firefox will kill Firefox. End of story.

There’s a great deal we don’t know about creativity and innovation. But the research does suggest some patterns are more common than others. You can expect tension. No amount of “messaging” can work your way out of that. The tension will be there, you have to accept it, or you never move. There will be risk. Again, accept it or you never move. You should trust in small, cohesive teams. You should support them, and encourage risk taking. That’s often referred to as “creating space”. My personal experience has been that all these things are true, but I’ve also seen that if you make the innovation process “easy” whatever is being built ends up sucking. Especially at the front end of the process. Maybe it’s because ideas are free to create and valueless on their own. I don’t know.

In that spirit, today I’m placing a bet on a small, cohesive team that for the last 6 weeks spent hours I know for a fact they didn’t have, hacking on an idea they simply refused to let die. God knows the last month of stop energy should have killed it. Years of fear of hurting Firefox, by rights, should have never even let the idea germinate. But somehow they held on and fought for it.

We’re setting up the project a little differently too. The team is not open for internal transfer. The team no longer has access to their own calendars. They’re being unsubscribed from all email lists. They’re not going to attend even a single Mozilla meeting. We’re kicking off in person, everyone in a room, in Tofino on Vancouver Island where the idea for this UX direction originated last summer, and from there we’re going to co-locate the core team in Vancouver for 3 months. That’s how much time I’m giving the team to prove there’s something here that we could turn into a product. If not, we kill it. We’re not going to expect help from anyone at Mozilla and we’re not going to distract the other 95% of our team that’s doing hero work on Firefox.

Origin stories have always fascinated me, and when I look back, a great deal of Firefox’s origin story is not well known. Whether a successful product or feature set comes from this project or not, I can’t say, but I’ll at least document the story of how we’re building new browser experiences inside one of the world’s most experienced browser teams. I’m looking forward to being their story teller!

Browsers, Innovators Dilemma, and Project Tofino was originally published in Project Tofino on Medium, where people are continuing the conversation by highlighting and responding to this story.

Boy there’s been a lot of attention on content blocking in the last week! Apple entered the debate with the blunt instrument that is Safari / SafariViewController for iOS9, and all of a sudden everyone noticed. As they should. Tim Bray’s Money and Ads on the Web links to a bunch of writing worth reading, and I’d recommend Zeldman’s piece on Ad Blocking and the Future of the Web as a must read. But for all the reasonable, intelligent articles that try to wrestle with the fact that content blocking is a complex issue, it pretty much boils down to this:

Kontra on Twitter

Then Users: Please DoNotTrack me AdTech+Publishers: Screw you Now AdTech+Publishers: Please DoNotAdBlock me Users: Screw you

I’ve spent a lot of time in the last year thinking about how to evolve the web’s relationship with ads responsibly, and you see that work shipping in Firefox’s Tracking Protection for Private Browsing mode, which is moving to Firefox Beta tomorrow, and also in how we designed Tiles for the new tab page to respect user choice and privacy. I’m really proud of the work we did, and I’ll talk more about it soon.

Right now, though, in the middle of all this attention around content blocking, what I’m struck by is that the web’s model allows us to have a debate about content blockers at all. The web is still fairly unique in that its fundamental architecture is built around a “user agent” that sits between the publisher and consumer and that agent mediates the experience. Also of note, the web browser is the only agent the user chooses separately from content (thx for reminding me, @osunick). It’s a pretty powerful model that has benefitted all parties involved over the last 15 years, and without that design tradeoff we wouldn’t be having this debate at all. The web’s kinda old, yeah, but it’s still got some fascinating properties that differentiate it from everything else!

The other big thing I’ve been thinking about over the last week is whether I should have had my team build a Safari content blocker. We considered it, debated it, decided against it, and in retrospect, I suspect I held too tightly to an opinion that Apple was being irresponsible in their pursuit to harm Google by implementing content blocking with little to no user interaction capability. “We’d never ship something this crude!”, I argued. An opinion rooted in the fact we’ve had the technical ability in Firefox to do what Safari is effectively doing for over a year, but we decided that we didn’t have good enough answers to “well, what should the system work like, then? how and why do sites get on/off these lists?” and until we did we wouldn’t ship for general browsing. This is where Apple differs from a pure web browser vendor like Mozilla, I suppose; Apple has an answer for publishers to the often shitty experience of web advertising: don’t use the web, use apps with iAds, use Apple News, use Apple Music, use Apple… Apple’s answer isn’t a better web, really, it’s Apple’s iOS ecosystem.

It’s not too late, of course. We know how to build for iOS, have the policies/tech/lists we developed for Tracking Protection in Firefox, have no need to ever charge money (and therefore, arguably, no potential conflict of interest) for a content blocking app or list curation service, can credibly say we could operate in the open with transparency, and of course we have a running theory that users might want Mozilla to have a part in how this plays out on iOS.

Whereas Marco just didn’t feel good about the success of his #1 app, I think for many folks at Mozilla it just doesn’t feel good for us NOT to be there for our users, skin in the game, working to make the web better, despite the severe limitations that Apple’s placed on developers implementing content blocking.

A final thought on Apple and the web. John Gruber argues that the outcomes, whatever they may be, should not be framed as “Because of Apple”, but as “because of us”, and that’s true but I think he is underestimating Apple’s influence and role in this somewhat. First with Flash, and now with content blocking, Apple is shaping the web as we know it. It’s almost ironic, then, that while the health of the web isn’t top of Apple’s mind (hurting Google and advancing their own ecosystem clearly is), they have an uncanny ability to create these watershed moments that force the web to adapt and get better.

This is my first Medium post, go ahead and note it up and I’ll use that feedback to evaluate whether or not I should post more these sorts of personal self-doubt-meets-product-strategy pieces! (only half joking..)

Content blocking is the web at its best was originally published in ART + marketing on Medium, where people are continuing the conversation by highlighting and responding to this story.