Looks like I never actually filed a standalone bug for this design from a year ago.

https://mozilla.invisionapp.com/share/2XEEY0RYA#/screens/263400464

1. Primarily, this design cleans up the double toolbar of the console by moving the filter buttons into the filter bar. This will give the logs more room. It also adjusts some of the colors so they look less distracting.

2. Secondly, it proposes a Settings menu and a way to switch to a Chrome-style minimalist toolbar. This came from Twitter polling in which half of folks preferred minimalism, and half preferred everything to be always showing.

Color details: https://mozilla.invisionapp.com/share/2XEEY0RYA#/screens/263398480

Original doc: https://docs.google.com/document/d/1HG2mJi8jNklgUnIMND-iTnoPByI7HnAexmUXG-lyyCI/edit#

Thanks for filing this bug Victoria :) I'm creating smaller bug we can work on separately

Regarding the mockup, I can see that the button style is different from what we have:

• They have a grey background if they're enabled
• They don't have a background if they're disabled

Is this something we still want? I don't think this style is applied anywhere (for example in netmonitor), and I guess we should make this change toolbox wide if we still want it.

Yes, I think that change should be made toolbox-wide. (We had feedback about the blue button styling being too bold/distracting.) Looks like there was some confusion in which the gray Network buttons were reverted to match Console :/ https://bugzilla.mozilla.org/show_bug.cgi?id=1459539

Hello Victoria,

As a contributor kicked off this work I thought I'd look a bit more into this, and I have a few questions :)

1. In the screenshot, for 1, the button is disabled, but hovered, and you can see it has the same color as the enabled button, which is a bit weird when disabling a button (the color keeps being the same one it was before). Should we have another color for hovered buttons?
2. When one or multiple filters being disabled mean we're hiding messages from the user, we have this UI of a label + a button (See 2) that indicates something is hidden. I feel like this is redundant now since we always show the buttons and we have the "hidden messages indicator" right into them (e.g. Info (1)). So, should we get rid of both the label + the Reset filters button ? (I feel like Reset filters could be put after Requests |, not sure).
3. In compact mode, we have this Filters (23 hidden), which mimic what we currently have. But currently this counter also includes message hidden because of the filter input. Should we keep it that way? My gut feeling is that it could be a bit weird because the label is tied to the dropdown which is only about "button filters" (as opposed to the text input).
4. What the colors should be in dark mode?

Thanks a lot!

Quick remark about icons. Since the Invision mockup is one year old, we should use the newer icons for settings and the filter input. They are:

• https://searchfox.org/mozilla-central/source/devtools/client/themes/images/settings.svg
• https://searchfox.org/mozilla-central/source/devtools/client/themes/images/filter-small.svg

Also I think Console was the only user of filter.svg (the 16px variant), I don't know if we need to remove to avoid breaking some tests? It could be useful to keep it around, but if we do that we can end up keeping a lot of things around. :P

Victoria, friendly nudge about https://bugzilla.mozilla.org/show_bug.cgi?id=1523842#c3 :)

Ahhh whoops, yes! Thank you for the nudge. I didn't mean to file this bug and then fall of the face of the earth 😅

And these are super great questions.

1. In the screenshot, for 1, the button is disabled, but hovered, and you can see it has the same color as the enabled button, which is a bit weird when disabling a button (the color keeps being the same one it was before). Should we have another color for hovered buttons?

Yes. So, with the change to make the background white, the gray90-a10 will stand out better (than in your screenshot), and I think we should be able to use something like gray90 .05 for inactive-hover. For toggled-on hover, I would suggest gray90 .15. This kind of thing is best tried out in a build - so if you don't mind, give these a try and let me know what you think!

1. When one or multiple filters being disabled mean we're hiding messages from the user, we have this UI of a label + a button (See 2) that indicates something is hidden. I feel like this is redundant now since we always show the buttons and we have the "hidden messages indicator" right into them (e.g. Info (1)). So, should we get rid of both the label + the Reset filters button ? (I feel like Reset filters could be put after Requests |, not sure).

I agree this is redundant now, yay, so much visual weight reclaimed! Reset filters does make sense in that space.

1. In compact mode, we have this Filters (23 hidden), which mimic what we currently have. But currently this counter also includes message hidden because of the filter input. Should we keep it that way? My gut feeling is that it could be a bit weird because the label is tied to the dropdown which is only about "button filters" (as opposed to the text input).

1. What the colors should be in dark mode?

I'll get back to you later this week on these two other questions

turning my needinfo back on

I modified the main mockup to show how the hover and active colors should look:

https://mozilla.invisionapp.com/share/2XEEY0RYA#/screens/263398480

Just to keep things together, here's the related bug I just filed for Netmonitor: https://bugzilla.mozilla.org/show_bug.cgi?id=1530572

There's also similar work happening for the Changes panel https://mozilla.invisionapp.com/share/VFQC7MQSD9W#/screens

About the number of filtered messages by the text input, I was wondering if we could take advantage of the new clear button to put the button there. Basically:

+-------------------------------------+
| [myApp]                     (234) ✕ |
+-------------------------------------+

(there's a mockup in the attachment to have a better view of what it could look like).

I'm not sure about this yet.

Just in case, for future self or for the person who want to tackle this, here's the CSS changes required:

.devtools-searchinput-clear {
  /* width: 16px; */
  --icon-width: 16px;
  min-width: var(--icon-width);
  background-repeat: no-repeat;
  background-position: right center;
  padding-inline-end: calc(var(--icon-width) + 4px);
  color: var(--comment-node-color);
}

Adding Bug 1523864 as a dependency

Ah, nice. We could actually copy the Debugger's styling for this. So no parens needed - it could just say 238 messages (or whatever wording would be better)

Ideally we would also use the photon-style simple close button icon, if that doesn't look weird. Adding a separator bar between the close button and the Persist Logs checkbox would help clarify that it's part of the input field.

I just added dark mode variants to the same Invision link.

Give this a try and let me know what you think. I'd love to have a try build to test it out, as this type of styling is hard to evaluate without testing it in HTML/CSS.

(In reply to Victoria Wang [:victoria] from comment #13)

Created attachment 9050090 [details]
Screen Shot 2019-03-11 at 12.54.09 PM.png

Ah, nice. We could actually copy the Debugger's styling for this. So no parens needed - it could just say 238 messages (or whatever wording would be better)

Ideally we would also use the photon-style simple close button icon, if that doesn't look weird. Adding a separator bar between the close button and the Persist Logs checkbox would help clarify that it's part of the input field.

Thanks for your input Victoria. Now that I'm reading this, something is striking me: the number we currently have display the number of hidden messages. With this design, I feel like it should display the number of messages that are displayed. Does that sound right to you?
Anyway, when we have a prototype running, I'll definitely share a try build you can play with :)
Kelly's patch is really close to land, so we should have something in the next weeks (probably not for 67, but definitely for 68)

Also, for the close button, since we are going to use the shared SearchBox component, we could make the changes there and have it in all the tools using it.

[Brainstorming]
Maybe a label like:

"Showing 45/123 messages"

or just

"45/123 messages"

the number we currently have display the number of hidden messages. With this design, I feel like it should display the number of messages that are displayed. Does that sound right to you?

Ah yes! That's what I was thinking for this message. The best thing is that now it will say '0 messages' when there are no matches, so the user knows Console isn't just crashing on them.

Florens' idea makes sense. What about this? "43 of 123 messages"

Also, for the close button, since we are going to use the shared SearchBox component, we could make the changes there and have it in all the tools using it.

Awesome!

I like the idea of having the number of messages shown vs the total number of messages. Though I worry it might take too much space? The simplest form (4/123 or 4 of 123) might be not too long, I'll try to land that and then we can see how it looks, and if we want to improve it.

How does it look to you Victoria & Florens?

I'll try to land that and then we can see how it looks, and if we want to improve it.

Just to unblock this, short makes sense.

Looking at Chrome, which shows the hidden count (17 hidden), similar to our current Console filter UI – this might make it even easier as it is the information people are probably most looking for (as in "how many messages are filtered?") and it is short. This would make the filter element UI 14 filtered (x).

One concern I have (which I should have brought up in my initial comment) is that we show the hidden state in the filter input vs showing the hidden state for all disabled filters (Errors, Warnings, Logs, Info, Debug). With a hidden indicator outside of the input, we can extend the indicator to present the complete hidden message count, not just the string filter.

I remember we had past mockups with hidden indicators in the type-filter buttons, so it seems to be a reoccurring thought.

I wonder how important it is to show the total number considering the different ways filter buttons are used vs filter text.

I'm assuming that the filter text tends to be temporal, usually one-off search actions, so it makes sense that its hidden number is right next to the x button, which clears the number in addition to the text.

On the other hand, the filter button states might last the whole session or many sessions, and those indicators are more like passive notifications, so there generally isn't a need to clear them all at once (e.g. reset to default).

Button colors will be handled in Bug 1525039 (which was close to land, but stalled)
I think I like the idea of X hidden: there's little value in showing the total number of messages. same for total number of visible messages. These numbers act as little notifications to remind the user that something occurred they can't see because of the filters.

I think this looks pretty good! If you don't have any objection on this, I'll proceed with this patch and try to land it soon (and then do the button color one)

This does look good!

A little extra spacing between the x button and the hidden number would be nice. But I'm actually going to file a bug now to tone down that x button styling everywhere (it needs to be smaller, lighter, and have more spacing on both sides) so I guess that work can all be done separately too :).

Filed universal (x) button bug here