Freecodecamp: Beta: preview panel covered by flash message

[moT01]

When going through the challenges, the JavaScript is disabled. Execute code to enable flash message constantly shows up in the preview panel covering the preview itself. There's no way to close it - it doesn't fade out. It's really annoying, and it's pretty much on every challenge that shows the preview.

---

---

Potential solutions:

Add the ability to close the message.
Fade it out after a second or so.
Push the preview content down.

---

It looks like something related to this was recently worked on #16804

[bennettnw2]

I second this. It is quite annoying to have that block your preview all the time

[vkWeb]

@moT01 Ya - It's annoying when you constantly need to look at the preview. I think we should display this message in challenge log.
Something like this:

What do you say @Bouncey, @QuincyLarson?

[Bouncey]

@raisedadead @QuincyLarson @BerkeleyTrue, what are we trying to communicate with the flash? I don't remember any UX issue with respect to this from production?

[raisedadead]

This is same as https://github.com/freeCodeCamp/freeCodeCamp/issues/16565 being worked upon. The flash, I believe was placed as an interim solution for a better locking mechanism, which we are planning to hopefully get away with in the linked issue.

[bennettnw2]

@raisedadead Thanks for looking into this for us. I'm a total newbie so please forgive my ignorance but it seems what #16565 references is not related to this. I think it is more closely related to #16804. The locking mechanism is fine. We just want the notification of the locking to not block the preview pane. Thanks again!

[raisedadead]

Hi @bennettnw2 thanks, well I explain how this is related:

1. The code locking is so that we are able to lock any code that was not written by the user in the editor.
2. As a result, UI wise two things are notably displayed, the first is the button label in the issue which I linked and the second is the flash message as being discussed in this thread.
3. Now, these are there for the lack of better alternates during the initial development, of our new platform.

So far we have had discussions, to make this UX as friction-less to the users as possible.

To the best of my knowledge @tchaffee is doing some work to detect this for certain specific use cases (which I agree are not going to be there that often).

Until we come up with a fix, that enhances this requirement, I am afraid this is an inconvenience.

Hope this clarifies the issue?

[moT01]

@raisedadead it doesn't quite clarify it for me - this issue is specifically addressing the fact that the flash message is in the way - are you saying we are just stuck with it being in the way? Or are you saying that it might be moved or removed once he comes up with a solution for that issue?

[raisedadead]

Yes, it will be removed once we have a way to display it only for very specific use cases (rare cases).

[BerkeleyTrue]

That specific message is to indicate to the user that no js is running in the preview window. This is prevent uncompleted js code from crashing the preview window while the user is writing out their code (fun fact, writing "function" to an iframe script tag used to crash the client). When I originally wrote that flash message it was a simple span tag with text that rendered in the preview window but above (top not z) the user content.

This seems to be a bug introduced downstream when styling was applied to the message. Changing the styling is fine but we shouldn't be removing the message. This is not licked to code locking. This happens on every keystroke pause and is disabled on code execute

[raisedadead]

Ah thanks @BerkeleyTrue I had a misunderstanding that this is tied to locking.

So, the effective solution is an alternative text in the message, to clarify the intent.

[BerkeleyTrue]

@raisedadead yeah, if it is desired, but the issue is the styling should not cause the flash message to float over the preview content, which seems to be the main complaint.

@Bouncey didn't you have a PR recently that changed the styling on the preview window? Could that be the cause?

[moT01]

@BerkeleyTrue yes, in my original post the other issue that is linked has a reference from that PR it at the bottom. -- I'm pretty sure before that merge the content of the preview was just getting pushed down by the message. I still vote to remove the message

[QuincyLarson]

I also vote to remove the message, and code locking in almost all cases except the one discussed on https://github.com/freeCodeCamp/freeCodeCamp/issues/16565

[tchaffee]

One way to look at this is to ask what bad would happen if we just removed the flash message? Knowing the answer to that will help figure out the best UX.

I think the code locking is mostly unrelated to this even if they feel similar. Confirmed that I'm working on that.

[QuincyLarson]

@tchaffee The risk is that people don't realize why their code hasn't loaded and assume there's a bug.

We didn't want to run the code when the challenge loaded for the following reasons:

1. There could be an infinite loop in the code, which would cause the page to crash
2. If they followed a link to view someone else's code on freeCodeCamp, that code could be malicious, and if they they wouldn't get a chance to inspect the code before it ran.

@BerkeleyTrue were there other reasons we didn't want to auto-run the code?

I feel like we could always just load and run the challenge's default code and that would be OK.

Currently if there's a solution in local storage, it says "I found a previous solved solution. Loading now." This instead could say "You previously wrote code for this lesson. Would you like to load it? [Load it.]"

Then they would be opting in to running their own code (and could thus dodge a /noprotect infinite loop if there was one.

[tchaffee]

The risk is that people don't realize why their code hasn't loaded and assume there's a bug.

That's helpful. My next question is how big is the risk? Is this happening often? Were folks coming to the forums with this complaint and so we put this in because the risk was not just theorized about, but a real risk?

I'm going to guess it's not a real risk because of the following UX:

• The first challenges are HTML and CSS and there's no JS in that. The HTML automatically refreshes in preview window, so they get used to seeing the preview refresh as they type. Which causes the expectation for JS to be the same. BUT:

• The next challenges are JS and there is no preview pane. So the micro-behavior they are learning during the JS challenges is that when they are working with JS they have to click the "Run Tests" button to see any output.

• By the time they get to the first challenges that have a preview pane and JS (which would be jQuery), they already have it down as a regular habit to click "Run Tests" in order to see JS output.

My guess is that most people will just get it.

I think it would be worth it to ditch the flash warning altogether and see if any users come to the forum with this complaint. Or to use analytics to see if there is a sudden dropoff of users when they they get to the jQuery section or any other section that requires them to click "Run Tests" to see the preview.

The above reasoning aligns well with the YAGNI principal from extreme programming (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it).

I feel like we could always just load and run the challenge's default code and that would be OK.

I think we should be consistent and either always load JS without clicking, or never run it without a click. Consistent and simple behavior is always easier to explain to users.

Because of the below from @BerkeleyTrue, it seems like always loading without a click is risky:

This is prevent uncompleted js code from crashing the preview window while the user is writing out their code (fun fact, writing "function" to an iframe script tag used to crash the client).

Putting it all together with the other issue about running code from a URI the behavior would be.

1. All JS requires you to click the "Run Tests" button to see any output in the preview pane or console output.
2. JS code from a URI has an additional protection in that you have to unlock the code first and then click the "Run Tests" button.

That's it. Very simple and easy to explain to users.

[QuincyLarson]

@tchaffee We have had real complaints around this, but I hadn't considered one of your points before.

I suspect you're correct that since we have moved JavaScript completely out of the first certificate, campers should get used to the fact that they have to click a button to run the JavaScript.

If we still get complaints about this post-launch, we can figure out a better way of reinforcing that the JavaScript isn't running.

So I'm also in favor of going ahead and removing the notice. Please go ahead and do this.

[tchaffee]

Please go ahead and do this.

I'll give it a shot. I should have a PR soon.

[tchaffee]

@QuincyLarson @BerkeleyTrue @raisedadead @Bouncey
I'm ready to submit a PR for this but I'm getting errors from npm test. I put more details over on gitter if someone can help out.