firefox-devtools / ux

Firefox DevTools UX Community
Mozilla Public License 2.0
103 stars 21 forks source link

Improve DevTools focus rings #7

Open violasong opened 5 years ago

violasong commented 5 years ago

DevTools focus rings that need UX help:

DevTools focus rings (UX solved, some implementation needed):

Design System

Examples of Firefox focus rings

It's pretty messy right now but useful for inspiration

image image
fvsch commented 5 years ago

Main tabs use hover style as focus style. I’d like to extend this to all of the toolbar buttons in each panel.

This can be useful, but is not enough for an accessible focus style, because the hover style is too subtle. For keyboard focus, it’s best to also add a strongly contrasted outline (which can be implemented as a CSS outline, border or box-shadow).

A possibly useful trick is to have all buttons use a 1px transparent border:

.some-devtool-button {
  border: solid 1px transparent;
  border-radius: 3px;
  padding: 2px 4px;
}

.some-devtool-button:-moz-focusring {
  border-color: blue;
}
jasonLaster commented 5 years ago

In the debugger and i believe the toolbox, we only show the focus ring on key down. We do not show it on mouse down. I think this is a nice pattern that other tools could benefit from.

aburone commented 5 years ago

Hi. Which one would be the good focus ring?

fvsch commented 5 years ago

The Photon design system defines focus styles for buttons as:

box-shadow: 0 0 0 1px #0a84ff inset, 0 0 0 1px #0a84ff, 0 0 0 4px rgba(10, 132, 255, 0.3)

We could use this style, but Photon elements are often 50% bigger than DevTools elements. So maybe we need to adapt it.

Personally, I would love it if each interactive element could have a 1px border (transparent by default, if the design doesn't use a border). This would enable us to do:

  1. Focus styles with a strongly contrasted blue border, plus a lighter 1px or 2px blue box-shadow.
  2. High contrast theme where all borders are visible and contrasted.

That would be cool, but I'm not sure a high contrast theme is on the books. So implementing with an inset box-shadow (1px) and an "outset" partial opacity box-shadow (1px or 2px) could be okay.

aburone commented 5 years ago

OK. Sooo. Do I start hacking around and put a PoC here? I've read the proton style guide. Is there one for the devtools (specially the dark theme)

Shall I create a bug for every instance of inputs with the wrong focus (that would be madness IMHO)

Also I realize that ie RDM styles are totally isolated from other tools. But in the inspector the changes I tried with other bug affected the settings.... Is there any documentation about this behavior?

fvsch commented 5 years ago

Also I realize that ie RDM styles are totally isolated from other tools. But in the inspector the changes I tried with other bug affected the settings.... Is there any documentation about this behavior?

The code is the documentation. ;)

Some stylesheets are generic and loaded in most all contexts, including:

Some stylesheets are loaded only by a given tool, they can be in the devtools/client/themes/ folder or in a tool's own folder (devtools/client/foo).

fvsch commented 5 years ago

Do I start hacking around and put a PoC here? Shall I create a bug for every instance of inputs with the wrong focus (that would be madness IMHO)

The current situation is that there are a lot of different ways that focus styles are applied, with many different styles; sometimes no focus styles are applied at all for some interactive elements (which is an accessibility bug); and often those focus styles are applied on clicks, which we would like to prevent (see Dealing with sticky focus styles for a general explanation, and :-moz-focusring for a way we could implement that in DevTools).

We still need to define the exact behavior and look we want to achieve, but a proof-of-concept implementation would help seeing an improved behavior and look in action, so that we can create a clear guideline.

So the next step could be:

  1. Implement a proof of concept in a limited part of DevTools.
  2. With feedback from UX and accessibility people (Victoria, Matt and yzen), create a design document that specifies what kind of result we want to achieve (how it should behave and look).
  3. Then we can create bugs for implementing that design; probably one bug per tool or per tool panel.

Steps 2 and 3 also depend on project management decisions. We should not go off and define a large change and open 30 bugs or more without input and some sort of sign-off. ^^

@violasong Does this plan sound good to you?

@aburone I think you can start working on step 1 if you're interested; I would suggest working on the Network monitor for the proof of concept, and focus on 3 areas: the top toolbar, the "no requests" view, and the request table (excluding the request details that appear on the right when selecting a row). This gives us plenty of different use cases: buttons that touch their container's sides, buttons that are offset from the toolbar's sides, text input that takes the full toolbar height, select buttons, table headers, table rows, etc. For this POC I would recommend creating a new stylesheet to load in the netmonitor iframe, and trying to override existing styles if needed.

aburone commented 5 years ago

Perfect. When I have something to show, shall I upload a patch in a bug report? Or is there another preferred way?

fvsch commented 5 years ago

I think you can create a bug, e.g. "Explore new focus ring styles in Netmonitor", and reference this issue. Then you can upload a patch to Phabricator (with r=fvsch). I'll note in the bug that we won't merge it.

aburone commented 5 years ago

Florens I created a html file with the basic idea and the different triggers. I used different focus color for dark and light themes. Everything is defined in variables for easier tinkering.

Let me know how far away of the mark I've got so I can create a better PoC in the actual devtools. https://bugzilla.mozilla.org/show_bug.cgi?id=1502098

fvsch commented 5 years ago

Nice, I've commented on bugzilla. Let's try to make progress there for now.

violasong commented 5 years ago

Hi @aburone and @fvsch, I'm so happy to see you working on this bug and I would really like to help more with this. I'm currently needing to focus on some tight deadlines coming up so I can't think about this much right now. I'm happy to go with Florens' plan and jump back in with feedback sometime next week when I'm able to. Thanks so much!

fvsch commented 5 years ago

We have a design proposal ready for review at https://bugzilla.mozilla.org/show_bug.cgi?id=1502098#c16

fvsch commented 5 years ago

Discussed at All Hands with @violasong and :yzen.

Main decisions:

  1. The proposal at https://fx-devtools-focusring.netlify.com/ is mostly validated; we'll probably drop the inset shadow for edge-to-edge elements.
  2. We do need an implementation that avoids adding focus rings on buttons after mouse clicks. Pending an implementation of :focus-visible in Gecko, we may need to experiment with using a polyfill. The Accessibility tool already uses Photon focus styles, and some JS hacks to prevent focus styles after clicks.

One way to go forward is to prototype implementing the new styles and the :focus-visible polyfill in the Accessibility tool. I'll change the Bugzilla bug with this goal.