It's been a year since Panorama was just an idea, and now it's shipping in Firefox 4! What have we learned in the process? What did we do well? What could we have done better?

Notes

• There was a coherent team that was focused solely on getting this feature in and making it shine.
• While the vision and initial push came from inside (Aza), the development team was largely new to Mozilla. Even Aza was originally from Labs, not mainstream Firefox.
• The feature went from prototype to shipping without a re-write; we just iterated and refactored as needed.
• The UI is largely HTML rather than XUL. We also wrote and used a Firefox-specific lite version of jQuery, called iQ.
• Integrating the feature with all of the many aspects of the browser (including new major features that were landing at the same time, such as app tabs) took the majority of the time (over creating and evolving the feature itself).

Good

• As a dedicated team, we were focused enough to surmount the obstacles we encountered.
• As outsiders, we brought fresh perspective.
• Building a working prototype first made a huge difference in terms of convincing people the feature was worthwhile.
• Starting it as an add-on meant it was easy for people to try out in the early days.
• Evolving the feature for several months before integrating allowed us to iterate rapidly on the UI.
• We didn't write unit tests during our initial feature evolution (which would have slowed us down at the time and locked us into certain paths before they were baked from a UX standpoint), but we were dedicated about landing unit tests with every patch during the refinement and integration stage. This seems like a good balance, and we've ended up with excellent coverage.
• We had a number of "friends of Panorama" inside Mozilla whom we could turn to; they really made it possible.
• Having our dedicated chat channel (#tabcandy) was a great way not only for the team to keep in touch, but also for the "friends of Panorama" to make themselves available.
• We had a weekly "scrum" email thread that helped keep us all up to date (since the entire team was geographically distributed).
• We collected knowledge relevant to the team in our wiki, and used it to get new people up to speed quickly: https://wiki.mozilla.org/Firefox/Projects/TabCandy/Work
• Aza's external evangelism (including blog posts and tweets) brought energy and at least one developer to the project. He also created a centralized dashboard early on.
• Reviews could finally keep up with patches once Ian became an official reviewer. Another thing that helped with reviews was the reviewer dashboard that allowed us to see where things were piling up.
• People have commented that the code is clean, well structured, and easy to get up to speed on. Part of this is the way it's written like a web app, and the use of iQ.
• We were consistent about documenting all of our functions. We also had a series of web pages that brought that documentation together.
• Our use of meta tracking bugs for milestones allowed us to keep focused.
• The team was generally on top of bugzilla, keeping up with all the conversations. Having a Panorama-specific component in Bugzilla allowed the team to see all the traffic for our feature without getting swamped with the Bugzilla firehose.

Needs Improvement

• As outsiders, we encountered a steep learning curve, and made a number of naive decisions that had to be reversed later.
• We weren't involved in mainstream Mozilla enough (we didn't attend the Firefox team meetings, weren't following the mozilla.dev.planning mailing list, etc). This meant we were often surprised by new developments, and also meant we weren't visible to the rest of Mozilla.
• If it was clear that this was a stated goal of fx4, a little earlier, within the firefox team, ux, and to dev/community communications, it would have been easier to get people on board and help.
• We spent a lot of time trying to figure out who to ask for things.
• We often had to pull our "friends of Panorama" away from their "day job" to help us out.
• We should have had better communication earlier of what we wanted to do with the platform folks so that they can suggest/optimize the performance of many things on the platform side.
• We were often review-bound; we had a lot of work to do and we wrote patches faster than they could get reviewed. We'd also sometimes end up with a whole lot of reviewed patches waiting for approval. Either way, we had to deal with a lot of bitrot.
• It was unclear early on what exactly the hurdles would be in getting this in the product (reviews, unit tests, code style, talos, etc).
• We didn't start writing unit tests until we got serious about landing, so we had a lot of catch-up to do there.
• By developing for a number of months before integrating, we had a huge hurdle to initially land because of the size of our code base. For one thing, it would have been good to get reviewers involved earlier.
• Another source of stress was the "all or nothing" quality of the landing requirements. We couldn't land at all until we had satisfied them. Perhaps a better approach would be to allow landing a major feature like this pref-ed off even without meeting all of the requirements, with the understanding that it can't actually ship pref-ed on until it does meet them.
• Since Panorama is largely self-contained (both the code and the team), we often punted on deeper integration with the browser. For instance, the notion of "tab groups" should really have been a real xul/js construct in the tabbrowser level. Also, starting it as an add-on meant it already had a lot of momentum towards over-compartmentalization when we did integrate it.
• When Panorama first landed, and for a few months after, it had the nasty habit of getting triggered accidentally and hosing your tabs in various interesting ways. This is another reasion we should have landed pref-ed off at first and flipped the default switch once things were more stable. Once it was proven to be solid, the kill switch should be removed entirely (to avoid the browser becoming a morass of possible permutations).
• Key combos (and gestures), in particular the Panorama activation command, were and endless source of argument amongst the community.
• We could have done more (blogging, for instance) to keep interested parties outside of the core team up to date on where we were. Perhaps our scrum threads could have been public as well?
• We could have used better documentation for the overall architecture (as opposed to the invididual functions).
• The code is different from mainstream Mozilla; a number of folks find this off-putting.
• We never formalized an API, and the feature still isn't documented on MDC.
• The design kept evolving, which on its own is fine, but we didn't keep a spec up to date, which caused confusion.
• Although various folks pitched in on the planning side, having a dedicated Project Manager would have made a big difference.
• Panorama exercised the browser code in ways it wasn't used to, and a few times we uncovered flaws that hadn't been found before. That's probably good, but it usually took us a while to realize that it wasn't just something we were doing wrong in the Panorama code.

Further Thoughts

• Having at least one insider 100% dedicated to the project would have made a big difference.
• In any established product, there's inertia against large innovative features. For version one of such a feature, you need a dedicated strike team in order to get over that inertia. For version two, however, the feature and team needs to dissolve back into the product as a whole.
• It would be great if this process of introducing major innovations was more understood and had better support throughout the system. At the very least, there should be a "so you want to start a feature strike-team?" FAQ.

Original Discussion

The thoughts above have been distilled from the original chat meeting we had on the subject; you can read the transcript if you'd like.