conflation of UI visibility with activation

[nod]

Okay, let's start fresh and try this again. Long time user, 2nd post.

Looking through the newsgroup, I see several people trying to
articulate this point and explain why it's such a significant problem,
without success on the receiving end. I don't know if I'll be more
successful, but I'll be trying to be very concrete, logical, and step-
by-step.

Core problem description: conflation of UI visibility with activation
I'll be trying to explain:
1. what this is
2. that this is different from previous Firebugs
3. why the conflation is a bad thing
4. why the way the change was implemented is a bad thing

Scenario A:
1. Ctrl-F12, "Open Firebug in New Window"
2. See a greyed-out window with a button in the middle saying
"Activate Firebug for the selected Firefox tab"
3. Think "ok, I will activate Firebug so that it will be 'on' and I
can debug this web page"
4. Click the Activate button.
5. Discover that a page refresh is needed, and refresh the web page.
6. Use Firebug to investigate an issue in the web page
7. Be finished with Firebug for the moment, but want to continue
working with the web page
8. Use i) Ctrl-W, ii) File->Close, iii) the red "X", or iv) "Open
Firebug in New Window" to close the Firebug window.
9. User now thinks Firebug window is closed, but that Firebug is still
running (like all previous versions) on this web page.
10. Repeat step 1.
Expected: To be in the same state as the beginning of step 8
Actual: The user is at state 5
Expected: That the console log and net tab have been operating between
steps 9 and 10
Actual: Firebug has been "suspended" during that time, so any issues
have to be recreated

Scenario A illustrates how two functions which were heretofore
distinct:
1. The "on-ness" or activation of Firebug
2. The visibility of the user interface of Firebug
have been merged, or conflated, into one single thing, where "thing"
means both representation in the Firebug interface and action taken by
the user. This conflation leads to these perceived problems:

Expected: Hiding the Firebug UI does not turn it off for my web page
Actual: Hiding the Firebug UI turned off console logging, script
breakpoints, net logging
Expected: I turned Firebug on for this site, it should always be
running
Actual: Firebug gets turned off unintentionally - the user meant to
*hide* Firebug, but they also *deactivated* it because those two
actions are conflated.
Expected: There is a way to have Firebug hidden but running, like all
previous versions
Actual: There is NO way to close the Firebug external window without
deactivating Firebug for that web page.

These are all different ways of attempting to express the effect of
this conflation. Now, do I need to explain how this is different from
previous Firebug versions? In previous versions, once I got things
turned on for my whitelist of sites (which, for me personally is just
"localhost" most of the time), I never had to worry about it again. I
don't think there *was* any "suspension" of Firebug previously.

The existence of a suspension/deactivation feature is not itself a bad
thing. However, by tying it inextricably to the visibility of the
Firebug UI, users are forced to do both things when they only want to
do one.

The way this change was made really brought about confusion, by *not
changing anything visible*. The menu still says "Open Firebug", not
"Activate Firebug". The Firebug File menu still says "Close", not
"Deactivate". This is guaranteed to confuse all the users who are
migrating to Firefox 3.5 and are trying to deduce why/how Firebug
changed its behavior. (The no-auto-refresh change, while a good
change once a toggle/preference gets implemented, is another
confounding variable to figure out.)

Here are a few more problems with external window mode that are
inconsistencies with even the new conflated model: (These are NOT the
main issue here, they serve just to further illustrate how the
semantics of UI visibility are subtly different for in-page mode and
external window mode, further illustrating how the central conflation
fails to work usefully and understandably.)
Expected: "minimize" works the same for all modes of Firebug
Actual: in-page Firebug is hidden completely by minimize, while the
external window stays around in the Windows taskbar.
Expected: if the Firebug UI insists on being visible when active and
hidden when deactivated, then the external window should hide itself
for non-active tabs
Actual: the Firebug external window remains open (but greyed out) when
the user switches to a non-active tab
Expected: external window mode v. in-page mode will be remembered
Actual: if a user uses the "switch to non-active page, then close
external window, then come back to active page" trick, the Firebug UI
comes back inside the page rather than as an external window

I develop a web application that has server-rendered components that
are sensitive to page size. Having Firebug pop up inside the browser
makes my page size smaller, which causes Bad Things (tm) to happen
with respect to debugging ability. This is why I always use the
external window mode of Firebug, and thus why the conflation of UI
visibility with activation hits me - and all external-mode Firebug
users - even harder than most.

Are we now close to clear on the nature of this problem?
Again, love the tool and am here because I care. Thanks. -James

[Luke Maurer]

Wow! You have expressed the problem, as I see it, thoroughly and yet
succinctly. Thanks, and allow me to add my +1 :-)

- Luke

[Luke Maurer]

Wow! You have expressed the problem, as I see it, thoroughly and yet
succinctly. Thanks, and allow me to add my +1 :-)

- Luke

On Jul 6, 10:13 am, nod <james.a.ba...@gmail.com> wrote:

[johnjbarton]

On Jul 6, 10:13 am, nod <james.a.ba...@gmail.com> wrote:

> Okay, let's start fresh and try this again.  Long time user, 2nd post.
>
> Looking through the newsgroup, I see several people trying to
> articulate this point and explain why it's such a significant problem,
> without success on the receiving end.  I don't know if I'll be more
> successful, but I'll be trying to be very concrete, logical, and step-
> by-step.

Yes! This is the best way so I can understand.

>
> Core problem description: conflation of UI visibility with activation

I do not agree with this characterization of the problem.

> I'll be trying to explain:
> 1. what this is
> 2. that this is different from previous Firebugs
> 3. why the conflation is a bad thing
> 4. why the way the change was implemented is a bad thing
>
> Scenario A:
> 1. Ctrl-F12, "Open Firebug in New Window"
> 2. See a greyed-out window with a button in the middle saying
> "Activate Firebug for the selected Firefox tab"
> 3. Think "ok, I will activate Firebug so that it will be 'on' and I
> can debug this web page"
> 4. Click the Activate button.
> 5. Discover that a page refresh is needed, and refresh the web page.
> 6. Use Firebug to investigate an issue in the web page
> 7. Be finished with Firebug for the moment, but want to continue
> working with the web page
> 8. Use i) Ctrl-W, ii) File->Close, iii) the red "X", or iv) "Open
> Firebug in New Window" to close the Firebug window.

8i, 8ii, and 8iii if you mean the red X on the Firefox tab all mean
the same to Firebug: the user is done with this web page. According to
the design, Firebug will open the next time you visit this page. As I
understand it this is the same as 1.3.

I don't understand 8iv.

> 9. User now thinks Firebug window is closed, but that Firebug is still
> running (like all previous versions) on this web page.

I don't understand why: you closed the Firefox tab that you where
debugging, how can it still be running?

> 10. Repeat step 1.
> Expected: To be in the same state as the beginning of step 8
> Actual: The user is at state 5
> Expected: That the console log and net tab have been operating between
> steps 9 and 10
> Actual: Firebug has been "suspended" during that time, so any issues
> have to be recreated

According to what I read, the web page should have been closed?

>
> Scenario A illustrates how two functions which were heretofore
> distinct:
> 1. The "on-ness" or activation of Firebug
> 2. The visibility of the user interface of Firebug
> have been merged, or conflated, into one single thing, where "thing"
> means both representation in the Firebug interface and action taken by
> the user.  This conflation leads to these perceived problems:

But there is no such conflation: just hit the minimize button [_] to
see Firebug active and not showing.

>
> Expected: Hiding the Firebug UI does not turn it off for my web page
> Actual: Hiding the Firebug UI turned off console logging, script
> breakpoints, net logging

This will be fixed by changing [X] to "Off"

> Expected: I turned Firebug on for this site, it should always be
> running
> Actual: Firebug gets turned off unintentionally - the user meant to
> *hide* Firebug, but they also *deactivated* it because those two
> actions are conflated.

As I said it is not true. What is confusing is that [X] does do both
while it did not do that in 1.3.

> Expected: There is a way to have Firebug hidden but running, like all
> previous versions
> Actual: There is NO way to close the Firebug external window without
> deactivating Firebug for that web page.

That is correct. I don't plan to fix this, but I agree it is a
design flaw.

>
> These are all different ways of attempting to express the effect of
> this conflation.  Now, do I need to explain how this is different from
> previous Firebug versions?  In previous versions, once I got things
> turned on for my whitelist of sites (which, for me personally is just
> "localhost" most of the time), I never had to worry about it again.  I
> don't think there *was* any "suspension" of Firebug previously.

Sorry you missed it.

>
> The existence of a suspension/deactivation feature is not itself a bad
> thing.  However, by tying it inextricably to the visibility of the
> Firebug UI, users are forced to do both things when they only want to
> do one.
>
> The way this change was made really brought about confusion, by *not
> changing anything visible*.  The menu still says "Open Firebug", not
> "Activate Firebug".  The Firebug File menu still says "Close", not
> "Deactivate".  This is guaranteed to confuse all the users who are
> migrating to Firefox 3.5 and are trying to deduce why/how Firebug
> changed its behavior.  (The no-auto-refresh change, while a good
> change once a toggle/preference gets implemented, is another
> confounding variable to figure out.)
>
> Here are a few more problems with external window mode that are
> inconsistencies with even the new conflated model:  (These are NOT the
> main issue here, they serve just to further illustrate how the
> semantics of UI visibility are subtly different for in-page mode and
> external window mode, further illustrating how the central conflation
> fails to work usefully and understandably.)
> Expected: "minimize" works the same for all modes of Firebug
> Actual: in-page Firebug is hidden completely by minimize, while the
> external window stays around in the Windows taskbar.

Well they both make the UI out of your way. I don't see why it is a
problem.

> Expected: if the Firebug UI insists on being visible when active and
> hidden when deactivated, then the external window should hide itself
> for non-active tabs

But the premise is not true.

> Actual: the Firebug external window remains open (but greyed out) when
> the user switches to a non-active tab
> Expected: external window mode v. in-page mode will be remembered
> Actual: if a user uses the "switch to non-active page, then close
> external window, then come back to active page" trick, the Firebug UI
> comes back inside the page rather than as an external window

Also a design problem I know about and one I don't expect to fix soon.

>
> I develop a web application that has server-rendered components that
> are sensitive to page size.  Having Firebug pop up inside the browser
> makes my page size smaller, which causes Bad Things (tm) to happen
> with respect to debugging ability.  This is why I always use the
> external window mode of Firebug, and thus why the conflation of UI
> visibility with activation hits me - and all external-mode Firebug
> users - even harder than most.
>
> Are we now close to clear on the nature of this problem?
> Again, love the tool and am here because I care.  Thanks. -James

Thanks for your information, very helpful,
jjb

[Luke Maurer]

*Grrrr* ... thought that first post hadn't gone through. Damn you,
Google!! :-D

- Luke

[johnjbarton]

On Jul 6, 10:13 am, nod <james.a.ba...@gmail.com> wrote:

> Okay, let's start fresh and try this again.  Long time user, 2nd post.

...

> Again, love the tool and am here because I care.  Thanks. -James

Actually I realize I did not try your scenario, so I missed a key
point: its all about open in external window.

jjb

[johnjbarton]

On Jul 6, 10:13 am, nod <james.a.ba...@gmail.com> wrote:

> Okay, let's start fresh and try this again.  Long time user, 2nd post.

And now I am trying a second reply...

So the question I ask you is: what do you want 1.4 to do at this
point?

You want the page to remain active. But you don't want Firebug to be
detached.

In 1.3 Firebug acts as if you minimized. I think we can do that again.

The hard part here is insuring that the information stored in the
external window is again synced up with the information in the browser
window. The code that did this in 1.3 was bizarre, no one understood
it.

...

> Here are a few more problems with external window mode that are
> inconsistencies with even the new conflated model:  (These are NOT the
> main issue here, they serve just to further illustrate how the
> semantics of UI visibility are subtly different for in-page mode and
> external window mode, further illustrating how the central conflation
> fails to work usefully and understandably.)

...
The other message I want to get out about open in new window is
simple: we don't have the development resources to handle all of the
Firebug code. One option I have considered is dropping the external
window feature. Not dropping it is a decision which causes other work
to be dropped. So I urge folks who want the external window feature
to be supported: use the alpha and beta versions and give feedback
during the development. Since we don't here from you, the feature does
not get the attention you think it needs.

jjb

[nod]

> Actually I realize I did not try your scenario, so I missed a key
> point: its all about open in external window.
>
> jjb

Yes. Okay, I will not respond to most of your points in light of that
realization, presuming that if you still have questions/disagreements
about the problem description that you will post them afresh.

> This will be fixed by changing [X] to "Off"

As I understand this, you were talking about the in-page Firebug,
where there is a "Hide" (the minimize button).

>> Actual: There is NO way to close the Firebug external window without
>> deactivating Firebug for that web page.

>That is correct. I don't plan to fix this, but I agree it is a
>design flaw.

This makes me sad. I would revert to Firebug 1.3 for as long as I
could, if FF3.5 supported it.
Are you sure you wouldn't consider allowing some way to "close but not
deactivate" for the external window? Leave the "X" doing both actions
if you like, but give a File menu option labeled "Hide" that has the
Firebug 1.3 "X" behavior?

James

[johnjbarton]

On Jul 6, 1:50 pm, nod <james.a.ba...@gmail.com> wrote:
> > Actually I realize I did not try your scenario, so I missed a key
> > point: its all about open in external window.
>
> > jjb
>
> Yes.  Okay, I will not respond to most of your points in light of that
> realization, presuming that if you still have questions/disagreements
> about the problem description that you will post them afresh.
>
> > This will be fixed by changing [X] to "Off"
>
> As I understand this, you were talking about the in-page Firebug,
> where there is a "Hide" (the minimize button).

Yes, but the Off will be in both

>
> >> Actual: There is NO way to close the Firebug external window without
> >> deactivating Firebug for that web page.
> >That is correct.   I don't plan to fix this, but I agree it is a
> >design flaw.
>
> This makes me sad.  I would revert to Firebug 1.3 for as long as I
> could, if FF3.5 supported it.

1.3 + FF3.0 would work.

> Are you sure you wouldn't consider allowing some way to "close but not
> deactivate" for the external window?  Leave the "X" doing both actions
> if you like, but give a File menu option labeled "Hide" that has the
> Firebug 1.3 "X" behavior?

It's easy to stop the external window [X] from deactivating Firebug
for the page. The hard part is what to do next. What state is Firebug
in after you close the window? What data is in the window you closed
but now needs to be in the browser?

jjb

[johnjbarton]

James, I"m making a third pass over your note, mainly to advertise you
trying 1.5a9. Below:

On Jul 6, 10:13 am, nod <james.a.ba...@gmail.com> wrote:

Please try Firebug 1.5a9 and let me know if this is fixed.

...

> Expected: "minimize" works the same for all modes of Firebug
> Actual: in-page Firebug is hidden completely by minimize, while the
> external window stays around in the Windows taskbar.

I don't plan to change this. I could add back the [_] button inside
the UI but it would do the same thing and the operating system window
close.

> Expected: if the Firebug UI insists on being visible when active and
> hidden when deactivated, then the external window should hide itself
> for non-active tabs
> Actual: the Firebug external window remains open (but greyed out) when
> the user switches to a non-active tab

I don't get what the problem here is.

> Expected: external window mode v. in-page mode will be remembered
> Actual: if a user uses the "switch to non-active page, then close
> external window, then come back to active page" trick, the Firebug UI
> comes back inside the page rather than as an external window

I don't know the exact sequence here, let me know if 1.5a9 works or
not.
...

jjb

[Rob Campbell]

I really think the X button should remain as "Close" or "Off". The _
(or down arrow on Mac) minimize. Changing these two won't make sense
on that platform and should remain consistent for all users. It's
unfortunate that we have to use an "off" text button to represent
this, and hope we can move back to the graphical icon only in a later
version.

[littlewoodEd]

The detached window is a crucial feature, as the attached window takes
up screen real estate ordinarily used by the UI you're debugging. So
radically altering the runtime environment of what you're debugging is
an untenable situation. From my point of view, drop any feature but
that.
--ed