It's hard to differentiate between console.log() and our print statements

[jonbell-lot23]

The issue

We have this moment in our onboarding experience* where we triumphantly say "Check the console" but ... it's hard to know what we're referring to:

** Not just an onboarding issue!*

It would be tempting to say the onboarding experience just needs a tweak for this one scenario, but there's a larger issue at play here. Some items in the console are generated directly from the code, whereas other items (like our print statements) are separate. We don't lose much by calling attention to our print statement output, but we can gain a lot.

Proposal

It's possible that a super light background row color is enough to experiment with. Not just for the onboarding experience, but overall as a way to help our print statements stand out. We spent weeks and weeks making sure our print statements were delightful and obvious, and I think this little tweak could help a lot.

[jonbell-lot23]

Update:

Rather than going with a super light red as shown above, we're going to make this a yellow flash that fades away after a few moments. Removing needs-design and moving to design-discussion, also moving to April.

[jaril]

On second thought, the yellow flash has limited value in solving the differentiation between native and replay print statements.

• It's temporary, so the differentiation only exists for the first few seconds that it appears in the console.
• It may be hidden in the case that the new message is not displayed in the scroll container

I think if we were to solve this we need something more permanent indicator (e.g. background color/symbol/something) that allows the user to, at a glance, distinguish between the two.

[jasonLaster]

I wonder what the user value of differentiating between print statements added in Replay or in the original code. For example, what if we went the other way and made them more similar. e.g. users could edit or disable console code console.logs?

Moving to a discussion to get more folks opinions.

[markerikson]

I actually would find it very useful to visually distinguish / filter between "stuff I'm logging as I'm debugging" and "this is the original output of the app".

If it's a print statement I added, then it's almost definitely something I am very concerned with as I'm trying to understand the behavior of the app and debug it. On the flip side, the original console output of the app could easily be irrelevant to whatever it is I'm trying to work on.

[jonbell-lot23]

Agree. There are two use cases where this is obvious:

1. Onboarding, where we say "check the console!" and there's no way to see what we're referring to.

2. When I'm poking around and it's important for me to see the results of the thing I just did.

From me to BrianV to Jaril to Mark to customers, I've never heard someone express concern that their changes might be too visible. On the contrary, I hear this request frequently and I think I've only heard one person express concerns about it ;)

[jonbell-lot23]

(That said, going the reverse order as Jason mentioned is worth considering. But I see it as a separate topic. First, items added into a potential wall of content need to stand out. Separately, the ability to edit them is intriguing, but should be their own discussion point, independent of this one.)

[jonbell-lot23]

I've created a discussion for the question that Jason brought up around editing console messages directly. It's provocative, I like it! #6313

[jonbell-lot23]

The original intention of this task (looking into highlighting rows) is part of my broader onboarding audit, and has been well discussed. The next step is to put something together for the team to react to. The ticket is here: https://github.com/RecordReplay/devtools/issues/6314