The primary goals for Firefox 4 will be making a browser:

• Fast: making Firefox super-duper fast
• Powerful: enabling new open, standard Web technologies (HTML5 and beyond!),
• Empowering: putting users in full control of their browser, data, and Web experience.

Usually software producers don’t present these sorts of plans in public until they’re finalized, but Mozilla is a little different. We work in the open, socializing our plans early and often to gather feedback and build excitement in our worldwide community. Not everyone could attend the presentation today, though, so I’m sharing the slides and video here as well.

That said: please understand that these plans are fluid and are likely to change. As with past releases, we use dates to set targets for milestones, and then we work together to track to those targets. We always judge each milestone release against our basic criteria of quality, performance, and usability, and we only ship when it’s ready.

If you have Firefox or a modern web browser that supports fully open HTML video, you can watch the presentation.

If you’d just like to thumb through the slides yourself, I’ve put them up on SlideShare:

As always we’re interested in your feedback. Use Rypple, or leave a comment here, or if you have specific thoughts about Firefox or our platform development you can join the discussion in:

• Firefox Developer’s Forum
• Mozilla Platform Developer’s Forum
• Mozilla Planning Forum

I will be presenting the product plans on Monday, May 10th at 9pm CET / 3pm ET / 12pm PT / 7am NZT on Air Mozilla. The presentation will be recorded and available for anyone to watch afterwards. During the presentation I will have people watching the #airmozilla chat room on IRC in case people wish to ask questions – please do not hesitate to ask even despite the broadcast delay; I won’t mind going backwards.

The goal of the presentation it to help everyone understand the product vision for the next version of Firefox, and what projects are underway to realize it. I hope you can make it.

Design takes time, patience and iteration. It takes sketching the same ideas out over and over again on a whiteboard, figuring out which bits work and which bits just seemed like good ideas at the time. It takes staring at other people’s ideas and jealously wishing that you’d thought of that, too, and wondering what bits you can take as inspiration without people accusing you of not being original. It takes many soul searching evenings of figuring out if being original is really the right goal.

Sharing those sketches can be hard to do, and often it’s done only in the context of the finished product. In the past when we’ve tried to share early sketches at Mozilla, the enthusiastic (yet often awfully harsh) feedback of the community ends up ending design explorations before they really get started. The result is that designers have waited until more fully fleshed out mockups and designs can be shared, but this comes at the cost of not being as transparent as we feel we should be, and not including our community in our design discussions.

So those of us working on User Experience at Mozilla are going to try something new: a virtual idea journal and sketchbook, which we’ve tentatively called “From the Bikeshed” (as you may imagine, picking a name proved tricky!) It’s a Tumblr microblog doohickey thinger that we’ll all be posting to throughout the days and weeks to come. It’s only been active for a few hours, and we’ve already started really filling it up.

The astute will quickly notice some things:

1. It’s really random. There’s really no rules to what type of content will get posted here. We’re sharing sketches, whiteboard diagrams, iterations of high fidelity mockups, half formed ideas, articles that we found interesting and relevant, even images or photographs that inspired us.
2. There is little context being offered. This is intentional. When we have more context to give, we’ll write a blog post, but for now, this is our design stream of consciousness. When we’re done with a meeting or sketching out something cool, we’ll post it right away without cleaning it up.
3. There is no place to leave comments. This is less intentional, but while we figure out how to enable comments on Tumblr, we’re also going to think about what sort of comments we want to enable. As always, people should feel free to give us feedback in the dev-usability group.
4. Some of the stuff has nothing to do with Mozilla. Yup, and that’s healthy. The best ideas often come from thinking about how to apply other solutions to your problems, so we often go around looking at other problems in order to figure out how to solve our own.

So far it’s been really freeing and enjoyable for us all to start sharing this stuff with you, and hopefully you like it, too. Thanks to Alex Limi for setting up the Tumblr and getting us rolling.

The rumours of Firefox 3.7’s demise have been greatly exaggerated. Nobody’s planning on “dumping” features or the hard work of our passionate and tireless community.

The shape of the Internet changes every day. Our mission is to develop the best open source implementations of web technologies and ship them in an excellent browser so that our users and the entire Web can benefit. That means always thinking about how we can deliver technology as efficiently and quickly as possible. Sometimes it means challenging our assumptions.

One assumption we’ve had for a long time is that the only way to ship new technology – such as improvements to downloadable web fonts or support for new standards like CSS, SVG and WebGL – was through a full Firefox version update. Until recently, our infrastructure prevented us from being able to be as agile as we would have needed to be in order to deliver something isolated like the “Lorentz” project (which aims to improve product stability and security by running plugins in their own process) to our users. Now that we have better test automation and the ability to develop on project branches, we can better isolate changes with continuous integration testing, nightly builds and the ability to deliver smaller pieces continuously through the regular maintenance cycle (“minor updates”) of a product. This means that we can, without the user being disrupted or disturbed, improve stability, security, and capability for the 25% of the Internet users who browse using Firefox. One day they’ll start up their web browser and it will be better. Maybe it will crash less, maybe it will be improve typography support on the web.

This is a powerful change, but we must also be careful to keep users in control of their software. Improving the open video engine is something we should feel comfortable doing, as it preserves (but improves!) the existing user functionality. Changing the way the browser looks or interacts with users is something we should avoid doing. I think of it this way: if I take my car in for service and it comes out with better fuel efficiency, that’s great. If my gearshift has changed location, I’d be pretty surprised and upset. We shouldn’t be doing anything in a maintenance release that could leave a user surprised and upset, period.

So instead of thinking of “Firefox 3.7″ and “Firefox 4.0″ and being rigid and proscriptive about what technology improvements will come in which specific months, I’m encouraging us all to think about what we’re trying to improve, and how those improvements can be most efficiently delivered to our users and the Internet. Improvements and support for new technology originally slated for Firefox 3.7 in a draft roadmap long ago may now find their way into users’ hands even earlier. Risky interactive changes that could benefit from multiple iterations and betas can safely do so without worrying about “missing the boat.”

Software development is chaotic, and due to the open nature of our community you (and the press) are getting to see exactly how the sausages are made. It may look like a bloody mess at the start, but once it starts to take shape it’s obvious that you’re making something delicious.

If I’m not as available as you’re used to, please accept my apologies in advance and send me an email, instead.

Oh, and if you haven’t already, do give the Firefox 3.6 Release Candidate a thorough try. Since I’ve been using this version since the alpha releases, it’s easy for me to forget how much of an improvement it is over what we were so proud to publish only 6 months ago. With built-in support for Personas, vastly improved stability and security, and new technology that improves the capabilities of the web as well as the speed with which we bring it to you, I’m pretty sure that Firefox 3.6 will be a big hit.

There’s the obvious challenge of competing with not one but three industry giants. This is the competition we wanted, the competition we created, and the competition that has benefited the Internet and all of its users. It’s what we set out to do as a community. The new challenge I see is ensuring that we don’t let the open web technology stack become turned into a commodity. The competition in the next 2 years will be about how the technology used to create exciting, rich, interactive experiences online is developed.

At the same time, Jay Sullivan, Chris Beard, Mike Shaver, myself, and many other people have been working on expressing a structure for understanding how to build a strong direction that can be used to draw a roadmap for the future of Mozilla products. The two topics are obviously related: in order to move as quickly and efficiently, we need to know where we’re going.

I’ve embedded (and linked to) my presentation below; I put it on SlideShare.net* yesterday and the editors there bumped it to the front page, which is exciting to me as it means that the messages we’re putting forward are resonating with people.

I expect that the roadmap will evolve over time, and will be working with many people in the Mozilla project to add more detail in the coming weeks and months.

(* yes, I realize that there’s an irony to these slides being shared through a Flash-based viewer; I put the slides together using Apple Keynote, and the export to HTML version really doesn’t work so well.)

(edited: Saturday, October 10th for clarity)

Week of August 10th:

• started into the triage of bugs nominated to block Firefox 3.6
• worked with the release engineering and development teams to co-ordinate the branching of mozilla-1.9.2 from mozilla-central, and updated the checkin rules for those trees
• gathered more input on the product roadmap from various stakeholders, and a kick in the butt about actually publishing instead of gathering
• worked with Chris Blizzard and others on a project to help users update their plugins
• started talking with John Slater on how we can provide better upgrade and first run experiences to Firefox users

Loose threads:

• file bugs for the upgrade and first run experiences and discuss with Rob Strong (updater) and Mike Morgan (AUS)
• file bugs for the plugin update experience and discuss with Rob Strong (updater) and Mike Morgan (AUS)

Next targets:

• publish draft of Firefox product roadmap before August 21st
• get the nomination list for bugs blocking Firefox 3.6 to 0 before August 21st

I also wanted to mention that the Mozilla Corporation employees who are members of the Firefox development team will be getting together at the new offices in Mountain View, California to collaborate face to face for a week. We’ll do our best to make sure that the meetings and discussions are being broadcast in ways that let you join in, but as always, you can find our backchatter on IRC in #fx-team.

• Progress: the major goings-on within a project area for the past week; “not much” is a perfectly acceptable update here, and quite a valuable one as it helps us understand when projects are getting stuck or slowed down.
• Loose threads: patches can linger in review queues, projects can get stuck waiting on feedback, documentation can go unwritten, but all of those things should be listed as loose threads so that we can make sure we tie them up.
• Next target: this should list the next set of objectives (patches, designs, decisions) and an estimate of when they are to be completed.
• Next steps: a recommendation of whether work on the project should continue, or be shelved for now, or be killed outright, as well as any insights into future directions.

You can keep tabs on an overview of all the projects that the team is engaged on, and of course, come and chat with us about the projects and how to get involved.

I’ll likely give slightly different reports, focusing on an overview of the major Firefox product management happenings over the past week. For instance, this week would probably look something like this:

• Firefox 3.0.13 and Firefox 3.5.2 were shipped to users on Monday.
• At Tuesday’s Developer’s Meeting we discussed the upcoming Firefox 3.6 Alpha 1 release, as well as when infallable malloc should land in the tree and whether or not we should ship a subset of the jQuery libraries with the Mozilla platform.
• At Wednesday’s Delivery Meeting we talked about how the mozilla-1.9.2 branch would likely be cut early next week, and how we could help users running older, insecure versions of Adobe Flash update themselves to the latest version.
• I gathered some more input on the product roadmap, a deliverable that I am extremely behind in delivering
• A post-mortem was held on the Firefox 3.5.2 and 3.0.13 release
• Firefox 3.6 Alpha 1 is set to be released late Friday afternoon

I’m not as sure if my overviews will be as interesting, so please feel free to leave a comment if there’s more or less of a certain type of information you’d like to see from me in particular.