[Debugger] Inline variable preview

[digitarald]

Debugging UIs are complex, so showing more context within code allows users can focus on just their code source and how it executes. Inline preview shows local values in context, with the code, while users pause and step; so it is easier to see state and changes.

Leads: @dhyey35 @darkwing Supporting: @loganfsmyth @janodvarko @jasonLaster

Related:

• Requirements document
  • Related work
  • Jason's mockups

Technical constraints:

• The information the preview has is the variable name (or property path) and the value
• Value preview is done using devtools reps
  • Gives us a rich, highlighted preview
  • Could even be interactive
• Small horizontal viewports and code with long lines could lead to previews causing scrolling, and being outside the default viewport
• Diverging: Variables can be interactive, one could imagine shortcuts for creating watchpoints or watchpoints (pause on variable access)
• Please add more, I will add them as comments come in

Example of current state of work, showing variables and property values:

[digitarald]

I like Jason's exploration where the value and variable are nicely separated with subtle boxes . Here my take on it, highlighting the variable name and only outlining the value.

[jasonLaster]

That looks good.

I'd like to also explore the different interactions as well.

• expanding/collapsing
• previewing
• context menu options like
  • copy to clipboard
  • copying the variable to the console 🏅

[fvsch]

Some accessibility questions:

• How should it read in a screen reader? Should there be a visually hidden label to make sure the code and previews are separated? Without intervention, this content might be hard to understand without information from layout and visual helpers:

var x = { a: 2, b: 'o' } x { a: 2, b: "o" }

Maybe something like:

var x = { a: 2, b: 'o' } Preview x = { a: 2, b: "o" }

• If we use subtle borders as signifiers of the equals sign in x { a: 2, b: "o" } (instead of the readable x = { a: 2, b: "o" }), my understanding is that those borders should meet this WCAG 2.1 criterion for non-text contrast and reach a 3:1 contrast. Currently the two mockups seem far from that. On a white background, a passing value could be #909090:

[digitarald]

Thanks @fvsch for the a11y focused feedback; we should ensure that we keep those in mind when moving on to more detailed mockups.

How should it read in a screen reader?

Given that variables are also shown in the Scopes pane, I would lean on hiding the information from screen readers. A11y in Debugger's codemirror parts is in general a big question mark for me and something we should understand better.

… those borders should meet this WCAG 2.1 criterion for non-text contrast and reach a 3:1 contrast

👍. I would add that the boxes need to have good contrast no matter what, as they otherwise blend in with the code and can't be told apart.

@violasong what are your initial thoughts?

[darkwing]

I really like the subtle boxes approach, and agree we should hide from screen readers. I think the right-click interactions would be a great bunch of follow up items too!

[violasong]

I really like what I'm seeing here and in the debugger channel!

A few questions:

Do we expect folks to easily understand what this is? Most other editors use an equals sign/colon — would that help understanding?

How important is the yellow? I usually like to keep it for warnings, but I see that yellow is common in a lot of editors. (And it looks like warnings/errors in quite a few of them!) Some editors (e.g. Jetbrains, below) make it look like a code comment. This feels intuitive to me, though it doesn't communicate interactivity.

It does help if we tone down the yellow a bit.

A colon could be added:

A few other tests:

Figma source :)

[dhyey35]

@violasong I think people would be easily able to understand which one is variable name and which is it's value, so an = would just use extra space every time.

[fvsch]

A few other tests:

These and the toned-down yellow ones are all pretty good. I like the purple one and first gray one, for no particular reason.

I still think having a symbol between the expression and value helps, and the colon or arrow might be less ambiguous than the equals sign (which could be understood as an assignment operator).

[digitarald]

A colon could be added:

@violasong one reason for the design change was that we could make the variable name clickable to collapse the variable. Some can be massive space hogs and collapsing them reduces clutter and can even help to clean the output up for taking a screenshot.

How important is the yellow?

We assume Chrome users are trained on it, and as you saw it seems to be the go to in many editors. Purple, which I am a fan of, might work just as well – and so does gray as it makes the syntax highlighting that preview uses a bit more vibrant.

Beyond a single color: Another idea discussed, which we can talk about when we get there, is to differentiate changed variables by color. A yellow highlight could be applied to updates.

In the backlog we also have inline preview for errors (which Chrome supports nicely, and which makes clicking from console errors to the source a lot more affordable), but also preview for console logs; bringing more context from the console into the source. Those would also be great elements to color code.

first gray one, for no particular reason.

IMHO I am not sure if just-gray without background works so well, as it can be confused with actual comments in the code.

[digitarald]

@violasong one aspect you might have seen in the shared screenshots, would be to mock up when previews on 2 lines, touching bottom to top, look like.

With line-height in mind, maybe borders could blend into a single line, or we try to keep some whitespace.

[violasong]

I still think having a symbol between the expression and value helps, and the colon or arrow might be less ambiguous than the equals sign (which could be understood as an assignment operator).

Yeah, I had this thought as well about the equals. I like that arrow means "output," but I'm guessing the colon will be the most commonly understood.

I think people would be easily able to understand which one is variable name and which is it's value, so an = would just use extra space every time.

I guess I'm thinking of situations of unfamiliar code, where variable names might not be obvious - and just a colon wouldn't take much space.

one reason for the design change was that we could make the variable name clickable to collapse the variable. Some can be massive space hogs and collapsing them reduces clutter and can even help to clean the output up for taking a screenshot.

Design change: As in the subtle boxes?

• Interesting. I think we'd need a bit more indication for clickability then.
• Should we truncate long previews, or do we want to show the full output by default?
• I feel I'd want the whole thing to be clickable to expand, like Console XHR messages. If we still use the subtle-boxes look, it would be decorative.

Example with "Console style" - truncated, disclosure arrow, fully clickable:

With subtle boxing, for an extra sense of being a button/badge:

[violasong]

How important is the yellow?

We assume Chrome users are trained on it, and as you saw it seems to be the go to in many editors. Purple, which I am a fan of, might work just as well – and so does gray as it makes the syntax highlighting that preview uses a bit more vibrant.

I'd actually describe Chrome's color as Peach Yogurt :D

...and it reads as midway between warning and error to me, especially when the previews are super long like in your screenshots.

In the backlog we also have inline preview for errors (which Chrome supports nicely, and which makes clicking from console errors to the source a lot more affordable), but also preview for console logs; bringing more context from the console into the source. Those would also be great elements to color code.

Sounds like now would be a good time to determine colors for all these situations. Preview for console logs might need to claim purple, since log points use purple.

[digitarald]

Should we truncate long previews, or do we want to show the full output by default?

Maybe @dhyey35 has thoughts on truncation; as we will hit reps bottlenecks with massive objects. We can leave this off the table until we know what we can do within reps.

Interesting. I think we'd need a bit more indication for clickability then. … I feel I'd want the whole thing to be clickable to expand, like Console XHR messages. If we still use the subtle-boxes look, it would be decorative. … truncated, disclosure arrow, fully clickable:

The arrow seems to borrow from trees and vertically expandable elements; which isn't the case here. Space is a premium in this case, so I would want to see if users get it without an icon. The feature would be also ok to be found through exploration.

The preview would not expand vertically; but could maybe use the preview tooltip or jump to the expanded object in the Scopes panel. Overall Debugger has existing UI for this that works really well for expanding objects.

Example with "Console style"

The boxes seem to have grown compared to the prior iterations. Maybe it makes sense to mock them up in context of code, to see how well they visually separate from code and align when they are close to each other?

Sounds like now would be a good time to determine colors for all these situations. Preview for console logs might need to claim purple, since log points use purple.

Not sure if users already have that association. Since logs can happen a lot throughout instrumented code, making them more subtle might also be worth an exploration.

[violasong]

The arrow seems to borrow from trees and vertically expandable elements; which isn't the case here. Space is a premium in this case, so I would want to see if users get it without an icon. The feature would be also ok to be found through exploration.

The preview would not expand vertically; but could maybe use the preview tooltip or jump to the expanded object in the Scopes panel. Overall Debugger has existing UI for this that works really well for expanding objects.

Ah, I see what you mean. It's more like an Inspector badge then. Making the whole area clickable area still seems best to me.

The boxes seem to have grown compared to the prior iterations. Maybe it makes sense to mock them up in context of code, to see how well they visually separate from code and align when they are close to each other?

I was about to say they haven't changed but they did accidentally get 1px taller somehow 😅 (here they are together) - but yes, this is a good next step to mock up :)

[violasong]

Here's how this could look: (changed font size to a step smaller than the code, and height of badge to match line height (15px))

[violasong]

Thought through the colors more and I'm still liking the purple.

Re: the other colors:

• Blue: Primary color, used in the most places and representing breakpoints, focus, and on-states. Could also be used for active line highlight in the future (if we want to match style editor on this) and general UI like toggled-on badges. Best to avoid for special UI like this.
• Yellow: For warning messages. Currently used as a hover-highlight color (which should probably be blue instead) and flash effects.
• Red: Error messages
• Grey: The Inspector badge off-state color. In Debugger, sounds like we could use it for understated messages such as logging.
• Green: Success color, and used in diffs for added lines. I tried it out in context but it sticks out a bit too much in this color scheme.

Here's purple + boxed effect

[digitarald]

changed font size to a step smaller than the code

Figma says 10px, is that correct? I have not found other obvious places where DevTools uses 10px. Trying to avoid scaling down the UI too much, how would this work with 11px?

Here's purple + boxed effect

With border find this somehow better to comprehend. Maybe because purple is also used in some parts of the syntax highlighting, it doesn't set itself apart as much as it should?

It also separates the boxes better for multiple variables, which tend to blend together more in the other screenshot.

The other side effect is that the lighter preview area helps with color contrast.

Aside for yellow …

> Yellow: For warning messages. Currently used as a hover-highlight color (which should probably be blue instead) and flash effects. For the long term, I like to better understand this, so it can inform future use of yellow: Do we have frequent warnings across panels that this might compete with? Yellow element highlighting is a "standard" UX across the web to focus attention; even in non-warning cases.

[violasong]

Figma says 10px, is that correct? I have not found other obvious places where DevTools uses 10px. Trying to avoid scaling down the UI too much, how would this work with 11px?

Here's how it looks with 11px:

I think the smaller font size fits into the badges better. The Inspector's badge font is even smaller - 9px.

[digitarald]

Yesterday I thought 10px works definitely better, but today I like both again – while 10px gives it a bit more room to breath.

Here is a take with reduced box size, hairline borders and 11px:

@violasong since we are down to pixel-tweaking, would it make sense to pick one fav now and then keep filing follow up fixes after reviewing the landed design?

[violasong]

Ah, interesting idea! Looking at these side-by-side though, I still think 10px is the easiest to comprehend due to the extra contrast in look/padding. It seems easier to jump my eye between the code and the previews.

Sounds good to follow up on tweaking later - would be great to see this in more real world contexts.

[digitarald]

OK, your latest 10px version is the final light design then, posted https://github.com/firefox-devtools/ux/issues/86#issuecomment-518886258

@jasonLaster brought up that we also need a dark mode version; after that we can probably close out this bug and file new ones for follow up tweaks.

[violasong]

Here's the dark mode version which uses colors based on the dark syntax purple.

[digitarald]

Follow up on font-size: https://bugzilla.mozilla.org/show_bug.cgi?id=1576687#c2

Testing non-retina designs would be good to keep in mind for future UX testing.

[darkwing]

Thank you for carrying this over @digitarald. A few things that maybe @fvsch or @violasong could help me with:

1. Do we have a standard retina/non-retina media query that we use throughout DevTools?
2. There was a suggestion that we could increase the line-height in the editor (it's now 15px/11). I'd love your help here to figure out a good line-height and font-size pairing :)

[violasong]

I don't have an easy way to look at this on a non-retina screen at the moment so it's tough to work on this. Can I get a screenshot? (I'm also happy to defer to Florens on this.)

For future reference: Do we have an estimate for how many users use non-retina? Is it... more than half? This would increase my need to dogfood on an older machine sometimes.

[digitarald]

Reference shot from a 1080p display 1 dpr.

Do we have an estimate for how many users use non-retina? Is it... more than half?

Maybe the UX team has those numbers to inform designs? A quick search through telemetry has not yielded.

Only related information I found is that the top screen sizes for hacks visitors are 1920x1080, 1366x768 and 1440x900. HDPI on smaller screen sizes just makes less sense, so I'd assume it is "common enough".

[digitarald]

Fix with 11px font-size, remove codemirror's 0.1px padding hack. Seems to work pretty well? @darkwing could you share what kind of issue you ran into when scaling up the font (or was it just caused by the codemirror hack)?

[fvsch]

Tip: one way to simulate a 1x screen (if you don't have one) is to open the Browser Toolbox and run :screenshot --dpr 1, then open the resulting image in your image viewer or editor of choice.

It works the other way too, that's how I do 2x screenshots these days ^^

[violasong]

Thanks all for the work on this. Sounds like this issue can be closed?

[digitarald]

Yes, this feature turned out great; looking forward to user feedback!