Olivier Yiptong

The page shown to the user each time they create a new tab is called the "new tab page". The original page landed on mozilla-central on March 13, 2012.

It is an extremely valuable piece of real estate for the user: it is opened multiple times a day. For Mozilla, it is the biggest area of pixels shown to the user on a regular schedule. We have the potential to be of great utility to the user there.

However, we haven't revisited the initial assumptions since 2012, nor tried to see what is useful or not. I'm happy to say that we're now exploring ways to improve the user experience. As a first step, I'd like to explore removing some features that are barely used today.

Engagement metrics

Starting with the Directory Tiles project, we have been trying to create something useful for our users.

The premise is simple: if a user has no history, we can provide some links which we think could be useful. Hence the name "directory" (or default) tiles. We have served billions of tiles, with our own content as well as sponsored ads. We subsequently tried Suggested Tiles, a means to recommend content, including targeted ads, to our users.

(All advertising has been discontinued in Firefox worldwide as of Dec 31 2015 and is a story for another time.)

Building directory and suggested tiles has lead us to build a reporting infrastructure to get a sense of what people are doing on the newtab page. We have thus developed a privacy preserving reporting system, and started collecting anonymous data about the page.

Up until then, we did not have any significant insight as to what users do on this page. Now we do.

What we found out is that:

• Users click the most on the left-most tile and the first row, and exponentially less on subsequent rows (a fact we've known from a previous telemetry experiment, verified on a real user population)
• A small number of users block tiles
• Almost no one pins tiles (and by extension, drag'n'drop. A "pin" is recorded every time a tile is "dropped", if a pin did not occur, a drop most definitely did not occur).
• People do not want to click on ads (as compared to a history tile, or if we put the Alexa top 10 as Directory Tiles), and in fact actively block them

Here's a sample of the data we collected for the first 3 tiles, for one day:

note: This data was collected around the time both directory and suggested tiles were run. Suggested ads were shown at position 0. A bump in the block rate probably shows that people didn't want to see ads in that slot.

Great or Dead

My take on this is that we should take advantage of this data and learn from our user behaviour.

In the spirit of Great or Dead, we should consider killing features which demonstrably not useful to our users, therefore not "great". Those features also add unnecessary bloat that we have to maintain.

Blocking, our second most popular interaction type, lags behind straight clicking by a lot. However, it is still useful, because it helps the user avoid embarrassing, or annoying, situations.

Removing unused features will make space for us to try new things and create new experiences for the user.

Firefox is one of the largest open source project on the net. There are roughly 350MM users that depend on Firefox, and we have roughly 3,000 patches per release, from 400 unique monthly contributors on mozilla-central alone.

Given our reach and the maturity of our project, we have to be very careful of what we deploy to users' devices. Most developers nowadays are used to writing web applications, server and client-side.

The ergonomics of developing for the web are a departure from "desktop-software" and highly contrast with developing a browser:

• We can only periodically update the browser. Every 6 weeks for a new Firefox release, but practically 18 weeks from a patch landing in mozilla-central. Potentially much longer if factoring engineering time.
• Users expect the browser to be fast, use as little resources as possible and not break
• A browser needs to be secure, given that it allows foreign content to run on a user's computer

Given the high stakes and the high impact, we adopt fairly rigorous quality standards and processes. Unfortunately, that can also slow us down from a product development perspective and adds a long latency between conception and delivery. New ideas are extremely costly, so are mistakes.

Many of us want to go faster, to try new ideas and delight users. In fact, we could even say that we need to do so to stay relevant. I'd like to propose a new way to do Firefox engineering: to remotely-host UIs in Firefox.

Modern Web Technologies

Firefox is a web browser, and it may seem paradoxical, but we've only recently started using current web technologies for our own UIs. The web, until recently, wasn't ready for a desktop-class application. We think that has changed today. With HTML5, CSS3 and newer web APIs like ServiceWorker and more, we think we can deliver a UI experience on-par with what we make with XUL.

One of the benefits of using modern web technologies is that we can host our UIs on servers, and update them just as we would normal web pages. This opens the door to many workflows that seem routine to developers accustomed to deploying server-side applications:

• A/B or multivariate testing
• Granular, staged roll-out of features
• Quick feedback loop
• Quick deployment

Quality and Innovation

Users expect a high-quality experience using Firefox and we have many users. This is one of the reason of why our process is rigorous to begin with.

However, it doesn't make sense to have the same kind of scrutiny on presentation code than on platform code. For instance, should we choose to use a red button vs a grey button, it should not take 3 months+ to ship. This makes any product change extremely onerous. This also lowers the quality of the experience we can deliver to our users, because we take a lot of time to try out new things.

A page failing to load due to a Javascript error, for instance, won't break Firefox in a web page. However, as "browser chrome" code, that's a very real possibility.

Quickly update-able UIs can be easily isolated and errors contained. The idea is to make Firefox use regular web pages for "browser chrome", similar to another Mozilla project: browser.html.

Security

Users' expectation of the web is not what it was before. More of the browser's capabilities require external services. Accepting remote data and code has serious security implications. Pages that come to mind are about:home, which load remote Javascript, about:healthreport, about:accounts and more.

Currently in Firefox, user interfaces run code that have system privileges (a.k.a. chrome privileges). This means that the code that runs Firefox UIs can do what the Firefox application can generally do; i.e. read/write files off disk, execute code on the users' computer, etc.

On the server-side, we use server and network providers we trust, but they could get compromised and leave our users exposed.

Being a high-value target, using web technologies is a great, because it does what we're trying to prevent: access to more of what is needed.

Conclusion

We're proud to say that we're trying this new engineering strategy on the new tab page. It is a very visible piece of browser real estate and would demonstrate at scale how this method works out.