878519 - Hard to skim console output

Status: RESOLVED DUPLICATE of bug 1519904

(DevTools :: Console, enhancement, P3)

Description

[Heather Arthur [:harth]]

Attachment: Screenshot of Console output that is hard to grok

The console looks way better than the Error Console, but I find it takes longer to find errors I'm searching for because of the styling of the output.

I've attached a screenshot of some output I was looking at earlier. All the errors blend together.

Maybe a light grey divider line between messages is on order?

Comment 1

[Rob Campbell [:rc] (:robcee)]

We could definitely use some styling help here and are open to suggestions. Separators might be a little harsh, but what about alternating background styles? And of course, a dark theme would be excellent.

Comment 2

[Brian Grinstead [:bgrins]]

Attachment: error-comparison.png

I'd like to chime in that when there is a syntax error, and it can be hard to detect that it has happened until looking closely.  For me, this is super common (maybe from missing a comma between properties object props, forgetting to close a bracket, etc), and I really like when that simple issue jumps out at me.  Maybe just printing JS errors in red could help with this?  Turning off net logs by default would also make it easier to find (this screenshot was taken on a brand new profile), though I still think that making errors stand out visually with text color would be very helpful.

Comment 3

[Mihai Sucan [:msucan]]

(In reply to Brian Grinstead [:bgrins] from comment #2)
> Created attachment 8374374 [details]
> error-comparison.png
> 
> I'd like to chime in that when there is a syntax error, and it can be hard
> to detect that it has happened until looking closely.  For me, this is super
> common (maybe from missing a comma between properties object props,
> forgetting to close a bracket, etc), and I really like when that simple
> issue jumps out at me.  Maybe just printing JS errors in red could help with
> this?  Turning off net logs by default would also make it easier to find
> (this screenshot was taken on a brand new profile), though I still think
> that making errors stand out visually with text color would be very helpful.

Yep, I also vote for changing the text color of errors to red.

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Maybe this could be a good first bug to tweak the styling?

Comment 5

[Mihai Sucan [:msucan]]

Yes

Comment 6

[Siddartha L K [:siddu]]

I would like to assigned to this bug, could someone assign me please.

Comment 7

[Mihai Sucan [:msucan]]

Sorry, currently I'm unable to mentor any bugs, due to health reasons. Please ping someone else on irc in #devtools - colleagues will be able to answer any questions you have.

Comment 8

[tejdeepg]

Would like to pick up this bug if siddu is not working on this.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

I think it's safe to start working on this bug, it's been a while without any updates. Nowadays we don't usually assign bugs before a patch is actually submitted.

Comment 10

[Sebastian Zartner [:sebo]]

I've unassigned this bug now, as Siddartha didn't work on this.

Sebastian

Comment 11

[Sebastian Zartner [:sebo]]

Could we use this bug to make all the changes mentioned by ntim in bug 1269730 comment 3? Those are:

- color-coding info messages in blue
- separating messages (either by separators like in the Rules side panel or by altering colors like in the Computed side panel)
- make the icons bigger

@Panos: According to comment 4 and 5 I've marked this as a good first bug and assigned you as mentor. Please reassign if you can't mentor this.

Sebastian

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

I'm not a good person for this kind of thing these days.

Comment 13

[Nicolas Chevobbe [:nchevobbe]]

Hello Sebastian,

> color-coding info messages in blue

what do you mean ?

> separating messages (either by separators like in the Rules side panel or by altering colors like in the Computed side panel)

Maybe light separators could help

> make the icons bigger

Mhh, not sure about what that would provide. Icons are pretty distinct in shapes and color. However I know Victoria wanted to see if we can use another icon for error messages.

Victoria what do you think of this ?

Comment 14

[Victoria Wang [:victoria]]

I'm fine with making the icons being about 1px bigger on each side (any more and it seems like it would look unbalanced with the text). 

Re: new icon for error - yes, it would be nice to use Photon's circular error icon to help distinguish from warnings (for low-color vision) https://design.firefox.com/photon/patterns/errors.html (Talking to UX and will try to find the actual SVG for this)

I would try to avoid adding separators or alternating colors as they can result in more visual clutte - some of these problems they solve can be more nicely fixed with better use of whitespace. However, I'd be happy to look at any screenshots that show a need for more separation.

Comment 15

[Sebastian Zartner [:sebo]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #13)
> Hello Sebastian,
> 
> > color-coding info messages in blue
> 
> what do you mean ?

The messages output by console.info() should have a blue background and icon. See how Firebug did that at https://bugzilla.mozilla.org/attachment.cgi?id=8811629.

> Maybe light separators could help
> 
> > make the icons bigger
> 
> Mhh, not sure about what that would provide. Icons are pretty distinct in
> shapes and color. However I know Victoria wanted to see if we can use
> another icon for error messages.

Currently, the icons are barely recognizable due to their small size.

(In reply to Victoria Wang [:victoria] from comment #14)
> I'm fine with making the icons being about 1px bigger on each side (any more
> and it seems like it would look unbalanced with the text). 
> 
> Re: new icon for error - yes, it would be nice to use Photon's circular
> error icon to help distinguish from warnings (for low-color vision)
> https://design.firefox.com/photon/patterns/errors.html (Talking to UX and
> will try to find the actual SVG for this)

+1 on that for better distinction and for being consistent with other parts of Firefox' UI.

> I would try to avoid adding separators or alternating colors as they can
> result in more visual clutte - some of these problems they solve can be more
> nicely fixed with better use of whitespace. However, I'd be happy to look at
> any screenshots that show a need for more separation.

Try this:
data:text/html,<script>console.log("foo");console.log("foo\nbar");console.log("foo");console.log("foo");console.error("foo");console.log("foo");console.warn("foo");console.info("foo");console.log("foo");<%2Fscript>

You'll see that the messages have few space between each other, making it hard to differentiate them. This is especially visible around the message with line break.
Separators or altering colors may add visual clutter if their colors are too strong, though they improve the separation of messages/recognition of which parts belong to a message and make the UI consistent to other parts of the DevTools.
Again, see the Screenshot of Firebug linked above and the Inspector's side panels, the Style Editor side panels, and Performance, Memory, Network, and Storage panels. All use either altering colors or separator lines. (Would be great if they were consistent, though that's another issue.)

Sebastian

Comment 16

[Victoria Wang [:victoria]]

For the round error icon, I discovered that we're supposed to use the info icon flipped upside down :D https://design.firefox.com/icons/viewer/#identity

> The messages output by console.info() should have a blue background and
> icon. See how Firebug did that at
> https://bugzilla.mozilla.org/attachment.cgi?id=8811629.

Seems reasonable to do something similar, but I wonder if info messages are important enough to be called out with their own background color, or if the icon be enough. I'll defer to Nicolas on this. (I'm starting to incorporate info icons in other places like this gray Async message. https://mozilla.invisionapp.com/share/FSK0MSH45DJ#/screens )(In reply to Sebastian Zartner [:sebo] from comment #15)

> Try this:
> data:text/html,<script>console.log("foo");console.log("foo\nbar");console.
> log("foo");console.log("foo");console.error("foo");console.log("foo");
> console.warn("foo");console.info("foo");console.log("foo");<%2Fscript>
> 
> You'll see that the messages have few space between each other, making it
> hard to differentiate them. This is especially visible around the message
> with line break.

Thanks for this example. I looked at this and I can see what you mean, but given that each message is on its own line, it has an intrinsic separation that I think works well. My preference for improving the viewing/expanding experience is bringing back a hover state for the rows that can be clicked on to expand. I'd like us to try that first and see how it goes before considering adding other visual elements.

Comment 17

[Sebastian Zartner [:sebo]]

(In reply to Victoria Wang [:victoria] from comment #16)
> For the round error icon, I discovered that we're supposed to use the info
> icon flipped upside down :D https://design.firefox.com/icons/viewer/#identity
> 
> > The messages output by console.info() should have a blue background and
> > icon. See how Firebug did that at
> > https://bugzilla.mozilla.org/attachment.cgi?id=8811629.
> 
> Seems reasonable to do something similar, but I wonder if info messages are
> important enough to be called out with their own background color, or if the
> icon be enough. I'll defer to Nicolas on this.

Ok, so I set the appropriate need-info flag.

> (I'm starting to incorporate
> info icons in other places like this gray Async message.
> https://mozilla.invisionapp.com/share/FSK0MSH45DJ#/screens )(In reply to
> Sebastian Zartner [:sebo] from comment #15)

Great idea!

> My preference for improving the viewing/expanding
> experience is bringing back a hover state for the rows that can be clicked
> on to expand. I'd like us to try that first and see how it goes before
> considering adding other visual elements.

That's also something I had in mind but forgot to mention. I agree with you, let's try that first.

Comment 18

[Nicolas Chevobbe [:nchevobbe]]

I would be against colored-background console.info for 2 reasons: 
- it would make them stands up from console.log and console.debug messages, which seems a bit wrong since we kinda have this "levels" going error > warning > log > info > debug
- it's very difficult to have background work with every other elements you can log (numbers, strings, object, urls) and with the elements on a message (timestamp, icon, location), even more when you think of dark mode.

A nice icon should be enough I think.

Regarding message separation, we already have the blue border on hover at inline-start, and maybe it would be worth to also have it an inline-end so you can match the message content and its location more easily ?

Comment 19

[Sebastian Zartner [:sebo]]

Attachment: console.info() message with blue background

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #18)
> I would be against colored-background console.info for 2 reasons: 
> - it would make them stands up from console.log and console.debug messages,
> which seems a bit wrong since we kinda have this "levels" going error >
> warning > log > info > debug

Is that internally handled that way? Because my understanding of the levels is error > warning > info > log > debug.

> - it's very difficult to have background work with every other elements you
> can log (numbers, strings, object, urls) and with the elements on a message
> (timestamp, icon, location), even more when you think of dark mode.

It's fairly easy when you use a subtle color like for warnings and errors. I've attached a mockup for how this would look like.

> Regarding message separation, we already have the blue border on hover at
> inline-start, and maybe it would be worth to also have it an inline-end so
> you can match the message content and its location more easily ?

This would allow to scan the line faster, yes. Though highlighting the whole line makes it even easier for the eye to recognize what's part of the line. And my other point here was also to make the highlighting between the panels more consistent.

Sebastian

Comment 20

[Victoria Wang [:victoria]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #18)
> Regarding message separation, we already have the blue border on hover at
> inline-start, and maybe it would be worth to also have it an inline-end so
> you can match the message content and its location more easily ?

I think the chunky blue border looks best as a one-sided highlight. For line background, I was thinking we could color just one row at a time (so not entire expanded trees). We could use Inspector's blue hover on white rows, and I could come up with new hover colors for the red/yellow rows. I realize this might be tricky though because of how the console rows inside expandable trees aren't 100% in width.

Comment 21

[Joan]

I would like to work on this or help out if possible.
Thanks,
Cheryl.

Comment 22

[:Harald Kirschner :digitarald]

It doesn't look like we have agreement on UX. This is also an area where UR can help validate mock-ups and prototype.

I'll remove the good-first-bug for now. If people are interested in contributing prototypes for ideas, please feel free to step up.

Comment 23

[Victoria Wang [:victoria]]

Ah yes, I was starting to talk to Nicolas about my idea for this at all-hands: Any row that is expandable/closable could benefit from having a single row hover effect of 100%-width light-blue background (same as Inspector). It's not high priority but it could help with reading and navigating lines inside a big complicated object that already has the left-border styling on the entire object.

Comment 24

[Nicolas Chevobbe [:nchevobbe]]

Not sure what would be left to do after Bug 1519904, but not closing yet so we can check again once we have the borders.

Comment 25

[Nicolas Chevobbe [:nchevobbe]]

Closing as dupe of Bug 1519904.