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
-~----------~----~----~----~------~----~------~--~---
