> > > > 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. > > The first "Learn More" link > onhttp://getfirebug.comishttp://getfirebug.com/doc/enablement/enablement1.4.html
Actually it goes to http://getfirebug.com/using.html which contains content, but then uses a meta redirect to reach http://getfirebug.comishttp://getfirebug.com/doc/enablement/enablement1.4.html . Since many users have meta redirection disabled, you should probably change that. Redirection aside, the front page's Learn More topics are hardly equivalent to any kind of usage documentation or reference materials. The intent of the front page and its Learn More topics is to sell potential new users on the merits of FireBug. If you are already sold on FireBug, it's unreasonable to expect anyone to re-read that information; especially when there isn't any hint that the link is being redirected to new and pertinent information. Side Note: Coincidentally, the "Put down your spectacles" section of this page shows a picture of the 1.3 FireBug menu which includes both "Disable FireBug for All Sites" and "Allowed Sites..." commands. Obviously you'll want to fix that -- unless you want to make me happy and bring them back :P. > 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. > > I wonder what resources informed your opinion? As far as I am aware, > only the FAQ is seriously out of date. I fixed that one. The information here isn't out of date, but the topics covered here are incomplete. Basically the docs here are a more of a quick- reference for the console than a guide or reference for FireBug as a whole. I'm not going to list everything that could be added here, but I will point out two key topics missing. The first is obvious: the activation model's behavior isn't here. Even the Learn More link you cited above isn't referenced by these docs. Since this is the primary way users interact with FireBug, I think it warrants being mentioned here. The second is a list of what the various FireBug options do. Some of them (e.g. Activate Same Origin URLs) require discussion because improper usage can crater FireFox. Others could use some details as to what they are actually doing (e.g. what are the extra checks done when the Console's Strict Warnings is enabled?). > >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. > > But I can do them quickly. Right. And it's a great thing that you maintain an active blog. :D But like I said, blogs aren't good as permanent references because they lack proper indexing. For example, your post http://blog.getfirebug.com/?p=304 about Minimizing FireBug includes some good info that I cannot find anywhere else (it is somewhat discussed on the enhancements page you cited, but TBH this blog entry does a much better job). Right now, it is the 2nd post in your blog so you could argue that users will easily find it, but how long will that remain the case? The 6 months of this year's blog posts already go back 5 pages. So 6 months from now when 1.5 is being discussed like 1.4 is now, do you expect users to go back 5 pages to find that Minimizing FireBug blog post? > > > > > 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 > > hadhttp://groups.google.com/group/firebug-working-group/web/firebug-user... > > 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. > > Ok, suppose I gave you the choice: shall I work on outputing > activation URLs or documentation? There is a difference between seeing the need for a something and prioritizing the work for it. Seeing the need is where this discussion started and hopefully you agree that FireBug's documentation needs some polish. Once the need is identified, the work can be done by via user contributions or by the FireBug team. With no clear and simple platform for user contributions (e.g. no Wiki, no user authored forum stickies, etc), this means the FireBug team must prioritize this work item among all other items. TBH it's not that the information isn't available, it's that the information is scattered all over the place; it's in FireBug Google Group replies, FireBug Working Group pages, disconnected getfirebug.com web pages, and various blogs. So if the information is already available (meaning the hard work of capturing the knowledge is already done), you only need to do a smattering of additional work to create a codex of links to that knowledge. Since http://getfirebug.com/docs.html already has 6 reference links like this, you could easily flesh out those links with more. It's near zero work for the FireBug team to maintain such a codex and it doesn't change the way or amount of documentation that the team is already doing on their own (e.g. via blog posts), but this would be a tremendous help to users, especially new/novice users. Regards, -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 -~----------~----~----~----~------~----~------~--~---
