On Jul 15, 2:23 pm, FoamHead <[email protected]> wrote:
> 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.
While I would be happy to agree, as a practical matter users come here
when they choose to do so, usually right after we release something
they don't like ;-)
>
> 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.
As you probably know from reading the working group, I was against the
AMO distribution of 1.4 but there was nothing I could do about it.
What we don't know however is what would have happened in the absence
of that distribution. Would we have gotten the kind of feedback we
needed? Would users of Firebug who upgraded to FF 3.5 be ok with going
to getfirebug.com? Would Mozilla pull support for Firebug project? We
will never know.
>
> Re: Active List
> Looking at the "A Simpler Model" section
> ofhttp://groups.google.com/group/firebug-working-group/web/firebug-user...,
> 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.
Well what does that mean? The web page you point to exists. I've
written a bunch of blog posts. I've replied to a billion newsgroup
posts. What else?
>
> 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.
Based on other discussions in this group, I think the default is best
this way.
>
> 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.
Another issue in windows vs tabs: sites and users can cause links to
open in the same or new tabs.
>
> 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.
I agree that an output of the activation URLs would be nice. Removing
annotations would be easy.
>
> 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.
Yes, this is just another example of how activation issues are more
complex than they seem.
>
> > 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.
I have no control over that particular cause. I can cause a shorter
dev cycle. Plus I don't completely agree with you analysis. By
pushing out one change at a time we help users focus on the issue
without mixing it up with other issues.
jjb
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
