MozillaWiki

Firefox/Projects/Tabcandy/Panorama 1 Debrief: Difference between revisions

Page Discussion

Firefox/Projects/Tabcandy/Panorama 1 Debrief (view source)

Revision as of 17:40, 29 April 2011

258 bytes removed ,  29 April 2011
no edit summary
No edit summary
No edit summary
 
Line 16: Line 16:
* Starting it as an add-on meant it was easy for people to try out in the early days.  
* 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.  
* Evolving the feature for several months before integrating allowed us to iterate rapidly on the UI.  
* Our original feature had very few unit tests (just enough to allow us to land), but thereafter we were quite dedicated about landing unit tests with every new bug fix. At this point we have quite good coverage, but it grew organically out of the process of refining the code. This seems like a good balance; when you first create a feature, it's hard to know what's going to break and you could easily go out of control writing intricate tests for every possibility. The problem is, you're still evolving it, and a thicket of user tests at that stage will only slow down the evolution. Once you've had a chance to work with the feature for a while, however, and you're down to fixing bugs, including unit tests as a way to increase your coverage and fend off regressions is definitely worthwhile.
* 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.
* 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.
* 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.
Line 42: Line 42:
* 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.
* 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.
* 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. We should have landed preffed off at first and flipped the default switch once things were more stable.
* 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.  
* 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 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?
Iangilman
68

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/304321"