I suggest the following approach: To test the actication-model, create a new Firefox-add-on: The activation-model without Firebug debugging: It would be a simple - say - coloured square: Red when for the site FB is deactivated, green when it is activated for the site blue when it is activated for selective pages/tab of the site and is active hier orange/violet when it is activated for selective pages/tab of the site and is not active hier.
This could be than offered as a guinea-pig solution, which is relatively simple to change. When everyone is happy about it, it would replace the activation model of the then newest FB-version. This could of course include a positive/negative list at site and/or page-in-site level and run-time deactivation at tab level for speeding up debugging. On Jul 13, 11:43 pm, johnjbarton <[email protected]> wrote: > On Jul 13, 12:20 pm, Luke Maurer <[email protected]> wrote: > > > On Jul 13, 8:17 am, johnjbarton <[email protected]> wrote: > > > > On Jul 12, 11:56 pm, Luke Maurer <[email protected]> wrote: > > > > > !!!! Dude! Why didn't you say there were design documents?! > > > > > Also, why have a separate group for them? Or why not redirect the > > > > design discussions from here over there? > > > > The separate group is focused on input from Firebug developers rather > > > than Firebug users. > > > Well, sure, that's the *focus.* What I'm saying is that it would've > > been good to at least *involve* the community in the early design > > process. > > I will try to increase the information about the 1.5 design work sent > through the blog and repointed in the newsgroup. > > > > > > > > > Seriously, we could all be having a much better informed and more > > > > productive discussion if we realized that there were documented > > > > rationales for all these decisions. Now we know what your assumptions > > > > were (and right away I can see that you erred in your consideration of > > > > what a "power JS user" is, if there is such a thing; the big category > > > > you're missing is JS/Ajax *developer*, which happens to be the > > > > constituency objecting the most to the changes). > > > > Rather than asserting an error, it would be more helpful if you can > > > say what specific issue you see missing the user experience scenario. > > > As I said, the needs of someone debugging a Web application are either > > missing or poorly represented. The closest match would be the "Power > > JS User" (which is a nonsensical descriptor anyway - who would > > describe themselves primarily that way? Sure, people *are* power JS > > users, but only as a means to an end, like Web development). But even > > then, you have bullet points like: > > > * User manages the state of each panel for every site they visit. > > > Huh? I do? Why? Why would I do that? I might well manage the state of > > each panel for the site *under development* (though normally I just > > want all of them on), but certainly not every site I visit. > > That bullet referred to a feature of 1.3 that we decided to remove. > Like you say, "why would I do that?" > > > > > * User has a strong understanding of how many tabs they have open and > > can keep track of Firebug's debugger status in them. Usually debugging > > 2 or more sites at a time with console logging and javascript > > breakpoints. > > > This simply makes no sense to me. What's the use case for debugging 2 > > sites *at once*? I mean, I guess I can see that some people might do > > that. But it's far from the primary case. > > The reason for such cases: do we support it, allow it, or prevent it. > I believe we allow it. > > > > > * User understands various options and settings that tweak output to > > console or causes breaks in script debugger > > * User enjoys having fine-grained control over different options and > > can turn features off to improve browser performance. > > > I alluded to a misframing of the design constraints as novices vs. > > power users earlier, and here we see it manifested. Why wouldn't a > > designer want fine-grained controls? Why *would* a JS developer > > necessarily need them? Frankly, "I want to tweak stuff" is simply not > > a user scenario. > > We considered a wide spectrum of users. We did not exclude any one on > the spectrum. > > > > > Finally, there's one *crucial* aspect about Web app development that > > you're missing: > > > * User is typically working for long periods on a single site while > > simultaneously having other sites open in different tabs for unrelated > > purposes (documentation, bug slips, GMail, etc., etc.). Debugging > > tools are needed only on the developed site. > > The point of those notes was to implement activation. The reason we > need activation is to support users who want Firebug on some sites and > suspended on other sites. So we did not spell it out, but that aspect > is the entire reason for the notes. > > > > > Note that this means that any assumption that "deep debugging" should > > be a task that takes over the whole browser is flat-out wrong. I can > > be doing plenty-deep debugging and still be checking e-mail or > > perusing API docs. If those features will interfere with those other > > tasks, I want them off for those other sites. > > So 1.4 should be great for you. > > > > > The takeaway from this is that, for Web developers doing debugging > > work, *per-site settings are essential.* But you know that, which is > > why you compromised on your grand vision by not removing them > > *entirely* but kinda-sorta faking them by following the user's clicks > > around and making apparently transient user actions (like closing the > > console) permanent decisions. And now no-one's happy, because the new > > activation model is missing features that many of us depend on but is > > still decidedly confusing to work with. > > Your description in this paragraph makes no sense to me. > > > > > > > So why not have those documents be part of the discourse earlier? > > > > Those notes were only relevant during the design work back in January. > > > I only pointed them out in case someone wants to work on an > > > alternative activation. > > > That's what I mean. We should've been hashing all this out *back in > > January.* Clearly the biggest design missteps taken were rooted in > > fundamentally incorrect assumptions that could've been corrected early > > on. > > I doubt that we would get any feedback of the kind you imagine. In > addition we would have the problem of deciding whether the feedback > was representative or not. > > Putting out pre-release versions is much more effective. Based on > alpha and beta feedback we fixed a lot of things. We missed a few > things so we held off the final release until we had dealt with them. > > 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. > > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
