908307 - [Meta] Implement new devtools search and filter specs

Status: RESOLVED INACTIVE

(DevTools :: Inspector, enhancement, P3)

Description

[Codacoder]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

1 - Type stuff into search box (dropdown list appears with matches)
   - Arrow-down using keyboard

2 - Entering long ids (and listing them in the dropdown) does not scale


Actual results:

1 - My search text gets wiped which means retyping the whole thing (possibly)

2 - for common/frequently used text in the page, the list is long... if the search text is long (I dunno, 20/30+ chars?) the list shows only the left most chars which is common to all of them... making it useless as a selection mechanism


Expected results:

Both 1 and 2 would be improved if HTML panel was live-scrolled to the matching HTML as I arrow-down the list 

Also, leave my entered search text as is

Also, make the search box a LOT wider (or make it flex)

Comment 1

[Codacoder]

And make the placeholder hint at the expected input being a selector.  I had no idea it expected $() kind of input.

Comment 2

[Tim Nguyen :ntim]

(In reply to Russ from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101
> Firefox/23.0 (Beta/Release)
> Build ID: 20130814063812
> 
Btw, I recommend Firefox Nightly if you're a dev, latest improvements usually come there.

> 
> 1 - My search text gets wiped which means retyping the whole thing (possibly)
> 
> 2 - for common/frequently used text in the page, the list is long... if the
> search text is long (I dunno, 20/30+ chars?) the list shows only the left
> most chars which is common to all of them... making it useless as a
> selection mechanism

Yep I get this issue too but after a very long string.


> Both 1 and 2 would be improved if HTML panel was live-scrolled to the
> matching HTML as I arrow-down the list 

Yep, this would be nice to have.

> Also, make the search box a LOT wider (or make it flex)

Hmm.. I should experiment with that.

Comment 3

[Codacoder]

This is being addressed here, it seems: https://bugzilla.mozilla.org/show_bug.cgi?id=835896

Comment 4

[Sebastian Zartner [:sebo]]

This rather sounds like a meta-bug for several smaller UX improvements. In order to make progress on this and allow implementing these improvements separately, should individual bugs be created for them blocking this one?

Sebastian

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Sebastian Zartner [:sebo] from comment #4)
> This rather sounds like a meta-bug for several smaller UX improvements. In
> order to make progress on this and allow implementing these improvements
> separately, should individual bugs be created for them blocking this one?
> 
> Sebastian

Indeed, it makes sense. I don't have time ATM, but I will file these bugs later today.
Thanks

Comment 6

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: search-and-filter-spec.png

Hm... I'd potentially like a lot of eyes on this, Brian. What's the best way to go about that?

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #6)
> Created attachment 8751961 [details]
> search-and-filter-spec.png
> 
> Hm... I'd potentially like a lot of eyes on this, Brian. What's the best way
> to go about that?

Easiest way I can think of is to post dev-developer-tools

Comment 8

[Sebastian Zartner [:sebo]]

Summary from bug 1272254:

The features of the search field widget include:
- single content search
- multiple content search (i.e. 'search all files')
- search options
- search suggestions
- showing number matches
- indication for no matches
- focus shortcut
- clearing the field
- go to line feature (might be in a specialized widget; triggered through some special option [like typing a colon as in Debugger])

The features of the filter field widget include:
- filter options
- showing hint that items are filtered out and/or their number
- indication for no matches
- focus shortcut
- clearing the field

Sebastian

Comment 10

[James Long (:jlongster)]

Sebastian, I agree on many of those features but I don't think we need all of them from the start. Some of them won't be concerned with this at all, but with how the tool integrates search.

I do feel like there's another option for the searching UI: instead of a dedicated field, it's a wide popup field invoked by something like ctrl+p and autocompletes the search. The difference is that it can take up the whole screen and show a lot more info. Not sure if I'm missing some use cases though.

Comment 11

[Sebastian Zartner [:sebo]]

(In reply to James Long (:jlongster) from comment #10)
> Sebastian, I agree on many of those features but I don't think we need all
> of them from the start. Some of them won't be concerned with this at all,
> but with how the tool integrates search.

Sure, feel free to split those features out into individual bugs. The number of matches could be one of them, for example.
Though we should try to avoid regressing existing features in the first version.

> I do feel like there's another option for the searching UI: instead of a
> dedicated field, it's a wide popup field invoked by something like ctrl+p
> and autocompletes the search. The difference is that it can take up the
> whole screen and show a lot more info. Not sure if I'm missing some use
> cases though.

I'm not sure how you imagine this UI to look like but maybe it goes into the direction of bug 1026479.
What info do you imagine to see in there, which you don't get with the normal search field?

Sebastian

Comment 12

[James Long (:jlongster)]

(In reply to Sebastian Zartner [:sebo] from comment #11)
> (In reply to James Long (:jlongster) from comment #10)
> > Sebastian, I agree on many of those features but I don't think we need all
> > of them from the start. Some of them won't be concerned with this at all,
> > but with how the tool integrates search.
> 
> Sure, feel free to split those features out into individual bugs. The number
> of matches could be one of them, for example.
> Though we should try to avoid regressing existing features in the first
> version.

The new interface is not going to match 1:1 with everything from the start. There are going to be new features and probably some smaller features from the old one missing. Part of that is because we want to actually avoid current features which is confusing, but also because we can't do everything in the first version.

> 
> > I do feel like there's another option for the searching UI: instead of a
> > dedicated field, it's a wide popup field invoked by something like ctrl+p
> > and autocompletes the search. The difference is that it can take up the
> > whole screen and show a lot more info. Not sure if I'm missing some use
> > cases though.
> 
> I'm not sure how you imagine this UI to look like but maybe it goes into the
> direction of bug 1026479.
> What info do you imagine to see in there, which you don't get with the
> normal search field?

Pretty much what Cmd+P looks like in Chrome. It's totally different than anything we have right now. There aren't any screenshots in that bug so I'm not sure what that looks like.

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

There's some interesting discussion in here around Cmd+P which my current doc doesn't recognize—I should mention that this is still a work in progress and still under review, so I'll definitely be updating the doc to reflect that kind of searching as well.

Comment 14

[Sebastian Zartner [:sebo]]

(In reply to James Long (:jlongster) from comment #12)
> (In reply to Sebastian Zartner [:sebo] from comment #11)
> > (In reply to James Long (:jlongster) from comment #10)
> > > I do feel like there's another option for the searching UI: instead of a
> > > dedicated field, it's a wide popup field invoked by something like ctrl+p
> > > and autocompletes the search. The difference is that it can take up the
> > > whole screen and show a lot more info. Not sure if I'm missing some use
> > > cases though.
> > 
> > I'm not sure how you imagine this UI to look like but maybe it goes into the
> > direction of bug 1026479.
> > What info do you imagine to see in there, which you don't get with the
> > normal search field?
> 
> Pretty much what Cmd+P looks like in Chrome. It's totally different than
> anything we have right now. There aren't any screenshots in that bug so I'm
> not sure what that looks like.

Ah, you mean the sources filter.

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #13)
> There's some interesting discussion in here around Cmd+P which my current
> doc doesn't recognize

The doc here not, though you already created a filter field in https://projects.invisionapp.com/share/9G5R8XCYZ#/screens/117937554. And I believe that's all that's needed. No need for a popup panel like in Chrome.

Sebastian

Comment 15

[Helen V. Holmes (:helenvholmes) (:✨)]

Comment on attachment 8751961 [details]
search-and-filter-spec.png

Clearing Brian's review since there are some changes I'd like to make to this.

Comment 16

[James Long (:jlongster)]

The reason why the overlay (opened with cmd+P) is nice is because:

* Many developers are used to it, most modern editors have that sort of file-finder popup
* It can span about 70% of the width of the screen, making room to show a lot of data like long paths which is important when looking for files in a large codebase
* It does not take up room in the UI when not in use. I can see why a dedicated filter box is nice, usually because it's filtering a component directly (filter the variables view, the net monitor table, etc). But we don't want to actually filter the sources tree, because it's a tree and should not lose its state. Additionally, we probably want to include *other* results in the list, like function definitions. So this is more of a global search component not tied to anything specific in the UI.

We should leave it up to Helen as to what the final designs are. There may be other ways to do it, and Helen has a sense for what all tools need to how to consolidate the UX across them. I'm fine if it's not a popup, but I would like to take into account the benefits that it brings and cater to them a bit (particularly the fact that it can be really wide).

Comment 17

[Codacoder]

@James

That sounds as though it's going to hide the page as presented. In my OP, I'd specifically stated in the "Expected Results" that live-scrolling to the match (in the *inspector*) being the way to go. Now, well, the "bug" seems to be about something else entirely - it's been hijacked. Am I supposed enter it again?

Maybe the "new devtools search and filter specs" will solve all of these problems, but that's not clear to me.

Comment 18

[Nicolas Chevobbe [:nchevobbe]]

Since the design file attached here is outdated, I moved all the blockers of this bug to Bug 1332653 instead, and I'm going to close this one