While this means that I won’t have as much time for Mozilla projects or Firefox as I used to, I do very much hope to be an active and positive contributor in the Mozilla Community. I’ve got my eyes on a few bugs and expect to comment there, as well as in the planning newsgroups. I’m pretty eager to see what this experience is like without the mozilla.com email address, and already have plans to work with Asa and Mary to do what I can to make it even easier.

Leaving Mozilla is one of the hardest things I’ve ever done, career-wise. Over the past six years I’ve had the distinct pleasure and privilege to work with the most amazing people, all of whom were more than just colleagues … they were trusted friends. The more I thought about saying “goodbye,” though, the less appropriate it seemed. Really what I’m saying is “see you less often.”

So, team: let’s get to work on Firefox 5, 6 and 7, eh wot?

Almost six years ago, when I left IBM Canada for Mozilla, my manager assured me I’d be back at Big Blue in a couple of years. “It’s just a web browser,” he said, “how much work can there be?”

A lot, it turns out. I knew very little about the technology used to drive the Web, about open source communities, about how to ship software, or how to not cause the trees to go orange by revving an entity name when changing a string.

I have had the great privilege to work with this community of employees, contributors, volunteers and enthusiasts in order to ship six “upgrades to the Web” from Firefox 1.5 through to the soon to be released Firefox 4. I am indebted to so many people at Mozilla for what they have had the generousity to teach me, for giving me the trust and opportunity to learn, and for some incredible memories, friendships and experiences.

There comes a time, however, when one needs to “just keep movin’ on.” I’ve been getting antsy for the past few months, as some people may have noticed, and have decided that it’s time to challenge myself by jumping into an industry about which I know next to nothing. Some things will be familiar, of course (I’ll be managing product strategy for a small team of incredibly smart people, developing advanced, disruptive technology in a stagnant market with a dominant market leader) but almost everything else will be different, and I’m looking forward to the opportunity to learn and grow. I expect that you’ll see me trying to see how I can apply some of the tools I’ve developed here to that industry, too.

It’s not a choice I made lightly, I can assure you. I’m incredibly eager to see how Mozilla continues to evolve, shifting its strategy to the new world in which the Web is not just alive and thriving, but evolving and transforming daily. Changing to delivering those Web upgrades by shipping smaller pieces more quickly, providing a new stable of Firefox-ish services – it’s clear that Mozilla’s future is filled with exciting new challenges and opportunities. Add to that the dear friendships I have with so many people in this community, and the simply incredible global work environment we’ve created together … you may assume that the decision took time, consideration, and involved more than a few tears.

It would be the most absurd hubris for me to believe for one second that Mozilla couldn’t face those challenges and opportunities without me. My role here has mostly been that of a lens, focusing the efforts of others in order to burn away obstacles. I am constantly in awe of the energy, passion and quality of skill held by everyone involved in this project.

Brian King recently wrote about a very significant change to the Firefox user interface which will be seen by all Windows Vista and Windows 7 users when they upgrade to Firefox 4. Designed by Alex Faaborg and the UX team based on community feedback from Test Pilot data, this new “Firefox Menu” will replace the Menu Bar. The goal is to put the most frequently used controls in a single menu, and return vertical space to the web content area by removing the pixels otherwise taken up by the Menu Bar:

(Image courtesy Brian King)

Alex filed a bug with the design, which included several new UI concepts that had not been previously implemented using XUL, such as a two-tiered Windows Vista-esque menu, and a menu that had buttons in it. At the time the bug was filed, we weren’t sure who would have time to experiment and implement the changes, and considered some of the design items to be at risk for Firefox 4.

This is where the soapy ham hocks come into the story.

Joshua M (who also goes by SoapyHamHocks on IRC) created a Bugzilla account on August 12th, and put up his first attempt at an implementation the next day. Working with the Firefox team in IRC and through Bugzilla, several iterations of his patch went by, and on August 20th, the patch landed in Mozilla’s codebase. There are some bugs and issues to work out, but thanks to Joshua’s contribution, our Windows Vista/7 users will all be able to look forward to a much more native, and better user experience – and of course, if Windows XP users want to try it out, they can customize their UI to do so! It should appear in a future beta revision, and of course users will be able to give us feedback about it at that time.

I’m always thrilled to see new contributors who want to make a difference for millions of users finding their way into our community, and similarly thrilled when our community can guide and help these new contributors towards successful implementations. Welcome to our motley crew, SoapyHamHocks – we all appreciate your work and effort.

We’ve actually gotten so much great feedback from users that we’ve had to create new tools to help us interpret it all. These tools allow us to navigate the 3-4 thousand feedback submissions we’re getting every day, calling out clusters of similar comments and allowing us to gather lists of websites that are reported to have compatibility problems. It’s also nice to see what changes are resonating positively with users on a week-by-week basis!

Over the next two planned beta releases we expect to add more web-developer and user-facing features to Firefox 4, at which point we’ll hit what we call “feature freeze.” After that point, we will spend all of our time fixing bugs and polishing the release for our hundreds of millions of users. It’s during this time that many of the bugs created from feedback reports will be addressed. So keep on letting us know what you like about the new betas, and what isn’t working well for you, and we’ll keep on working with you to make sure that Firefox 4 is moar awesome.

I wanted to do what I could to help our engineers understand what caused the problem, and my colleague Jeff Muizelaar showed me what to do. I figured that I’d share that knowledge with you, gentle reader, in case you were also interested in doing what you could to help the Mozilla project with the development of the Firefox browser.

Requirements:

• a Mac running OS X (I’ll write another post later on how to do this on Windows, too)
  
• a nightly Mac build of Firefox (don’t worry – they’re stable; I use it as my day-to-day browser)
• XCode installed on your computer (this is also included on your OS X DVD)

When Firefox “beachballs”:

When you see a colourful spinning disc (also known as a “beachball”) instead of a mouse cursor while hovering over a Firefox window, you’re experiencing a hang. If this lasts a long time, you’ll want to file a bug so that our engineers can investigate the source of the problem. To help them do this, you can collect two sources of information:

• a profile
• a stack trace

Profiling Firefox with Shark:

In the “Developer” folder installed by XCode there’s a folder called “Applications”, and inside that there’s a folder called “Performance Tools” and inside that there’s a program called “Shark.app”. You should also be able to find it with Spotlight.

• Launch Shark.app
• Select “Time Profile”, “Process”, “firefox-bin” and set the time limit to 30s
  
• Press Start
• Stop it anytime after 10 seconds if you’re not patient enough to wait the full 30s

Once it’s done collecting samples, Shark will analyse them and produce a chart indicating where Firefox was spending it’s time. Congratulations! That’s the first piece of information which will help the engineering team.

Getting a stack trace with gdb:

The next thing you can collect is a stack trace. Here’s how:

• Open a terminal window and type “ps aux | grep firefox-bin | grep -v grep” – this returns a list of running processes that match the name “firefox-bin”
• Make a note of the process number – it’s the first number in the line of text, usually three or four digits – let’s pretend it was 6115 like in the screenshot below.
• Type “gdb” to launch the debugger that was installed with XCode
• Type “attach 6115″ where “6115″ is the process number you got from step 1
  
• Wait a few seconds for the debugger to attach to your Firefox process
• Type “bt”
• Type “detach” to detach from the Firefox process
• Type “quit” to quit the debugger

Congratulations! Now you have a window with a stack trace! You can now force-quit Firefox and restart it, since you’ll need it to file the bug.

Now you’re ready to file a bug:

Bugzilla isn’t a very friendly tool at times, but it’s powerful and what we use. Don’t worry if your bug is a duplicate, people check for those and duplicate bugs end up being very helpful, so please don’t hesitate to file them. When dealing with a hang, it’s probably best to file the bug in the Firefox::General component and start the summary with the word “hang”. Try to write a summary that represents what you were doing when Firefox hung, like “hang when I plug in an external monitor” or “hang when I click on a link from Tweetie”.

1. Go to bugzilla.mozilla.org and log in (you may need to create an account)
2. Click on File a Bug
3. Select Firefox as the product and General as the component unless you suspect it’s associated with something in particular based on the Shark analysis or stack trace
4. Write a summary that starts with the word “hang” and expresses what you were doing when Firefox hung
5. Type a few sentences at the top of the report that describes what you were doing, and what version of Firefox you’re using (you can copy the “build identifier” from the page that appears when you type “about:” into the location bar and hit enter)
6. Expand all the twisties in the Shark analysis window, select all the rows, then copy them and paste them into the bug report
7. Scroll back the Terminal window and copy the stack trace into the bug report
8. Submit the bug report

I filed a bug on the hang I was experiencing using these steps, and that information may save our users from experiencing the same hang in the future. This is an important part of the open source process, and using these steps, hopefully you’ll also be able to take part in the development of Firefox.

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.