Right now, the stepper takes the code from the definition windows and displays it in a different window, with a different color, with a different layout, with some brackets turned into parenthesis, and with the comments are removed. I just opened a simple solution from last semester and launched the stepper on it. It took me no less than 20 seconds to trace the first redex presented by the stepper to the expression in the definition window it came from. It's really hard to do!
When using the stepper, students struggle to see the correspondence between what's on the left and what's on the right, despite the colored highlights and all that. In my experience, the correspondence has to be carefully pointed out to them by the instructor. Their understanding of the correspondence between the content of the stepper window and the code they wrote in the definition window must be fainter still. There has to be an easy way to establish these two correspondences: from pre-step to post-step, and from the stepper window to the definition window. None of the proposals posted to in this thread so far address this. I can think of many different ways to make the stepper<->definition correspondence manifest. As John said, I once suggested that the code should be reduced in-place, in the definition window. Shriram doesn't like that idea (but he has never bothered to say why.) Another possibility is to use a two column layout. The left column would show the normal definition window, and the right column would show a single stepper state, aligning each reduced (or partially reduced) expression with the expression it came from on the left-hand side. To establish the pre<->post correspondence, the redex should disappear and its reduction be put in its place (with the rest of the code sliding downward smoothly to make space if necessary.) > It's not clear how you want to handle test cases; they don't > currently generate anything in the interactions window, and yet this > sounds like the thing that you're *most* likely to want to be able to > step. Yes. > the result of "generate-report" (the hidden summary-generation call > that check-expect inserts) should be a snip that shows up in the > interactions window, called (e.g.) "Test Report". Clicking on this > (right-clicking on this?) should open a window showing the test cases > in some tabular format, indicating which ones succeeded and which > ones failed. Selecting one of these, the user could choose to see > its steps. That's too many clicks. Every click the student has to do is a click they may fail to do successfully. In my observations, most students fail to click on the blue links that appear in the test result window. Those who do click the link then fail to click back to the definition window. Clicks are expensive; our interfaces should strive to minimize them as much as possible. See also: Aza Raskin's presentation "Don't Make Me Click" http://www.cheaprevolution.com/the_cheap_revolution/2008/10/dont-make-me-click.html and Aza's blog post on how to critique an interface. http://www.azarask.in/blog/post/how-to-critique-an-interface/ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
