Console Search/Filter

[nchevobbe]

In the future, we might want to expose a "Search" UI in the console, similar to the one that exists in the debugger, as opposed to the Filter UI we currently have.

This does not mean the Filter UI will go away as we do want people to be able to both search and filter at the same time.

---

One idea that was brought during a meeting last week was that the filter UI could be moved along the existing filters (Error, warning, CSS, XHR, …), where it makes sense to put it.

Here's how it could look like (quick and dirty mockup):

A list of recent filters (let's say 5) would be displayed for quick access re-enabling. On the filter bar, custom filters would have a delete button to easily remove them (you can also disable them).

Like for other filters, I feel like we should persist those custom filters across sessions, but maybe we could tie them to a given origin?

Let's discuss of those things here, so we can work on this on Q1.

[fvsch]

I was about to add a UX issue for "Unify and improve filter-by-type features across Console and Network". It would be great to come up with a search/filter UI that can be applied consistently to both Console and Network, even if they don't have the exact same feature set.

Currently, we're using the same icon as either informative or as a button, we display filter categories by default (Network) or collapse them by default (Console), etc.

[DPX-designer]

Other ideas which were discussed in the meeting:

• Having Search appear by default and using a button to toggle the appearance of the Filter bar underneath Search (Think Search and Replace in VScode).

• A toggling mechanism which flips between searching and filtering within the same UI.

• Simply having both Search and Filter inputs beside one another in the same bar.

Additionally the question was asked whether Search should be more prominent than filter? Which do people instinctively wish to use first?

[janodvarko]

A toggling mechanism which flips between searching and filtering within the same UI.

I can imagine two ways how that toggle mechanism could look like in the UI:

1. A checkbox next to the Filter input (close to the 'Persist Logs' checkbox)
2. Three dots menu (...) available within the Filter input used to open a context menu. Just like the URL address bar has. See the attached screenshot. The context menu could offer a toggle action.

Both should work for Console as well as Network panel.

Honza

[nchevobbe]

silly idea: we want to have the cog icon in the top toolbar to show options (preserve logs, show timestamps, …), maybe we could also have one in the input?

[fvsch]

we want to have the cog icon in the top toolbar to show options (preserve logs, show timestamps, …)

Indeed. Especially as with the Settings redesign we will want to move more options out of the Settings page and into the relevant tool.

But I would try to avoid having two (or more) "options" buttons in a given tool. My rationale for options/three dots button is:

• Only one "three dots" button, in the toolbox
• Only one "cog" options button per-tool

So maybe fine-grained options for the input should go in that single "Console options menu". If we want to show them nearer to the input, I would rather use a toggle button (a 2-state icon; for an example of these, see "Skip all pausing" in the Debugger or "Pause/Resume recording" in Network).

Edit: Victoria has a mock-up for Console settings here.

[janodvarko]

But I would try to avoid having two (or more) "options" buttons in a given tool.

Yes, makes sense to me.

[violasong]

Mostly popping in here to say: nice mockup Nicolas :)

Florens: Looks like that console settings link still works for me.

If I'm understanding this bug correctly — I like the idea of unified search/filter results. So it could show filtered results, but also highlight the word in each row. Probably would need the outline-style highlighter.