Pause button
Add a “pause” button which stops recompilation/error checking as you type.
For what it’s worth, I’m skeptical of this idea—the “auto-run JavaScript” feature of JS Bin is very confusing for students in my experience, and I’d rather tackle problems with automatic compilation (e.g. alert(), infinite loops) directly (which we have for both of the aforementioned examples)
I think a pause button would be tremendously helpful. I'd actually go further and suggest that "auto recompilation" should be turned off by default. I feel auto-recompilation leads to a distracting first-time user experience. As soon as the student types <p the UI goes yellow (confusion) then red (sadness). Often times, the student then bashfully deletes the line they wrote. At this point, a volunteer usually has to steps in and say, "no, no, you were on the right track". This feels unnecessarily discouraging, imo.
A similar experience occurs when learning out html attributes and css selectors. The student types <a href=" or p { and the confusion/sadness cycle occurs.
I feel an explicit "Reload" button would help smooth these interactions and introduces students a standard industry term, "Reload the page".
@xavi- really appreciate the thoughtful feedback. I’m in complete agreement that the UI/UX surrounding errors in code is not great right now. The spinner is way too distracting, and it’s discouraging to see a list of errors every time you pause typing. I haven’t actually encountered the situation you describe in the classroom (students deleting a half-typed line because of an error message), but I can certainly see how it could happen.
That said, I’m deeply hesitant to change the default of automatically updating the output when the student types. My hesitation comes from experience watching students use tools like JS Bin and Cloud9, which do require manual action to update results. From my observation students tend to find this confusing and it can substantially slow down work.
I’m wondering how much of the current pain can be alleviated while still retaining the desired behavior of automatic updating. A few ideas come to mind:
- Change the spinner to something much less visually distracting. Perhaps just a semi-transparent dark overlay over the preview of the last good state of the page
- Don’t show all the error messages by default. Perhaps the above overlay could just have a chill 2 Errors message in the middle, which you can then click to expand into full error details. You’d also of course always see the inline error indicators in the editors
- Something more clever like suppressing error messages on the currently focused line in the editor (at least for a longer period of time). This might be hard behavior to get exactly right, though
One thing to note is that the spinner behavior is primarily a UX trick—the idea is to not show error messages immediately as you’re typing. There is no substantial delay before the outcome of code validation is available. The idea of the spinner is to reduce the annoyance of immediately being hit with error messages as you’re typing, but it’s not terribly effective given that students tend to type slowly and pause a lot.
I briefly played with JSBin and it seems to auto-update nowadays. Originally, was there a "reload" button? I would have thought a "reload" button would pretty natural for students since they're already familiar with reloading web pages and app.
The least invasive way of displaying errors I can think of is to use red underlines to highlight errors. Similar to how chrome or grammarly displays spelling errors. Playing with delays and cursor position may help, but, I agree, I think it'd be hard to get exactly right.
@xavi- I appreciate the feedback. Ultimately changing the auto-update behavior isn’t something I’m inclined to do right now, but I do think there‘s a lot of room to improve these pain points without making that change. It’s really helpful to know what parts of the tool are most in need of improvement. Thank you!