Between these last few responses and browsing the FireBug Working Group's info, I think I have a fair grasp of both what FireBug's current activation model is actually doing and what I'd like to see it do. First, some specific responses:
Re: Exposing the working group to users I think this is somewhat of a balancing act. You don't want the working group bogged down by too many user issues, however you do need significant user interactions to ensure their needs are met. I think it's clear the new activation model for 1.4/1.5 didn't get enough discussion before a "release". It sounds like you agree and 1.5 will get a little more user interaction :D. Re: 1.4 beta used as a release for FireFox 3.5 I don't know the API differences between FireFox 3.0 and FireFox 3.5, but one key reason 1.4's activation model is such a big issue is because the only FireBug version supported with FireFox 3.5 is 1.4 *beta*. Thus users that upgraded to FireFox 3.5 are now using 1.4 beta as if it was a full release. IMHO, if the 1.4 beta was allowed to complete as a voluntary beta, the kinks could have been fully worked out and properly documented which would have greatly decreased the pain of this change. Re: Active List Looking at the "A Simpler Model" section of http://groups.google.com/group/firebug-working-group/web/firebug-user-scenarios, I now fully understand how 1.4 tracks the active list. IMHO, having this kind of documentation for a 1.4 full release would be _very_ helpful to users. One potentially annoying feature of the new model is that all windows/ tabs of an activated domain will start on/activated. While this feature can be useful for sites that require multiple tabs/windows, the "Activate Same Origin URLs" that controls this feature needs to default to Disabled, should be renamed to refer to domains instead of URLs (since it is domain based, not URL based anymore), and requires specific highlighting in the aforementioned release documentation. IMHO having this Enabled by default is a *big* part of why people are confused/annoyed with the new model. With "Activate Same Origin URLs" off, the main user difference (I'm sure there are significant implementation differences) between the current model and the tab-oriented method is that the Enabled/Disabled status of each tab is the same for all windows/tabs of each domain. Since new windows/tabs start with FireBug Off, however, this has no impact unless you manually turn FireBug On. Of course, my original request is still valid: FireBug is tracking a series of domains in the Active List and it is taking actions based on that list. IMHO, FireBug should provide a little pop-up that allows me to view the Active List and delete one or all entries. Adding entries is via the pop-up is unnecessary since visiting the page and turning FireBug On does that. In the short term, this could be done easily enough by adding the Active List to the icon's right-click menu -- selecting a site would delete it from the active list. This is simple to implement yet does enough to ensure FireBug isn't "hiding" anything from its users. Note: IMHO, FireBug 1.4 doesn't need a complex site manager, Whitelist, or Blacklist. While I can see some use cases for these, 1.4 certainly should not include them. Simply allowing me some way to view/ prune the active list would suffice for 1.4 and perhaps 1.5. Some misc replies: > If you switch to GMail in the middle of a 1.4 debug session Firebug > will suspend unless you have activated Firebug on GMail. This was true > in 1.3 and continues to be true in 1.4. This is not true if you have "Activate Same Origin URLs" enabled. If I turn FireBug On for this very page and then open GMail in a new tab while "Activate Same Origin URLs" is enabled, GMail cripples FireFox while it loads with FireBug On. Again, this is why "Activate Same Origin URLs" should start defaulted to disabled and you need to clearly document "Activate Same Origin URLs"'s behavior. > Based on our overall experience with 1.4, I plan to make one important > change: we need to shorten the release cycle. 1.4 had a lot of UI > changes and that caused users to be unable to react to individual > changes, defeating our efforts to learn from their experience. I don't know how long your dev cycle for 1.4 is/was, but IMHO the complaints don't derive from the number of changes in one release. Rather, the fact that users were forced to upgrade to a beta that has little-to-no documentation on those UI changes combined with a default setting that can easily cripple FireFox is what caused a lot of the pain. I'm all for 3-6 month dev cycles, but please don't overlook the root causes or this will occur next time. Cheers, -Foam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
