Firefox Roadmap

I posted an update to the Firefox Roadmap.

Firefox will deliver a rock solid browsing experience with world-beating customization and a first of its kind recommendation engine that gets you the content you want when you want it, whether at home or on the go.

Context Graph

In the lead-up to the London all hands we had a Town Hall where Mark Mayo and Nick Nguyen previewed the three year strategy for Firefox.  That talk mostly covered an emerging area of focus and investment we’re calling the Context Graph.

This last week, Nick posted a vision for the Context Graph over at Medium. If you haven’t, I encourage you to go read it at medium.com/@osunick

So what is the Context Graph. The context graph is an understanding of how pages on the web are connected to each other and to a user’s current context. With Context Graph, we’re going to build a recommendation engine for the Web and features that help people discover relevant content outside of the popular search and social silos.

What does that look like in practice? Well, if you’re learning about how to do something new, like bike repair, our recommender features should help you learn bike repair based on others who have already taken the same journey on the Web. If you’re on YouTube watching a music video, Firefox should help you find the top lyrics or commentary sites that embed or link to that YouTube video. Or, if you’re walking into a WalMart, our mobile apps should automatically show you WalMart’s website or perhaps a WalMart deals and coupons site.

Building a recommendation engine for thew Web is a large project that will take time and effort but we believe the payoff for users and the health of the Open Web is going to be well worth it.

To dig deeper, I highly recommend Nick’s post at medium.com/@osunick and check out the wiki page at wiki.mozilla.org/Context_Graph.

Firefox 48 Beta, Release, and E10S

Tomorrow In the next few days, Firefox 48 Beta becomes available. If all goes well in our beta testing, we’re about 6 weeks away from shipping the first phase of E10S to Firefox release users with the launch of Firefox 48 on August 2nd.

E10S is short for “Electrolysis”. Similar to how chemists can use the technique called electrolysis to split water into hydrogen and oxygen, we’re using project Electrolysis to split Firefox into a UI process and a content process. Splitting UI from content means that when a web page is devouring your computer’s processor,  your tabs and buttons and menus won’t lock up too.

E10S has been enabled for some portion of our Beta audience since December of 2015 and we’ve had it enabled for half of our Beta population for the last 6 weeks. The team has been comparing the half with E10S to the half without for things like stability, responsiveness, memory usage, and more. And so far, so good. We’ve met all of our release criteria and assuming nothing shows up in Beta 48, we should be good to go.

(When we hit release in about six weeks, not all of our Firefox 48 users will get E10S. The teams have been working really hard but we’ve still got some compatibility and other work to do to make E10S ready for everyone. The groups that will have to wait a bit for E10S account for about half of our release users and include Windows XP users, users with screen readers, RTL users, and the largest group, extension users.)

This is a huge change for Firefox, the largest we’ve ever shipped. But don’t worry. The Electrolysis team at Mozilla has a release roll-out plan that ensures we’re going slowly, measuring as we go and that we can throttle up as well as down depending on what we see.

Here’s what that looks like. When we launch Firefox 48, approximately 1% of eligible Firefox users will get updated to E10S immediately. The 1% of release users should get us up to a population similar to what we have in Beta so we’ll be able compare the two. About ten days after launch, we’ll get another round of feedback and analysis related to the release users with and without E10S. Assuming all is well, we’ll turn the knobs so that the rest of the eligible Firefox users get updated to E10S over the following weeks. If we run into issues, we can slow the roll-out, pause it, or even disable E10S for those who got it. We have all the knobs.

As noted earlier, this is just the first phase. Next up we’ll be working to get E10S to the cohorts not eligible in Firefox 48. We want 100% of our release users to benefit from this massive improvement. After that, we’ll be working on support for multiple content processes. With that foundation in place, the next projects are sandboxing for security, and isolating extensions into their own processes.

It’s an exciting time at Mozilla. E10S is the largest change we’ve ever made to Firefox and we hope you’ll help us get through this with as few surprises as possible. To help out, get on Beta and let us know what you find.

update: There is some confusion about what’s new here. I think I can clear that up. E10S has been in beta for some time. That’s not new. It was there for half of our beta users for the entire previous 6-weeks cycle. What’s new here is that we’ve just recently met all of our release criteria and we think we can take the feature from beta to release in the next 6 weeks. Now we’re down to one final cycle — assuming we don’t encounter any surprises. That’s where you all come in. Please help us test this upcoming Firefox 48 beta well so we have confidence when we get to the end of the beta cycle that E10S works well for everyone that gets it. Thanks.

thoughts on web performance and ad blockers

I often use an ad blocker with my web browser. I do this not because I hate seeing ads. I block ads because I can’t take the performance hit.

Running an ad blocker, or using Firefox’s tracking protection, makes the web responsive again and a pleasure to use. Sites load fast, navigation is smooth, everything is just better in terms of performance when the ads and their scripts are removed from the web.

I don’t like the idea, though, that I’m depriving lots of great independent sites (some of them run by friends) of their ad revenue. Unfortunately, Ads have grown worse and worse over the last decade. They are now just too much load, physically and cognitively and the current state is unsustainable. Users are going to move to ad blockers if web sites and the big ad networks don’t clean up their act.

Sure, everyone moving to ad blockers would make the web feel speedy again, but it would probably mean we all lose a lot of great ad-supported content on the Web and that’s not a great outcome. One of the wonderful things about the web is the long-tail of independent content it makes available to the world — mostly supported by ads.

I think we can find a middle ground that sees ad-tech pull back to something that still generates reasonable returns but doesn’t destroy the experience of the web. I think we can reverse the flow of people off of the web into content silos and apps. But I don’t see that happening without some browser intervention. (Remember when browsers, Firefox leading the pack, decided pop-ups were a step too far? That’s the kind of intervention I’m thinking of.)

I’ve been thinking about what that could look like and how it could be deployed so it’s a win for publishers and users and so that the small and independent publishers especially don’t get crushed in the escalating battle between users and advertising networks.

Web publishers and readers both want sites to be blazing fast and easy to use. The two are very well aligned here. There’s less alignment around tracking and attention grabbing, but there’s agreement from both publishers and readers, I’m sure, that slow sites suck for everyone

So, with this alignment on a key part of the larger advertising mess, let’s build a feedback loop that makes the web fast again. Browsers can analyze page load speed and perhaps bandwidth usage, figure out what part of that comes from the ads, and when it crosses a certain threshold warn the user with a dialog something like “Ads appear to be slowing this site. Would you like to block ads for a week?”

If deployed at enough scale, sites would quickly see a drop-off in ad revenue if their ads started slowing the site down too much. But unlike current ad-blockers, sites would have the opportunity and the incentive to fix the problem and get the users back after a short period of time.

This also makes the ad networks clearly responsible for the pain they’re bringing and gets publishers and readers both on the same side of the debate. It should, in theory, push ad networks to lean down and *still* provide good returns and that’s the kind of competition we need to foster.

What do you all think? Could something like this work to make the web fast again?

 

My New Role @ Mozilla

After a couple of years working on Mozilla’s mobile operating system project, I’m coming back to Firefox!

I’ll be doing some familiar things and some new things. My official title is Product Manager, Firefox Roadmap and Community. What that means, first and foremost, is that I’ll be returning as our storyteller, making sure that we’re communicating regularly about where Firefox is heading, and that we’re fully engaged with Firefox users, fans, and contributors.

My first few weeks will be spent getting up to speed with the Firefox teams, from Product  Management and User Experience to Engineering and Program/Project Management. We’re doing a lot with Firefox in 2016 and 2017. I can’t wait to start sharing that story.

If you’ve got ideas about what needs improving first with Firefox communications, perhaps the Monday all-hands meeting content, or the roadmap documents on the wiki, or something completely different, please let me know in comments or email.

I’m over the moon excited about this role. Stay tuned. It’s gonna be great.

Foxtrot Update Jan 2015

Hey folks. Welcome to 2015!

About half of the people participating in the Foxtrot program have still not received Flame phones. I’m sorry about that. I’m hard at work on this but it depends on getting the right builds on the phones. We aren’t going to send our Foxtrot testers new phones with builds that brick the device randomly and we don’t yet have the process set up to deliver only functional updates.

We have delivered a couple thousand Flames to our very brave “unstable nightly” testers and developers, and thousands of others have purchased Flames to develop against, but we’re still behind on getting our “stable nightly” Foxtrot builds and update channel ready. As soon as that’s are ready, we’ll flash the remaining 100 or so Foxtrot phones and send them out to contributors.

I don’t have an ETA, but it’s a high priority.

(If you have not received an email update on Foxtrot, check your spam filter. All Foxtrot participants were automatically signed up for a mailing list for just this kind of update and information. Unfortunately, it appears that some people have removed themselves from the mailing list and others are not seeing the mails because they are ending up in a spam filter. If you removed yourself from the list, I dropped your entry from the Foxtrot program with the assumption that you were no longer interested. If you remember removing yourself from the mailing list but didn’t want to be removed from the program, you can email me and I’ll get you added back. The list is not optional though. It’s how we’ll contact you for program feedback.)

Also, it is very likely that we’ll be expanding the program to several hundred more people over the coming weeks. Stay tuned here for updates on how you can join.

Flame Distribution Update

About three weeks ago, I ran out of Flame inventory for Mozilla employees and key volunteer contributors. The new order of Flames is arriving in Mountain View late today (Friday) and I’ll be working some over the weekend, but mostly Monday to deliver on the various orders you all have placed with me through email and other arrangements.

If you contacted me for a Flame or a batch of Flames, expect an email update in the next few days with information about shipping or pick-up locations and times. Thanks for your patience these last few weeks. We should not face any more Flame shortages like this going forward.

Ten Years Ago

Ten years ago, tonight, this is what I was working on.

Join us in celebrating the launch of Mozilla Firefox 1.0. Tomorrow, Tuesday, November 9, from 2-7pm PST (that’s 22:00-03:00 GMT), we will be hosting AIR MOZILLA live from the Mozilla Foundation HQ, a 5 hour web event, including a live webcast and text chat. The show will feature interviews and discussions with key Mozilla staff. Questions from the audience (including the media) from the chat room will be fed into the show. The event will be hosted here at http://www.spreadfirefox.com. You’ll need QuickTime for the audio streaming. We’ll also use both IRC and a web-based text chat solution.

When:
2-7pm PST, 22:00-03:00 GMT. That’s 22:00-03:00 on Tuesday night in Germany. In Japan, that’s 07:00-12:00 Wednesday morning.

Where:
Here at http://www.spreadfirefox.com. If Spread Firefox gets overwhelmed by the high traffic, head on over to http://www.mozilla.org/airmozilla.

What:
Live webcast + text chat with key Mozilla people.

Yep, not only is it the 10 year anniversary of Firefox, it’s also 10 years since the inaugural Air Mozilla “broadcast”.

We’ve come a long way. So much more still to do :D

Foxtrot Update 2014-11-05

Hello Foxtrotters!

Our order of Flame devices is expected to arrive in the next week to ten days. In parallel, our integration partner is working on the Foxtrot builds of Firefox OS and the update system that will give y’all monthly development snapshots.

Once the devices order arrives in Mountain View, and I’ve got the Firefox OS Foxtrot image from our partner, I’ll spend a day flashing the image onto the devices, packaging them up and sending them out. It’s my intention to see the devices arrive, flashed and ready to receive the first official Foxtrot testing build over the air by the end this month.

MozFest Flame Phones

Dancing Flames
Image via Flickr user Capture Queen, and used under a CC license

Even though I wasn’t there, it sure was thrilling to see all the activity around the Flame phones at MozFest.

So, you’ve got a Flame and you’re wondering how you can use this new hardware to help Mozilla make Firefox OS awesome?! Well, here’s what we’d love from you.

First, check your Flame to see what build of Firefox OS it’s running. If you have not flashed it, it’s probably on Firefox OS 1.3 and you’ll need to upgrade it to something contemporary first. If you’re using anything older than the v188 base image, you definitely need to upgrade. To upgrade, visit the Flame page on MDN and follow the instructions to flash a new vendor-provided base image and then flash the latest nightly from Mozilla on top of that.

Once you’re on the latest nightly of Firefox OS, you’re ready to start using the Flame and filing bugs on things that don’t work. You’d think that with about five thousand Flames out there, we’d have reports on everything that’s not working but that’s not the case. Even if the bug seems highly visible, please report it. We’d rather have a couple of duplicate reports than no report at all. If you’re experienced with Bugzilla, please search first *and* help us triage incoming reports so the devs can focus on fixing rather than duping bugs.

In addition to this use-based ad hoc testing, you can participate in the One and Done program or work directly with the Firefox OS QA team on more structured testing.

But that’s not all! Because Firefox OS is built on Web technologies, you don’t have to be a hardcore programmer to fix many of the bugs in the OS or the default system apps like Dialer, Email, and Camera. If you’ve got Web dev skills, please help us squash bugs. A great place to start is the list of bugs with developers assigned to mentor you through the process.

It’s a non-trivial investment that the Mozilla Foundation has made in giving away these Flame reference phones and I’m here to work with you all to help make that effort pay off in terms of bugs reported and fixed. Please let me know if you run into problems or could use my help. Enjoy your Flames!