809348 - Filtering scripts by default is confusing

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Victor Porof [:vporof][:vp]]

We had a few complaints on this.

I could imagine that no operator == all operators :) So a panel showing the first results for every kind of search you can think of may be helpful. I don't think this would be slow at all, since the only bottleneck we have is building the ui.

Comment 1

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

yeah, we might want to rethink which search/filter mode we use by default. My brain usually does a backflip when I remember that it's filtering on script names only by default. I kind of want full-search to be the default, but would love to have some feedback on what makes sense.

Comment 2

[Kevin Dangoor]

I've always thought that a spotlight-like search would be a cool and useful thing (like Victor's suggestion in comment 0) Google's rise in search kind of makes you long for a search box where you just type in what you want and it figures out the best choices for you :)

Other than that, though, this seems like an area for some user research. I doubt there would be 100% agreement on this. The current behavior is natural *to me*, but I'm a Sublime Text user. I can definitely see that this wouldn't be the case for others.

I think a spotlight-like search could provide results that everyone would like, but I'd worry about the speed of getting to what you want compared to the current setup.

Victor: do you know what the complaints were specifically? Did people say what specifically they didn't like or what they would like instead?

Comment 3

[Victor Porof [:vporof][:vp]]

(In reply to Kevin Dangoor from comment #2)
> I've always thought that a spotlight-like search would be a cool and useful
> thing (like Victor's suggestion in comment 0) Google's rise in search kind
> of makes you long for a search box where you just type in what you want and
> it figures out the best choices for you :)
> 
> Other than that, though, this seems like an area for some user research. I
> doubt there would be 100% agreement on this. The current behavior is natural
> *to me*, but I'm a Sublime Text user. I can definitely see that this
> wouldn't be the case for others.
> 

Agreed with you here. It totally makes sense for me as well, especially when using the chrome debugger; the first action would definitely be to select a source from the hundreds listed.

I don't think we're regressing ux by having a spotlight-like search. We'd still filter scripts by name (and even showing them in a panel now), but offering additional suggestions (string matches in files, variables in the current scope etc.)

> Victor: do you know what the complaints were specifically? Did people say
> what specifically they didn't like or what they would like instead?

The general complaints were specifically directed to unexpected default behavior. I believe users were either used to Firebug-like searching (search in all files, jump to first match automatically), or Chrome (search in the current file only). The behavior we were proposing by default was completely different.

> I think a spotlight-like search could provide results that everyone would
> like, but I'd worry about the speed of getting to what you want compared to
> the current setup.
> 

I'm not at all worried about speed. The routines implemented for actual searching are very efficient; for global search results, the profiler shows only around 7 or 8% for finding the actual matches. 70-80% is just building the UI.

As long as our spotlight-like results panel draws fast, we should be fine.

Comment 4

[Kevin Dangoor]

(In reply to Victor Porof [:vp] from comment #3)
> (In reply to Kevin Dangoor from comment #2)
> > Victor: do you know what the complaints were specifically? Did people say
> > what specifically they didn't like or what they would like instead?
> 
> The general complaints were specifically directed to unexpected default
> behavior. I believe users were either used to Firebug-like searching (search
> in all files, jump to first match automatically), or Chrome (search in the
> current file only). The behavior we were proposing by default was completely
> different.

That makes sense. I was viewing this filter box as being akin to the search box at the top of Firebug's file list (which is a *really* odd place for a search box, but it works). Coupled with the Sublime-like search operators, you can use the filter box for whatever you want. I do think the help popup that's there now helps a lot.

> > I think a spotlight-like search could provide results that everyone would
> > like, but I'd worry about the speed of getting to what you want compared to
> > the current setup.
> > 
> 
> I'm not at all worried about speed. The routines implemented for actual
> searching are very efficient; for global search results, the profiler shows
> only around 7 or 8% for finding the actual matches. 70-80% is just building
> the UI.

I actually meant speed in the sense of how many keystrokes/mouse movements it takes to get to what you want. (user interaction speed, rather than CPU speed).

The current behavior is quite fast for navigating, in the same way that Sublime's goto anything is.

Comment 5

[Victor Porof [:vporof][:vp]]

(In reply to Kevin Dangoor from comment #4)
> 
> I actually meant speed in the sense of how many keystrokes/mouse movements
> it takes to get to what you want. (user interaction speed, rather than CPU
> speed).
> 

I think the ordering of results is very important here. I say we want to maintain using the same UP/DOWN keys for navigation, so the only issue here is deciding what's the the first thing you "hit" when pressing DOWN?

Since the most expected feature is text searching, I would imagine something like:
1. Matches in other files (!)
2. (soon to be added) Function definitions (@)
3. Other matches in this file (#)
4. (if the debugger is paused) Variables in scopes (*)
5. (in case of a number query) Line results (:)
6. Scripts filtering (currently no operator)

Thus, by pressing DOWN you browse through global search results (requested behavior), and pressing UP wraps around and gets you to script filtering results.

I think showing at most n (where n=5?) results for each item should be enough. It would also be pretty cool to add a "Show all results" link for each category, which would turn our query into a specialized search (prepend the corresponding operator).

In this case, do we need an extra operator for doing only scripts filtering? I'd say no, but I can't think of a good enough reason other than preserving the foo:n and foo#baz syntax for jumping to file + line or file + token.

Comment 6

[Victor Porof [:vporof][:vp]]

If we ever do this, then filtering scripts would need its own operator (I was thinking maybe "~"?), in which case a simpler approach than what is described in comment #5 would be to just do what Firebug is doing (i.e. search in the current source, then other sources, and automatically jump to the matched string in the source contents).

However I'm a bit worried now that the debugger searchbox has a little history and changing the behavior may definitely be perceived as unexpected by some.

Unassigning myself for now.

Comment 7

[Jason Laster [:jlast]]

closing as this relates to the old debugger.