I'd just like to note that if you happen to be using "On for all pages" in the intended way described by that document, you CAN'T disable it only for Gmail, and it has the potential to lock up your entire browser while Gmail tries to load.
On Jul 13, 1: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. > > > > 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. > > * 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. > > * 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. > > 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. > > 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. > > 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. > > > > 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. > > Also, it's clear that the decision to conflate visibility with > activation was a deliberate one from the start; that's another area > where early feedback would've helped. > > > > (For instance: If I want to "debug a site deeply," why does it follow > > > that I want to debug *all open pages*? You think we never check GMail > > > in the middle of a debug session? If I want to debug a site deeply, > > > that's what Firebug should let me do, and exactly what 1.3 let us do.) > > > 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. > > Yes, I know. I'm very glad the design document wasn't followed > terribly faithfully. > > - Luke --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
