processing / Processing-Hour-Of-Code

Repository for an interactive one-hour Processing tutorial.
hello.processing.org
56 stars 14 forks source link

Language and Script #10

Closed REAS closed 11 years ago

REAS commented 11 years ago

I'm starting to think about how we speak to the students. Dan will be speaking, so I think it's largely up to him, but I have some questions about how the video relates to the interface and pacing. For example, will Dan say things like:

"Start with the code below and try to draw the outlined shape to the left. Try different colors and positions for the circles. You can skip to the next lesson any time. We'll remind you that it's time to move on after 10 minutes."

"Press the 'hint' button for a suggestion about how to take the next step."

Will Dan give a lesson for 5 minutes, then the students have 5 minutes to try it out? Or will it be more continuous where he says, "Now try typing color(102)" and then pauses for about 10 seconds for that to happen.

They way the window is three panels makes more possible than the original idea of a full-screen video that is replaced back and forth by an editor.

REAS commented 11 years ago

Maybe we acknowledge that it's an hour tutorial at the start and let people know when they click the Play button on the welcome screen, for example, the time starts. We can use the menu bar at the top literally as a timeline and we can have a Play/Pause button at the top in the menu so people can stop if they want to take a break etc. But if people don't pause, the website starts and tops the videos at the hour-long pace and the progress is very clear at the top as a line moves from left to right. Thoughts?

shiffman commented 11 years ago

Scott and I just had a conversation about some of these questions in person. Here are some ideas:

  1. Tutorial starts with fullscreen video introducing everything.
  2. Video shrinks and code editor appears.
  3. I talk about general concepts using a whiteboard. Then I make some mentions about what code they are seeing below and what they are seeing in the canvas on the left. Everything is timed with popcorn.
  4. I give them little exercises and wait in the video (they can always pause).
  5. At some point, the video ends and they get a longer chunk to try stuff out before the video starts again.
  6. repeat

While we ultimately want polished / edited videos, Scott and I agreed that I should make "test" videos using my lesson recording systems so we can evaluate the "script" and see how the timing works. I'm going to make one later this week or early next week.

A goal I will attempt -- I will never show a computer screen in my videos (introduction excepted), I will only talk and diagram. All code and running code will appear in the browser popcorn-style.

I like the idea of shooting the final videos outside in the park, if that's not too crazy.

REAS commented 11 years ago

I'll digest this and think, but I'm commenting now to thumbs up the video in the park. With a whiteboard. I love the idea. When the time comes, I'll do all of my videos at the beach.

REAS commented 11 years ago

For some reason, the idea of you speaking to the imagined student has reminded me of these: https://vimeo.com/18531550 https://vimeo.com/18533401

scotthmurray commented 11 years ago

All these ideas are great.

Dan, when the code editor appears, would the canvas/output panel also appear at the same time? I could see that working well, but I could also argue for revealing only one thing at a time — so maybe the editor panel appears, then you talk about writing code, etc. Then the output panel appears only later, say when it's time for the first exercise (or when, in the video, you explain how this code --> images).

If shooting outside in the park is too crazy, you could green-screen it and at least pretend you are outside. (Just don't use a green dry erase marker.)

scottgarner commented 11 years ago

Bringing the conversation back over here. I did a Popcorn test with Dan's video:

http://hello.processing.org/editor/

Some thoughts:

1) I think Dan should show and run his code before asking for edits. Maybe the run button isn't even introduced until it is the user's turn. Right now the very first code run could throw an error from user input and that seems problematic.

2) Two editors seems like too much unless it's just a single editor with two visually distinct modes—sometimes it belongs to Dan and sometimes to the user.

3) Going off Scott's suggestion, maybe every new "your turn" session begins with the option to start with your previous code or to start with Dan's code.

shiffman commented 11 years ago

I like the idea of 3 above, I think this could work. My concern is that if the user reverts to his/her previous code then the "new" example code lost for reference. For example, what if the user has to type setup() and draw() for the next step, and can't recall how to do it once they have their old code back? Perhaps the solution is, as we've said before, to replace the video area with hints/reminders/reference etc.

shiffman commented 11 years ago

Closing this issue and moving my most recent comment to a different issue. This discussion has split into a bunch of different topics / discussions that have been solved or are referenced in other issues.