For several months now, a small team at Mozilla has been exploring new ways of building a browser. We called that effort Tofino, and it’s now morphed into the Browser Futures Group.

As part of that, Nick Alexander and I have been working on a persistent embedded knowledge store called Project Mentat. Mentat is designed to ship in client applications, storing relational data on disk with a flexible schema.

It’s a little different to most of the storage systems you’re used to, so let’s start at the beginning and explain why. If you’re only interested in the what, skip down to just above the example code.

As we began building Tofino’s data layer, we observed a few things:

• We knew we’d need to store new types of data as our product goals shifted: page metadata, saved content, browsing activity, location. The set of actions the user can take, and the data they generate, is bound to grow over time. We didn’t (don’t!) know what these were in advance.
• We wanted to support front-end innovation without being gated on some storage developer writing a complicated migration. We’ve seen database evolution become a locus of significant complexity and risk — “here be dragons” — in several other applications. Ultimately it becomes easier to store data elsewhere (a new database, simple prefs files, a key-value table, or JSON on disk) than to properly integrate it into the existing database schema.
• As part of that front-end innovation, sometimes we’d have two different ‘forks’ both growing the data model in two directions at once. That’s a difficult problem to address with a tool like SQLite.
• Front-end developers were interested in looser approaches to accessing stored data than specialized query endpoints: e.g., Lin Clark suggested that GraphQL might be a better fit. Only a month or two into building Tofino we already saw the number of API endpoints, parameters, and fields growing as we added features. Specialized API endpoints turn into ad hoc query languages.
• Syncability was a constant specter hovering at the back of our minds: getting the data model right for future syncing (or partial hosting on a service) was important.

Many of these concerns happen to be shared across other projects at Mozilla: Activity Stream, for example, also needs to store a growing set of page summary attributes for visited pages, and join those attributes against your main browsing history.

Nick and I started out supporting Tofino with a simple store in SQLite. We knew it had to adapt to an unknown set of use cases, so we decided to follow the principles of CQRS.

CQRS — Command Query Responsibility Segregation — recognizes that it’s hard to pick a single data storage model that works for all of your readers and writers… particularly the ones you don’t know about yet.

As you begin building an application, it’s easy to dive head-first into storing data to directly support your first user experience. As the experience changes, and new experiences are added, your single data model is pulled in diverging directions.

A common second system syndrome for this is to reactively aim for maximum generality. You build a single normalized super-flexible data model (or key-value store, or document store)… and soon you find that it’s expensive to query, complex to maintain, has designed-in capabilities that will never be used, and you still have tensions between different consumers.

The CQRS approach, at its root, is to separate the ‘command’ from the ‘query’: store a data model that’s very close to what the writer knows (typically a stream of events), and then materialize as many query-side data stores as you need to support your readers. When you need to support a new kind of fast read, you only need to do two things: figure out how to materialize a view from history, and figure out how to incrementally update it as new events arrive. You shouldn’t need to touch the base storage schema at all. When a consumer is ripped out of the product, you just throw away their materialized views.

Viewed through that lens, everything you do in a browser is an event with a context and a timestamp: “the user bookmarked page X at time T in session S”, “the user visited URL X at time T in session S for reason R, coming from visit V1”. Store everything you know, materialize everything you need.

We built that with SQLite.

This was a clear and flexible concept, and it allowed us to adapt, but the implementation in JS involved lots of boilerplate and was somewhat cumbersome to maintain manually: the programmer does the work of defining how events are stored, how they map to more efficient views for querying, and how tables are migrated when the schema changes. You can see this starting to get painful even early in Tofino’s evolution, even without data migrations.

Quite soon it became clear that a conventional embedded SQL database wasn’t a direct fit for a problem in which the schema grows organically — particularly not one in which multiple experimental interfaces might be sharing a database. Furthermore, being elbow-deep in SQL wasn’t second-nature for Tofino’s webby team, so the work of evolving storage fell to just a few of us. (Does any project ever have enough people to work on storage?) We began to look for alternatives.

We explored a range of existing solutions: key-value stores, graph databases, and document stores, as well as the usual relational databases. Each seemed to be missing some key feature.

Most good storage systems simply aren’t suitable for embedding in a client application. There are lots of great storage systems that run on the JVM and scale across clusters, but we need to run on your Windows tablet! At the other end of the spectrum, most webby storage libraries aren’t intended to scale to the amount of data we need to store. Most graph and key-value stores are missing one or more of full-text indexing (crucial for the content we handle), expressive querying, defined schemas, or the kinds of indexing we need (e.g., fast range queries over visit timestamps). ‘Easy’ storage systems of all stripes often neglect concurrency, or transactionality, or multiple consumers. And most don’t give much thought to how materialized views and caches would be built on top to address the tension between flexibility and speed.

We found a couple of solutions that seemed to have the right shape (which I’ll discuss below), but weren’t quite something we could ship. Datomic is a production-grade JVM-based clustered relational knowledge store. It’s great, as you’d expect from Cognitect, but it’s not open-source and we couldn’t feasibly embed it in a Mozilla product. DataScript is a ClojureScript implementation of Datomic’s ideas, but it’s intended for in-memory use, and we need persistent storage for our datoms.

Nick and I try to be responsible engineers, so we explored the cheap solution first: adding persistence to DataScript. We thought we might be able to leverage all of the work that went into DataScript, and just flush data to disk. It soon became apparent that we couldn’t resolve the impedance mismatch between a synchronous in-memory store and asynchronous persistence, and we had concerns about memory usage with large datasets. Project Mentat was born.

Mentat is built on top of SQLite, so it gets all of SQLite’s reliability and features: full-text search, transactionality, durable storage, and a small memory footprint.

On top of that we’ve layered ideas from DataScript and Datomic: a transaction log with first-class transactions so we can see and annotate a history of events without boilerplate; a first-class mutable schema, so we can easily grow the knowledge store in new directions and introspect it at runtime; Datalog for storage-agnostic querying; and an expressive strongly typed schema language.

Datalog queries are translated into SQL for execution, taking full advantage of both the application’s rich schema and SQLite’s fast indices and mature SQL query planner.

You can see more comparisons between Project Mentat and those storage systems in the README.

A proper tutorial will take more space than this blog post allows, but you can see a brief example in JS. It looks a little like this:

// Open a database.
let db = await datomish.open("/tmp/testing.db");

// Make sure we have our current schema.
await db.ensureSchema(schema);

// Add some data. Note that we use a temporary ID (the real ID
// will be assigned by Mentat).
let txResult = await db.transact([
  {"db/id": datomish.tempid(),
   "page/url": "https://mozilla.org/",
   "page/title": "Mozilla"}
]);

// Let's extend our schema. In the real world this would
// typically happen across releases.
schema.attributes.push({"name":        "page/visitedAt",
                        "type":        "instant",
                        "cardinality": "many",
                        "doc":         "A visit to the page."});
await db.ensureSchema(schema);

// Now we can make assertions with the new vocabulary
// about existing entities.
// Note that we simply let Mentat find which page
// we're talking about by URL -- the URL is a unique property
// -- so we just use a tempid again.
await db.transact([
  {"db/id": datomish.tempid(),
   "page/url": "https://mozilla.org/",
   "page/visitedAt": (new Date())}
]);

// When did we most recently visit this page?
let date = (await db.q(
  `[:find (max ?date) .
    :in $ ?url
    :where
    [?page :page/url ?url]
    [?page :page/visitedAt ?date]]`,
  {"inputs": {"url": "https://mozilla.org/"}}));

console.log("Most recent visit: " + date);

Project Mentat is implemented in ClojureScript, and currently runs on three platforms: Node, Firefox (using Sqlite.jsm), and the JVM. We use DataScript’s excellent parser (thanks to Nikita Prokopov, principal author of DataScript!).

Addition, January 2017: we are in the process of rewriting Mentat in Rust. More blog posts to follow!

Nick has just finished porting Tofino’s User Agent Service to use Mentat for storage, which is an important milestone for us, and a bigger example of Mentat in use if you’re looking for one.

What’s next?

We’re hoping to learn some lessons. We think we’ve built a system that makes good tradeoffs: Mentat delivers schema flexibility with minimal boilerplate, and achieves similar query speeds to an application-specific normalized schema. Even the storage space overhead is acceptable.

I’m sure Tofino will push our performance boundaries, and we have a few ideas about how to exploit Mentat’s schema flexibility to help the rest of the Tofino team continue to move quickly. It’s exciting to have a solution that we feel strikes a good balance between storage rigor and real-world flexibility, and I can’t wait to see where else it’ll be a good fit.

If you’d like to come along on this journey with us, feel free to take a look at the GitHub repo, come find us on Slack in #mentat, or drop me an email with any questions. Mentat isn’t yet complete, but the API is quite stable. If you’re adventurous, consider using it for your next Electron app or Firefox add-on (there’s an example in the GitHub repository)… and please do send us feedback and file issues!

Acknowledgements

Many thanks to Lina Cambridge, Grisha Kruglov, Joe Walker, Erik Rose, and Nicholas Alexander for reviewing drafts of this post.

Introducing Project Mentat, a flexible embedded knowledge store was originally published in Project Tofino on Medium, where people are continuing the conversation by highlighting and responding to this story.

Any list of learnings has the potential to sound very negative (as a list of battles it’s likely to focus on imperfections); but if this was just a list of the obvious things that we tried and which turned out to work fine, there would be little point in reading or writing it.

With that in mind, here’s what we’ve learned so far.

Electron

As an application platform, Electron is fantastic for building small simple client applications that involve a single main window. For larger applications it’s likely that you will need to fork Electron in order to get what you need. Project Tofino runs on a fork of Electron already and Brave does too.

A few examples of issues that we have run into:

• By default Electron ships with video and audio codecs that require licenses for use. We’re not lawyers, but it might make sense to consult one depending on your use-case.
• Electron is not designed to build browsers. There are some cases where web behaviours are broken and can’t be fixed without breaking Electron functionality (e.g. window.open() not returning values that web content would expect).
• The Electron process model uses one process per window and another process per tab. This leads to many processes when used at the sorts of scale we’ve seen from Firefox users. Since each process requires significant OS-level resources a browser is forced to do non-trivial process management (like clever shared forking) to keep overhead low. That’s likely to be hard with Electron.
• The main test harness for Electron, Spectron, has proven to be unreliable for us. On OSX we had to disable our minimal application tests since they were failing intermittently far too often to be useful.
• Because Electron uses a fork of Node, any native addon modules have to be recompiled to run correctly. This causes problems when running unit tests outside of Electron.

We’ve also found a couple of issues with the Node ecosystem, which are more obvious when delivering client applications:

• If you’re shipping code built with npm, you should really check that you are OK with shipping your code in a bundle that could be considered to have been “compiled” with GPL code. License checker can help.
• The problems of fragile transient dependencies and difficulties with npm-shrinkwrap are well known.

Electron is excellent for porting websites to the desktop, and is also great for for prototyping a new browser. It’s clearly also possible to ship a browser to many people using Electron, but at heart Electron is designed around use-cases like Atom (obviously), VS Code, Slack, etc, so it might not be the correct platform for a long term future-browser.

User Agent Service

Firefox, like the Mozilla suite before it, is component-oriented. Chunks of code like the history store, the cookie manager, and the network library are each wrapped up in a classic COM-style interface and made available to the rest of the system in a language-agnostic way. Each of these parts — UI-centric or not — is connected in a dependency web. For example, the “new tab” page, the history view, the preferences window, and Firefox Sync all talk to the same read-write history API… and classic Firefox add-ons can talk to all of these components, from the clipboard through to preferences.

Tofino evolved into a different kind of architecture, one that reflects the different challenges we face around managing change and complexity. This architecture is layered. The web rendering engine itself is self-contained, with narrow, well-defined points of integration for the rest of the application to see what’s happening — page title changes, for example.

Similarly, storage and exploration of the user’s data is contained within a user agent service — a separate chunk of code that exposes a profile data storage service over https and websockets.

This layering gives us flexibility to explore new interfaces without tying ourselves in knots. It might enable add-ons that look more like vanilla web properties which use the user agent service instead of privileged JavaScript APIs. It also enables us to work on new kinds of data storage without the complexity of multiple direct consumers.

Creating a Browser UI using Web Technology

From a UI standpoint, we’re using modern techniques for frontend development. We’re not the first to do this by any means. Browser.html, Vivaldi, Min and many others have beaten this path. In many ways Firefox itself is a precursor to this way of doing things if you squint and pretend that XUL is a widget library for HTML.

JavaScript modules and Webpack’s filesystem watching have made for quick iteration cycles, and it means we can use ES.next through Babel. This led to a world where we could write very maintainable code thanks to async/await, classes, standard imports/exports etc, all while just using F5 to reload the whole browser just like one would in a normal webpage. Hot module reloading was also useful while writing state-dependent code, like our “overview page summaries”.

We’ve chosen React and Redux for writing our UI and managing our application state. We found it good for easily writing maintainable code and quickly prototyping different views and the interactions between them. Compared to the XUL code that much of Firefox uses we think that React+Redux strongly encourages multiple developers to code with a unified style and means that our views, stores and actions are immediately alterable by someone unfamiliar with the codebase.

We discovered that we needed to be proactive about performance by automatic testing and/or careful reviews.

Furthermore, developing with React outside of the standard predefined and essentially carefully tailored environment of a web page was difficult at times. Managing non-standard DOM nodes that required non-standard attributes was unfriendly, and required either us writing custom wrappers, special prefixing with “data-”, or hacking our way through using the magical “is” component property. Subsequently this led to potential confusion due to component properties not being magically massaged anymore when they were mapped to DOM attributes: for example “className” had to be written as “class” instead, leading to easily fixable but frustrating bugs. Therefore the biggest problems in this department arose when having to deal with <webview> nodes in Electron.

Strictly adhering to the Redux model in Electron was also difficult. Single-store application state assumes a single process per application. When writing a web browser (in Electron or otherwise), dealing with multiple processes is a necessity, so the easy abstractions and “best practices” that worked in webpages were, in practice, much harder to respect. This led to an initial architecture where there were multiple application states, one for each process, with communication happening over IPC. Our final approach was to try and mimic the web and use web sockets in order to synchronize the multiple application states: after all, synchronizing multiple instances of the same application written in React and Redux is a known problem on the web and multiple solutions exist. However, it is still not clear which is the best way to handle this issue.

Next Steps

We’re currently working on two things. Having spent several months hacking on several different UI ideas, we’re changing focus slightly to investigate some more foundational problems like “remaining performant with many tabs open”, and so on. Once we have something that we feel covers the bases of at least a subset of users then we’ll return to UI experiments, so we’re shooting for a v0.1 which we’re all committed to using as our daily driver.

While we’re working on that we’re also evolving our next generation UI. It has an overview tab, allows collections of pages and shortcuts as better version of bookmarks, and allows for smarter searching in your personal history.

Often posts say things like “I’d like to thank X, Y and Z for reviewing this post”. In this case I’d like to thank Dave Townsend, Richard Newman and Victor Porof for actually writing it. The rest of the Tofino team did the reviewing. I just ran it together and tweaked.

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

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.

Conveniently, our research team was way ahead of the task and had gathered a wide variety of insights into people’s online behavior over the past years. The most recent of those efforts was also one of the most significant ones: we call it the Workflows Research and we’ll publish more on the results soon. This research provided us with insights about usage patterns, frustrations and problem solving strategies that real people use to solve real issues.

Among the workflows we picked to investigate first were comparison shopping, saving for later (and contextual recovery), and improving recurring navigational patterns (a.k.a. making it more convenient to visit the sites you go to frequently). We’ll talk more about each of the problems and solutions in another blog post. For now, let’s dive into the methodology we used to work on these problems.

After discussing what we learned through research on a topic, we started concepting with pen and paper, going broad and exploring different angles on a given problem. The big question for the design process was how we could get solutions in front of users as quickly as possible while still making sure that we got genuine reactions. I am personally not a fan of paper prototypes for two reasons: first, we can’t test them remotely, and second, they immediately move people from the role of the user into the role of the critiquer. While that would still be valuable, we were sure that we could get more value out of testing by evolving our concepts into low fidelity mockups right away. In addition, the step of turning our paper sketches into something that looks like software forced us to do one more iteration on each design, often sparking new ideas.

Since we wanted to move quickly, we couldn’t build an entire browser experience for each feature or test. All our prototypes were vertical, meaning that they allowed users to take one very specific navigation path through them. In order to prevent people from anchoring too much on their current opinions on particular browsers, we also made sure that the prototypes didn’t resemble any major browser too closely.

Each prototype explored a small domain of ideas and over the past weeks we have developed, tested and iterated in a number of areas. Focusing on qualitative testing of rough prototypes allowed us to move faster, broadening our understanding of both the problem and the solution we’re designing.

The other approach we used was to test other products with users. When we found that some other software already had implemented a concept similar to what we were exploring, we skipped creating prototypes altogether and instead tested that product with users. This allowed us to gather valuable insights from actual users even faster.

Using this process, we have learned among other things about the kinds of information that people need the most when making a buying decision, what attitudes to expect towards contextually surfaced content and the different mental models that users had towards saving information.

We are now at the stage of combining those concepts into something that’s more of a coherent product. This is also the point in the process where we can start exploring some of the interesting interaction ideas that we have been holding back on so far, along with the ones that many of you have been proposing through our various channels.

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

The web is central to our lives — we probably spend more time in our browsers than in our beds. It has changed the way we do so many things — how we communicate, plan, shop, learn, work, and watch movies. At first, browsing, surfing, or going online was a particular activity; now, the web has melted into everyday life. It has evolved, and the web is now simply part of how we live.

Our behaviours have changed as well. We have moved significant portions of our lives into the cloud, mobile phones have become our most important touch point with technology, and social media and messaging apps have risen to ubiquity.

On desktop computers and laptops, browsers have changed their role from being one application among many to acting as a meta operating system (and in some cases, as the actual operating system). For many users, it is the only app they are ever starting on their computers, where it will then keep running for days or even weeks. They are home to everything from quick ephemeral interactions, all the way to long running full-blown applications.

Meanwhile, the fundamental interaction principles of web browsers haven’t changed in the past 20 years. On the one hand, this is remarkable proof of the quality of those UI concepts and the power of incremental improvement. But there is every reason to believe that a tool originally shaped for reading documents isn’t where you would want to start to support today’s workflows and enable new kinds of interactions with the web.

When you think of a browser today, you’re probably thinking of tabs, a location bar and perhaps a bookmarking system. But are those still the best tools for the jobs we are aiming to accomplish on the web? Maybe they are. Maybe they are not. We want to find out.

That’s why we are starting Project Tofino. It is our name for a series of experiments and explorations on what a browser could look like when its fundamental paradigms are invented in 2016 instead of 1996. It is about taking a fresh look at where people struggle on the web, but not being bound to 20 years of legacy when we look for solutions.

What is it going to look like? We don’t know yet! That’s why we see Project Tofino not as a single product, but rather as a series of experiments. We will use it as a platform to explore radical new ideas that go beyond any existing browser.

You can follow along on Medium, Slack (get access here) and Twitter.

Designing a Browser that isn’t a Browser 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.