Now that 1.4.0 has been released, some of this discussion is academic, but a few points warrant a reply:
> > 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? The documentation for FireBug is pretty poor to begin with, but I have yet to see anything that clearly points new users to any discussion of the new activation model. Here's a run-down of the FireBug documentation locations I'm aware of: http://getfirebug.com/docs.html It looks like this info hasn't been updated in years and there is certainly no mention of the new activation model. Since these appear to be the official docs, this presents a brick wall for new users who don't want to go digging through the inner workings of the FireBug project. IMHO, either maintain these as official, up-to-date docs or delete these pages entirely. http://getfirebug.com/releases/ The 1.4 section makes no mention of a new activation model. I expected to see a statement like "The way FireBug is enabled/activated has been streamlined. Users of previous FireBug versions should read about the details." with "read about the details" being a link to a specific discussion of how the old and new models compare. http://blog.getfirebug.com/ There are some blog posts about aspects of the new activation model, but blogs are about timely, topical discussion of issues a-la a newscast -- they don't work well for a reference or guide style of documentation which is what is needed here. http://groups.google.com/group/firebug-working-group/web/firebug-user-scenarios This is the best source of information about how the activation model works. However, I'm not aware of any "top-level" links to it (I know I would have never found it unless you linked it first) and even if I wanted to look for it, its name does not match what it contains. I can't see how you'd expect anyone to find this without it being directly referenced. So let me turn this around to you -- where is the official FireBug documentation that includes a discussion of both the new activation model for new users and a comparison of the old vs new activation models for veteran users? > > 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. Awesome! With 1.4 released, is this on the slate for 1.5 then? > > > 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. IMHO you are *dramatically underestimating* the value of good documentation. All other concerns aside, if you simply had http://groups.google.com/group/firebug-working-group/web/firebug-user-scenarios fully fleshed out in the official FireBug documentation along with an old-to-new transition/migration page, many, many users would have been able to help themselves. Sure, there will always be some that don't bother to look for their own solutions, but most programmers are used to digging through documentation to solve their own problems. So when you combined a forced upgrade with no place for users read up on the changes, you got a bunch of unhappy users. 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 -~----------~----~----~----~------~----~------~--~---
