Grouped media simulation UI

[SebastianZ]

@nchevobbe already pointed out in bug 1692434 that the current UI with dedicated buttons doesn't scale well with more emulation features being introduced.

So a better way to display them needs to be found.

In https://github.com/firefox-devtools/ux/issues/129#issuecomment-780827098 I suggested a "toggle panel". This would be consistent with what we have for toggling different CSS pseudo-classes and for managing CSS classes and the UI would be associated with the CSS rules.

@fvsch wrote that a panel like that might easily get out of view and had several suggestions for different UIs:

1. A dedicated panel in the toolbox.
2. A dedicated tab in Inspector (same level as Fonts, Animations…).
3. As a button above the DOM view in Inspector (e.g. near the color picker).
4. As a button in the toolbox (near the RDM button).
5. As a button in the RDM toolbar (next to, or in place of, the touch emulation button).

Just for reference, the Chrome DevTools have all emulation features together with other rendering related options placed in a dedicated Rendering panel.

To mitigate the "out of view" issue, I suggest to add some indication when an emulation is active. For example, the main panel's tab could change its color like the Debugger does when script execution is halted. Additionally, there should be some tooltip or other textual representation indicating that the emulation is active. This works with my suggested toggle panel as well as Florens' suggestions 1 to 4.

Regarding the five suggested options,

1. A dedicated panel in the toolbox.

A dedicated panel would need to be enabled by default, otherwise this would be even more hidden than the toggle panel. Also, there wouldn't be sufficient options (yet) that justify a dedicated panel, in my opinion. That means the panel would mostly be empty. And if there are just rendering related features, it's better to keep them contextually near to related UI.

2. A dedicated tab in Inspector (same level as Fonts, Animations…).

Is an option, though the Inspector already has a lot of side panels which might be bad for discoverability again. Though I'd say it depends on the number of emulation options whether a dedicated side panel is justified.

3. As a button above the DOM view in Inspector (e.g. near the color picker).

A button would be visible enough, though I wonder what UI you had in mind when the button is clicked. I assume you meant that the button opens some kind of popup or overlay which would be a new piece of UI, as far as I know.

4. As a button in the toolbox (near the RDM button).

Like the Inspector button this would be visible enough, though just if that button is enabled by default. And again, there's the question of what UI should be shown when clicking that button. I.e. how the different emulation options should be toggled.

5. As a button in the RDM toolbar (next to, or in place of, the touch emulation button).

The RDM is rather used for simulating different devices, not user preferences. So I wouldn't place the options there.

Sebastian

[fvsch]

One idea I suggested in https://github.com/firefox-devtools/ux/issues/129#issuecomment-788771860 is that DevTools should probably not just let you “emulate” specific modes or media queries, but it should also report on what modes or media queries are matching whether the emulation is active or not.

That could probably happen in the same place.

A basic UI could be a table with "Media query | Current state | Override"

Media query	State	Override
Media type	screen	screen/print/all
any-hover	hover	hover/none
any-pointer	fine	fine/coarse/none
display-mode	browser	browser/standalone/minimal-ui/fullscreen
prefers-color-scheme	light	light/dark
prefers-contrast	no-preference	no-preference/more/less
prefers-reduced-motion	no-preference	no-preference/reduce
prefers-reduced-transparency	no-preference	no-preference/reduce

(This is an arbitrary subset of features from https://developer.mozilla.org/en-US/docs/Web/CSS/@media. Not all are implemented in Firefox, and not all would be relevant for developers or are a common ask.)

The third column could be a , or use some other UI pattern. It could be possible to merge the “current value” and “override” UI in some way too. In any case, the UI should make it clear, in no particular order:

• For each feature, if it’s using the browser/OS preference or a value set by DevTools.
• What each feature means (links to MDN look sensible).
• When there is one or more overrides active, that should be reflected in some way in the DevTools UI even when this specific panel is out of view (so, in the main toolbar or perhaps in the Inspector toolbar?)
• And maybe how long-lived the overrides are? (E.g. only active when DevTools are open, only for this page/session, only for the current DevTools session?)

SebastianZ commented 7 months ago

but it should also report on what modes or media queries are matching whether the emulation is active or not.

For what it's worth, the "At-rules" side panel in the Style Editor does that already. (Though there's definitely room for improvement.)

A basic UI could be a table with "Media query | Current state | Override"

For range queries like resolution the field could be an input instead of a drop-down list.

Another approach – especially when the number of possible emulation options increases – would be a dynamic list like in the Rules View or the CSS filter effects popup. I.e. a panel that's initially empty and you can add new emulations via two input fields. In the first one you'd type the media feature or type and in the second its value. Of course that requires smart autocompletion like in the Rules View.

That would have the benefit that the entries listed there reflect the active emulations.

Sebastian

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[SebastianZ]

but it should also report on what modes or media queries are matching whether the emulation is active or not.

For what it's worth, the "At-rules" side panel in the Style Editor does that already. (Though there's definitely room for improvement.)

A basic UI could be a table with "Media query | Current state | Override"

For range queries like resolution the field could be an input instead of a drop-down list.

Another approach – especially when the number of possible emulation options increases – would be a dynamic list like in the Rules View or the CSS filter effects popup. I.e. a panel that's initially empty and you can add new emulations via two input fields. In the first one you'd type the media feature or type and in the second its value. Of course that requires smart autocompletion like in the Rules View.

That would have the benefit that the entries listed there reflect the active emulations.

Sebastian