Support static mode

[sofian]

NOTE: This feature request was imported from P5.js

The P5.js editor does not currently support "static" mode which allows sketches that do not contain functions setup() and draw() to work.

Static mode is an interesting feature when introducing students to Processing. I wonder if it would even be possible to make it work but I'd be happy to give it a try if this is something others believe would be a benefit.

I personally feel it makes many students feel like it is an empowering feature tof Processing especially for beginners, as it allows to build confidence early on. I usually begin my classes with an empty sketch and show them that this still produces a gray-background canvas, and we build from there.

[catarak]

Thanks for submitting this! I don't have a strong opinion about this, and could be convinced either way, so I'm curious for more input.

[sofian]

In general, one point in favor of it is simply that it would more adequately match the "java" version of Processing. I also believe the IDE (and not the library) is the right place to implement this.

[limzykenneth]

I quite like this idea, however, it would mean that there will be a difference between code written in the editor vs code written in the user's own text editor (ie. if you copy a static mode code from the web editor into a custom setup project in your own text editor it will fail).

This works for Processing because Processing's users will probably be using the editor as the code actually written are significantly pared down from actual fully compiler friendly Java and the compiling stage are also taken cared of. I feel p5.js does less out of the box being just a library itself and just some "magic" to make global mode possible.

That's what I think anyway, whether it is that much of a concern for the users, much can still be said.

[sofian]

Yes this is the main drawback. No intermediate user really uses static mode, it is really more of an educational feature to introduce students to coding. So I believe that by the point users start using p5.js as a library outside of the IDE, they will be advanced enough to not use the static mode anymore, and it will be fine to just point out that static mode is not going to work in that context.

[catarak]

I was looking at this https://github.com/processing/p5.js/wiki/Frequently-Asked-Questions#why-cant-i-assign-variables-using-p5-functions-and-variables-before-setup today, which made me lean towards not including a static mode (or static mode being fairly low priority), but instead explicitly including p5 outside of setup or draw:

new p5();
print(random());

I think another option would be to explicitly have a 'static mode' in the editor which could be turned on by a preference option, but i wouldn't want static mode to be turned on implicitly.

[francisli]

Repeating my comments from the pull request (#488) in case it doesn't get propagated to the folks on this issue thread:

I, too, am interested in having the equivalent of Processing's "static mode" for a workshop geared towards elementary school students. Although it seems like a minor and limited feature, I've always felt that it was a keen insight of the original Processing- to completely remove any distractions from the first interaction, giving students that blank slate/sheet of paper to draw upon incrementally.

This is obviously a somewhat frail implementation of it, but it does work, and it would probably work in the majority of workshop/classroom settings. If you rename the initial js file from sketch.js to something else it will break (of course, it will break your project regardless unless you know how to also modify the html file script reference). Having multiple files can also break, depending on how they are used (this is why the original Processing PDE concatenates the content from all of its .pde file "tabs" into a single source file before pre-processing).

So, I think by the time you're ready to let students open up the side tab, and start manipulating the project files, you've probably gotten far enough that they've learned function declarations and started using setup() and draw()...

[sofian]

@francisli Thanks.

[sofian]

@catarak The option to include a 'static mode' in the editor is a good one : to make it explicit also makes it more clear. I also believe it should be "off" by default -- although (maybe) it could be interesting to overcome that in the URL eg. https://editor.p5js.org?static or https://editor.p5js.org/static or https://static.editor.p5js.org would set the default to be static so that you don't have to ask beginners to perform an extra step.

[francisli]

@sofian @catarak I've just updated my PR to make this static mode implementation an environment variable setting, for your consideration. If the environment variable is not defined or otherwise not set to 'true', then the editor will be in its original implementation. If STATIC_MODE_ENABLED=true is set in the environment, then the default sketch will be empty, and the handler for the code will be enabled.

FYI, I've been using this implementation in elementary school classrooms (3rd grade last year and now 3rd and 4th grade this year), with great success. It really is far less intimidating and a big difference to be able to just jump in to an empty file and have that clean blank slate and not have to answer any questions about the default sketch code or try to explain it.

[shiffman]

I'm really enjoying this discussion! This is such a tricky one that we have gone around and around on with p5.js since the beginning! One thought is that if we do decide to include support for a "static" mode that maybe we alter the code if the user selects "download" to wrap everything in function setup() {}? Could also even crazily provide a warning if the user does select all and copy? With Processing, whenever the code was "exported" to Java it included all the boilerplate wrapper stuff that the PDE itself would hide.

[catarak]

would it make sense for this to be a sketch preference? the way this is handled in other in browser text editors is a "template". or maybe, when a user is creating a new sketch, they could select the type of new sketch? i think using an environment variable is a solution that works, but in the case of editor.p5js.org, it would be propagated to all registered users.

[francisli]

@catarak @shiffman so, the way this is implemented in the editor is exactly how you describe- I check if a function setup() has been defined in the main sketch.js file, and if not, I wrap all the code into the setup function JUST before it is injected into the preview. I can look in to doing this for download as well, but I'm wondering if maybe we're going too far into the weeds for this as an edge case...? I made it an environment variable setting because it seems like, due to the issues around exporting/supporting this code outside of the editor, it doesn't seem like it should be the default behavior.

Rather, it seems like this will probably only be used in specific contexts, like with our organization which is hosting our own instance of the editor specifically for our elementary school classroom workshops. With the Heroku deployment configuration we use in #762, it's a one-click process to deploy your own instance, and if this gets merged in, I'll add this setting to the config so you can even just flip the switch on the environment variable in the Heroku deployment UI. And since we're in the classroom environment and quite a long ways away from them creating and hosting their own websites and sketches, I'm not as concerned about the download/export capabilities...

Finally, I really don't want to have to deal with this as a UI setting in preferences or when creating a new sketch (how would it choose for the default generated sketch anyway?)- it just adds more unnecessary complexity to the process for the kids- not that they can't figure it out, but they're inquisitive and want to know why you do each thing, and I want to save that curiosity for the coding itself and not UI settings and switches. Again, it is a simple but powerful insight that the original Processing team had that the moment you open the editor, you just get put into a blank sketch- no fiddling, no configuration, just a clean slate to start experimenting with code, and I really want to preserve that...

[catarak]

@francisli i hear you! i'm just trying to figure out what would make sense for other folks in the same position as you. given that this feature is only turned on with an environment variable, i think it would be okay to merge in your PR for now, but to me it does not feel like a long term solution, though i'm not sure what that looks like.

[catarak]

just an update, i'm having a hard time making a decision about this. i don't think that static mode should be turned on implicitly in the web editor, because p5.js is used in so many contexts outside of the web editor. whereas with processing, 99% of folks use the processing ide. my worry is teaching folks how to do something "the wrong way" and then having to unlearn it. maybe this is not as bad as i think it is.

i do see the value of static mode and no distractions, but i'm not sure how to implement it. i could see a world in which we include the line new p5(); by default in a script tag in the index.html, but i also see how this could be confusing.

[francisli]

My sense is that by the time someone is interested/capable of bringing their sketches outside the editor into their own hosted websites, they will have long progressed past static mode and understand and know about the setup() and draw() functions. Remember that you can't do any animation or interaction in static mode, so it really is only going to be for the earliest stages of learning.

[sofian]

Happy to see this discussion being resurrected.

I also believe that given that the static mode is really just for the first few steps that students/learners take into the environment I do not see any harm in making it an option only in the editor. None of these static mode programs are even shared over the internet, I think most people really use them only as an educational device for the first 30 minutes of class: and yet these minutes count a lot for people who are doubtful of their coding skills and often even afraid of coding -- it's all about first impressions!

Static mode builds confidence cause it removes all the unnecessary stuff that they do not need at that point (setup(), draw(), function, and brackets {}) and focuses their attention on the important things. After they see that they are able to code simple things and that they understand the relationship between what they type and what happens on the screen, it is easier to move to the next step.

[catarak]

hey y'all, i talked through this issue with @shiffman and @lmccart and i wanted to explain where we're at.

i feel strongly that it's a bad idea to implicitly transform the sketch to use static mode, because then, later on, a user has to learn that p5.js/javascript doesn't "normally" work like this. maybe this seems like a relatively easy thing to unlearn, but i think it's important that there is no unlearning, even small stuff. i think of the web editor as a tool to abstract as much stuff as possible, and then create a runway to slowly un-abstract concepts. this ties into a goal of p5.js, to teach programming concepts with programming syntax, and not just programming concepts (compare to a tool like Scratch).

i'm open to exploring what static mode would look like, explicitly, i.e. the default sketch gets added the line new p5() at the top. since the official p5.js examples tutorials don't do this, it could be confusing, or at least just inconsistent. this means it could be a preference option, which isn't great as discussed above. or something else, but i don't know what this looks like.

one thing to think about is that p5.js itself was designed this way to support global and instance mode. because of how web pages are loaded, it's not possible to do it another way.

i hope this makes sense. to summarize, i think that implicit static mode is not a good idea, and i think that explicit static mode points to design decisions about p5.js and its examples that have been previously made.

[francisli]

@catarak so the current implementation in the PR has it disabled by default- it can only be enabled with an environment variable. Is that acceptable for you to still merge in, or is the plan to decline it in favor of future explorations?

[catarak]

i was just commenting on the PR—will answer there!