search

racket / drracket

DrRacket, IDE for Racket
http://www.racket-lang.org/
Other
452 stars 94 forks source link

Stepper should permit better navigation of steps #163

Open pnijjar opened 6 years ago

pnijjar commented 6 years ago

The other frustrating thing that I find about the Stepper is that it is so difficult to navigate to the part of the stepping we care about. I understand that the Stepper is not the full debugger, but the navigation of the debugger is much easier to use because you can easily set breakpoints and then choose to go into or over expressions.

In the Stepper, you can choose to "jump" to the next application step, but you can only do that once. I have found no way to repeat this (on 6.7, but I think 6.10 is similarly affected). Once I jump to the next application step I can only move forward one step at a time, which means it takes a long time to find the steps I actually care about. There is some functionality called "Jump to beginning of selected" but I do not know how to activate this.

I can think of a few possible solutions to this, but I do not know what is easiest to implement:

It would be nice (although not a complete solution) to be able to put breakpoint in front of a check-expect and step from that point, but my understanding is that this would be awkward to implement. Students currently take the expression out of the check-expect and put it into the definitions window, then step from there. That is an awkward workaround, but it kind of works.

Maybe this is user error and I don't know what I am doing. In that case is there documentation that could help me?

jbclements commented 6 years ago

On Nov 19, 2017, at 10:01, Paul Nijjar notifications@github.com wrote:

The other frustrating thing that I find about the Stepper is that it is so difficult to navigate to the part of the stepping we care about. I understand that the Stepper is not the full debugger, but the navigation of the debugger is much easier to use because you can easily set breakpoints and then choose to go into or over expressions.

In the Stepper, you can choose to "jump" to the next application step, but you can only do that once. I have found no way to repeat this (on 6.7, but I think 6.10 is similarly affected). Once I jump to the next application step I can only move forward one step at a time, which means it takes a long time to find the steps I actually care about. There is some functionality called "Jump to beginning of selected" but I do not know how to activate this.

I can think of a few possible solutions to this, but I do not know what is easiest to implement:

• Maybe you could make the full debugger available in the teaching languages, but that doesn't fix the Stepper itself. • Maybe you could allow the jump functionality to be applied multiple times (perhaps with a "jump" button?). I am not sure whether this would jump fast enough that users could navigate to the expressions they care about or not. • Maybe you could implement functionality to jump a particular number of steps. Maybe being able to jump by 10 steps or 50 steps (or a user defined number of steps) would help students zoom in on the step they care about faster. • Maybe you could add some kind of breakpoint functionality without reimplementing the full debugger. It would be nice (although not a complete solution) to be able to put breakpoint in front of a check-expect and step from that point, but my understanding is that this would be awkward to implement. Students currently take the expression out of the check-expect and put it into the definitions window, then step from there. That is an awkward workaround, but it kind of works.

Maybe this is user error and I don't know what I am doing. In that case is there documentation that could help me?

First off: I’m delighted that you’re using the stepper!

Second: I’m sorry that the interface is so sub-optimal!

To answer your specific question: you can jump forward by one application step as many times as you want; just select “Jump to next application step” from the pull-down menu again, and it will jump forward again. You can repeat this as many times as you like.

Also, in re: “jump to beginning of selected”; if a section of the code is selected in the definitions window, then choosing “jump to beginning of selected” should jump to a step involving that piece of code.

HOWEVER: I understand that this violates typical interface expectations; we expect selection in drop-down menus not to trigger a change, but to change the meaning of a button-click somewhere else. I think that the right solution is probably to put lots of buttons at the top of the stepper window; tooltips would be an absolute necessity, but you’d also want someone to design decent graphics for the buttons.

Let me know what your thoughts on this are.

John

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

samth commented 6 years ago

I would prefer if the drop-down changed the meaning of the existing back/forward buttons (that's what I assumed it did until very recently). While this wouldn't be compatible with people's existing use, my guess is that it would bring the actual behavior in line with most expectations, and most users of the stepper are students who would have no prior Stepper experience.

Additionally, a way to go to the "next top-level expression" and/or the "next check-expect" form would make navigation much easier. Finally, a way to hide or otherwise show somewhere else all the definitions would be great as well.

jbclements commented 6 years ago

On Nov 20, 2017, at 11:09, Sam Tobin-Hochstadt notifications@github.com wrote:

I would prefer if the drop-down changed the meaning of the existing back/forward buttons (that's what I assumed it did until very recently). While this wouldn't be compatible with people's existing use, my guess is that it would bring the actual behavior in line with most expectations, and most users of the stepper are students who would have no prior Stepper experience.

Additionally, a way to go to the "next top-level expression" and/or the "next check-expect" form would make navigation much easier. Finally, a way to hide or otherwise show somewhere else all the definitions would be great as well.

Essentially, the pull-down is actually a filter on steps. It sounds like this pull-down should be something like this:

Filter steps: ———

?

John

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

samth commented 6 years ago

Another possibility would be having two buttons, one for the current small step, and one for a selectable big step.

Additionally, the concept of "step over" from debuggers might be useful here: step over an entire function application, even if that's multiple application steps.

pnijjar commented 6 years ago

On Mon, Nov 20, 2017 at 07:03:23PM +0000, John Clements wrote:

First off: I’m delighted that you’re using the stepper!

I am mostly writing on behalf of my students. They have been struggling this term.

Second: I’m sorry that the interface is so sub-optimal!

To answer your specific question: you can jump forward by one application step as many times as you want; just select “Jump to next application step” from the pull-down menu again, and it will jump forward again. You can repeat this as many times as you like.

I re-checked this. On my Linux netbook this does not work. On the Macs in the student labs, it does. Something is inconsistent.

Also, in re: “jump to beginning of selected”; if a section of the code is selected in the definitions window, then choosing “jump to beginning of selected” should jump to a step involving that piece of code.

HOWEVER: I understand that this violates typical interface expectations; we expect selection in drop-down menus not to trigger a change, but to change the meaning of a button-click somewhere else. I think that the right solution is probably to put lots of buttons at the top of the stepper window; tooltips would be an absolute necessity, but you’d also want someone to design decent graphics for the buttons.

Let me know what your thoughts on this are.

There is a label called "Jump...". If this label was replaced by a button then people could navigate the stepper more easily. One of the dropdowns could be something like "Jump forward 50 steps". Then when you select a dropdown nothing should happen; instead the user should press the "Jump" button to make things go.

I do not feel you need a lot of buttons if you implement those two changes (making the dropdown selection not actually change the stepper state, and making the Jump button activate the movement). That plus the other stepper fix would make things much more usable.

jbclements commented 6 years ago

On Nov 21, 2017, at 7:20 PM, Paul Nijjar notifications@github.com wrote:

On Mon, Nov 20, 2017 at 07:03:23PM +0000, John Clements wrote:

First off: I’m delighted that you’re using the stepper!

I am mostly writing on behalf of my students. They have been struggling this term.

Second: I’m sorry that the interface is so sub-optimal!

To answer your specific question: you can jump forward by one application step as many times as you want; just select “Jump to next application step” from the pull-down menu again, and it will jump forward again. You can repeat this as many times as you like.

I re-checked this. On my Linux netbook this does not work. On the Macs in the student labs, it does. Something is inconsistent.

See if you can give me a specific set of steps for reproducing this on a Linux machine; I’d be happy to try to reproduce it.

Also, in re: “jump to beginning of selected”; if a section of the code is selected in the definitions window, then choosing “jump to beginning of selected” should jump to a step involving that piece of code.

HOWEVER: I understand that this violates typical interface expectations; we expect selection in drop-down menus not to trigger a change, but to change the meaning of a button-click somewhere else. I think that the right solution is probably to put lots of buttons at the top of the stepper window; tooltips would be an absolute necessity, but you’d also want someone to design decent graphics for the buttons.

Let me know what your thoughts on this are.

There is a label called "Jump...". If this label was replaced by a button then people could navigate the stepper more easily. One of the dropdowns could be something like "Jump forward 50 steps". Then when you select a dropdown nothing should happen; instead the user should press the "Jump" button to make things go.

I do not feel you need a lot of buttons if you implement those two changes (making the dropdown selection not actually change the stepper state, and making the Jump button activate the movement). That plus the other stepper fix would make things much more usable.

Thanks for your input!

John Clements

pnijjar commented 6 years ago

I re-checked this. On my Linux netbook this does not work. On the Macs in the student labs, it does. Something is inconsistent.

See if you can give me a specific set of steps for reproducing this on a Linux machine; I’d be happy to try to reproduce it.

Okay. I reproduced this on a different machine with a different desktop environment.

Here is the program I used, if you care: 

(define (sum-numbers numlist)
  (cond
    [(empty? numlist) 0]
    [else (+ (first numlist) (sum-numbers (rest numlist)))]))

(sum-numbers (list 0 1 2 3 4 5))
jbclements commented 6 years ago

Okay, that makes sense. Even if I can't reproduce this (I haven't tried today), it makes sense that some window managers wouldn't send another "select" event for the re-selection of the same dropdown menu entry. It sounds like the solution to this problem is to overhaul the interface in a more dramatic way.