Console Row Borders

[DPX-designer]

To improve the legibility of a busy console containing many messages, row borders should be explored to provide a clear divider between individual logs and warnings.

Iteration 1 created by @fvsch:

• 1px borders using the splitter color (we probably want different colors for navigation, errors and warnings);
• 15px line-height for the text (11px font-size), as discussed with Victoria for the markup view;
• 2px padding, which makes the single-line rows 19px tall, and 20px tall if we count the top border.

Current feedback is positive for the dark theme mockup and the light theme mockup with grey 20 (pictured above).

Another discussion was around the inclusion of a setting to toggle line seperators, feedback on this idea highlighted that more settings can increase the likelihood of bugs and so should be considered carefully.

The next steps would be to produce visuals presenting these line seperators on a busy console, depicting a variety of different messages and log types.

@fvsch Did I forget anything? :)

[fvsch]

That sounds like everything.

I tried it in code, and here is an example on a busy console with errors and warnings:

Test with red/yellow borders for errors and warnings (I used the text color at 25% opacity):

Test with the same Grey 20 border for everything:

Same, but using the splitter color (Grey 25) for borders of errors and warnings:

Overall I'm not 100% happy with it, I find that the borders and background colors compete for attention a bit. Looking at what Chrome DevTools do, they have the same problem to some extent, but they use very light colors for console row borders (e.g. closer to a "Grey 15" than the Grey 20 for normal rows).

If we think this will help usability, I guess we can take a small "prettiness" hit.

[digitarald]

Personally, I like the gray borders as it seems less noisy – the additional contrast for errors/warnings is a great touch to improve contrast. But it is a tough call.

@mcroud would it make sense to tweet this out to gather some feedback?

[DPX-designer]

@digitarald A tweet should be in the pipeline 👌

[violasong]

Tweeted :)

I think the colored borders look great, but maybe could use less opacity to match the gray a little more? Let's see what people say.

[fvsch]

Looking at the replies to https://mobile.twitter.com/FirefoxDevTools/status/1076202797429710848 both options are popular, but it seems the colored borders have a slight lead.

I think the colored borders look great, but maybe could use less opacity to match the gray a little more

We can try that.

@nchevobbe I have a small implementation question. One way to handle borders is to have top and bottom borders for each row, and overlap rows by 1px (.message { position: relative; margin-top: -1px }). Do you think this could have a perf impact? It's much easier to deal with borders that way, because we don't have do have a bunch of selectors like this:

.message.error,
.message.error + .message {
  border-top-color: red;
}

[nchevobbe]

I don't know from the top of my head if there could be a perf impact, but we can run damp to make sure there is not.

[dholbert]

@digitarald pinged me to ask about this -- I don't think there'd be a perf impact to adding borders & using this margin-top hack.

Though, one minor correction RE this hypothetical styling... .message { position: relative; margin-top: -1px }

If you're just using margin-top for the adjustment, then you probably don't need position:relative. You would only need position:relative if you were using top (rather than margin-top) to make the tweak, I think.

[digitarald]

Implementation tracked in bug 1519904.

[fvsch]

The borders create a few design challenges.

Ideally, we want an error message to show two red borders (top and bottom), and warning message to show two yellow borders, etc. This creates issues with:

1. Borders between two messages (we want only one border)
2. The top border of the first message (clashes with the toolbar's border)
3. The bottom border of the last message (clashes with the input area's top border)

For (1), I'm showing errors and warnings above ordinary messages, so that the error/warning border takes precedence. When a warning follows an error or the other way round, the second item's top border takes precedence (so we get "red, yellow, yellow" for error+warning). We could decide that errors always overtake warnings ("red, red, yellow"), but in my tests it didn't look particularly better.

For (2), I'm removing the top border of the first message. Chrome does it differently: it puts a 1px gap between the toolbar and the first message, but this did not look better IMO.

For (3), Ideally the input area wouldn't have a border, so we would show the bottom border of the last message (whether it's light gray, red or yellow). This is what Chrome does and it looks good. BUT, when the logs are longer than the output area, we keep the input area fixed to the bottom, and it needs a top border to be clearly visible. Chrome doesn't do that: the input area scrolls way with the rest of the console content, which is not great. So for now I'm keeping the input area's top border (gray), and removing the bottom border of the last message. It's a trade-off. This is how it looks:

Finally, I'm wondering how to show the navigation messages:

• A: Use the default subtle borders (same as normal logs), errors/warnings take precedence

• B: Use a blue border with somewhat high contrast (I'm using our "Blue 30", which is more contrasted that the red and yellow shades I'm using for error/warning borders), and navigation messages take precedence over errors and warnings

• C: Use a lighter blue border and put navigation logs at the z-index as errors and warnings

[fvsch]

You can download a Nightly build for macOS with console row borders here. /cc @violasong @mcroud

[digitarald]

I like how A highlights the errors and warnings; this feels like the right balance and intention of raising importance of severe messages while visually differentiating.

[fvsch]

@nchevobbe Since you piloted the work on making the navigation marker more visible, do you think A would work (error and warning borders take over) or would you rather use something like B (navigation borders take over)?

[nchevobbe]

Great work Florens!

For navigation message I really like B, as it stands out from the other messages, which is what we want.

[DPX-designer]

@fvsch Your initial 3 points and your suggestions to overcome them seem well considered and logical to me 👍 Having errors/warnings take precedence aligns with my hierarchy of message importance which is why image A felt like a good balance to me.

It's tricky to determine whether something stands out adequately given the 100 billion combiniations of console output 😆 but even when the Navigation messages are sandwiched between two red errors, that crisp blue globe icon still stands out (for me at least).

Perhaps I am not aware of the true importance of the Navigation message and its position in the hierarchy, B certainly frames them with a greater importance and if they need to take front and center then B succeeds in doing that.

[violasong]

I like A/C best, and agree with @mcroud that maybe there's some importance to the navigation message that I'm not fully groking. I think B just looks a bit too strong, since we don't currently use that bright outline look anywhere - maybe C works as a middle ground?

[violasong]

Oh, what if B, but with the lighter blue outline colors of C?

If it needs more prominence beyond that, there's other things we could try with bolding, etc

[digitarald]

Navigation message

Important to keep in mind that a) they act more as separators than actual messages and b) they only show up for a subset of users that enable Persist Logs.

[fvsch]

This landed in Firefox 68 (beta).