876643 - Should probably stop showing the description arrow panel after a few counts

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect, P3)

Description

[Girish Sharma [:Optimizer]]

When you click/focus the search box in debugger, a description panel appears telling the specific uses of the box.  On one hand it is really useful, but it is not required to be shown always .. It conflicts with double/triple click behavior in the search box, and becomes rather annoying to have it jumping around.

Two things can be done here:
1. Have a counter and stop showing that panel after say 10 times the panel is shown.
or.
2. Show the panel only once per debugger opening.

Comment 1

[Rob Campbell [:rc] (:robcee)]

Why don't we make it an option to never show the panel?

Comment 2

[Girish Sharma [:Optimizer]]

Its really a small thing to be moved to option. Also, who wants to see that everytime ? Its useful in spreading awareness, but after a few times, the user already knows all the shortcuts, no need show the panel again and again .

The best solution that I can think is to show it once per debugger opening.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

Nobody will know all the shortcuts unless they've used them all. *I* don't even remember them all and I've used them more than most people ever will.

I feel like this help panel is not that intrusive, as far as panels go, but I can see how some people can be more sensitive to it than others. An option sounds like a good compromise, apart from the usual aversion to adding more options.

If bug 876633 is the main reason for doing this, I say let's find a different solution for that. It's not like hordes of people have been complaining about the help popup being annoying.

Comment 4

[Girish Sharma [:Optimizer]]

I know that not many people are complaining about it (may be none). Doesn't mean that we should not do anything about it though. The showing up of the panel imo is inconsistent. It doesn't open when the search box is focused via any other method than mouse click. Moreover, there is no need for it to reopen if the focus was already inside the search box and the user clicked in it again.

If we have to show it repeatedly, then we should probably only show it when the searchbox goes into the focused state from a non focused state via mouse. (I still do not get why only via mouse ..)

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

It opens fine for me when I hit Cmd-P.

Comment 6

[Girish Sharma [:Optimizer]]

(In reply to Panos Astithas [:past] from comment #5)
> It opens fine for me when I hit Cmd-P.

(when you have the searchbox already focused)

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Girish Sharma [:Optimizer] from comment #6)
> (In reply to Panos Astithas [:past] from comment #5)
> > It opens fine for me when I hit Cmd-P.
> 
> (when you have the searchbox already focused)

No, it opens even when it's not focused. If you don't get that behavior, then you should file another bug.

Comment 8

[Girish Sharma [:Optimizer]]

I meant, that when you press a shortcut and the focus is already in searchbox, then the panel does not open.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Girish Sharma [:Optimizer] from comment #8)
> I meant, that when you press a shortcut and the focus is already in
> searchbox, then the panel does not open.

Nor should it, this is not how it was designed. The idea is that you press Cmd-P to focus the search box and then you can use a number of prefixes to your search term to modify the type of search that will be performed. Since these prefixes are not terribly well-known, we want to educate users about them. When you get more comfortable with them, you might want to start using their direct keybindings instead. In that case you are actually doing a very specific search and displaying the help panel doesn't buy you anything. It's only when you focus the search box without any specific prefixes that we let you know about them, since memorizing them all is hard and probably useless.

Comment 10

[Girish Sharma [:Optimizer]]

(In reply to Panos Astithas [:past] from comment #9)
> (In reply to Girish Sharma [:Optimizer] from comment #8)
> > I meant, that when you press a shortcut and the focus is already in
> > searchbox, then the panel does not open.
> 
> Nor should it, this is not how it was designed. The idea is that you press
I agree. see below.

> [...]
> only when you focus the search box without any specific prefixes that we let
> you know about them, since memorizing them all is hard and probably useless.

So why is mouse focusing behavior not consistent with this shortcut behavior. Mouse focusing shoudl also trigger the description notification only when it is without any specific prefixes. Right now, mouse click will open the panel *always*, even if there is some text in it, or a valid prefix is already there, or even if the searchbox is already focused.
And if you do not see this behavior, then something is broken on Windows.

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

I don't recall whether this minor inconsistency was intentional or accidental, but I posit that it is indeed useful. 

Ask yourself, why would anyone start typing into the search box and then reach over to their mouse to click in it again?

Mistake? Quite possibly, but we're not interested in that case.

I'll wager that the second most common case will be the following: a newcomer to our tools clicks in the box (or presses Cmd-P) and sees the help panel. He then clicks on one of the prefixes that he finds most useful and starts typing. A few moments later maybe he realizes that he clicked on the wrong button or that a different prefix would actually help him more. So he deletes everything entered so far, but that gets him to the default 'filter scripts' behavior. He knows that there was another one better suited to his task, so he just wants that help panel back.

So what does he do? How can he bring back that help panel? By doing the exact same thing that got him the help panel in the first place: click the input box or press Cmd-P again.

We are creatures of habit after all.

Comment 12

[Girish Sharma [:Optimizer]]

I don't want to be persistent here, so feel free to wontfix the bug. But I still feel that the panel is shown just a little too much number of times, adding to that the jumping animation can get annoying very easily. It surely is useful to a newcomer (but he will not always be a newcomer..) , thus my initial proposal of having some sort of counter or something ...

Comment 13

[Eddy Bruel [:ejpbruel]]

(In reply to Girish Sharma [:Optimizer] from comment #12)
> I don't want to be persistent here, so feel free to wontfix the bug. But I
> still feel that the panel is shown just a little too much number of times,
> adding to that the jumping animation can get annoying very easily. It surely
> is useful to a newcomer (but he will not always be a newcomer..) , thus my
> initial proposal of having some sort of counter or something ...

I could agree to such a proposal provided there is an straightforward way for users to bring up the panel in case they really do want it (as Panos pointed out in comment 3, nobody will know all the shortcuts unless they've used them all).

If you have any ideas on how we can meet both use cases (we don't want the panel to keep popping up when its undesired, but we want it to be easily accessible when it *is* desired), let me know. If we can't come up with anything it's probably best to leave things the way they are, in which case I'm leaning towards WONTFIXing this.

Comment 14

[David Walsh :davidwalsh]

No longer an issue in the new debugger.