RunestoneInteractive / rs

A New Monorepo structure for Runestone
Other
41 stars 68 forks source link

When code is hidden, the 'Run' button is also disabled #176

Open DaveParillo opened 6 years ago

DaveParillo commented 6 years ago

An activecode block with a disabled run button is initially confusing / awkward.

To run code, students either press 'Show Code', then 'Run', or use the autorun option to run on page load.

If autorun is used, there is no way to run the example again unless the user selects show code.

bnmnetp commented 6 years ago

I think the decision to disable the run button was to discourage students from blindly running code they could not see and their own code isn't loaded until it is visible so that we don't have tons of server hits to download their history of every activecode on the page...

What use case are you thinking about where you would want them to press the run button without looking at the code?

In the example in the overview document there is a Sierpinski triangle that autoruns. On that page I can run the code again without clicking on show code.

DaveParillo commented 6 years ago

Re: download their history

Good point. I did not think about that. I don't have a grading back end or any persistence for my book, so I don't have any exposure to that.

Personally I think autorun will always result in at least 1 extra server hit for students actually interested in a given example (one they just don't gloss over). The Sierpinski example is a case in point. Because the example is below the viewable page region when I open it initially, my first urge when I get down to and see it in progress is to run it again.

So anytime you have an interesting animation that is not at the top of the page is one case.

Another use case is if the example code is long (or wide) and I don’t want the example code to interfere with the output. I could create a tab group, 1 tab with the code and another just to run the entire program.

Or simply press hide, then press run, which is not currently an option.

The float of the pre and canvas elements (mostly pre) is sometimes an issue for some examples, especially when the screen is narrow. When narrow, the pre always floats to the bottom of active code and in that case, if the goal is to simply run an example, the output might float below the screen viewport, especially on a cellphone.

When the browser is moderate width, the pre floats to the right side of the code and autosizes to a bit less than half the window width. Sometimes this makes the pre too small to accommodate on one line all the content that used fo fit on one line. The wrap is distracting. The editable code texture can be resized, but the pre cannot. One the float has determined where it’s going to put it, you’re done.