Mentor Code Changes

  • Nov 15, 2012
  • 0 Ð?омментарийs

To keep moving forward on the implementation while I'm working out a few design issues, I worked on filling in any missing pieces and fixing issues with the Select a World view and the Make a Suggestion view as they are.

Thinking ahead into the future for the suggestion tutorials (as well as for showing existing suggestions), I've been trying to determine what information we need, how to obtain it and when we can do that. I sifted back through the mentor suggestions from the study to confirm the types of suggestions mentors made and whether they fit with my current ideas on storing and representing the suggestions.

My understanding is  that right now tutorials are mainly for after remixing, in which case code is only added to the student's world, rather than needing to delete, modify and move around code that they already have. I think this makes the case of tutorials for suggestions more complicated because for mentor suggestions, we need to make sure that when a procedure is moved, we know that it was moved, rather than deleted and then added somewhere else, since that wouldn't necessarily teach the same concept.

Also, the way Michael is currently storing the origin of nodes is, I think, as they change. For the case of moving a procedure, even if the mentor deletes it and then re-adds it later, in the end, we really only want to show that the procedure was moved. I think that as-is, it would be pretty difficult to produce a good tutorial or show the existing changes. Michael mentioned that another possibility is rather than labeling nodes as the code is edited, they could be labeled upon saving by comparing the original (student) code with the edited (mentor) code. This seems like it may solve many of the problems I was having with doing it dynamically, so I think this may be the way to go for mentoring. Or, a combination may be possible, where a certain amount of labelling happens (like modification, or deletion), but we also do a comparison at the end to make sure we didn't miss anything.

There are also cases that need special consideration, such as when code within a custom procedure is changed(added/deleted or modified). In that case, the custom procedure should show up as modified. Another edge case would be if a parameter was added to (or deleted from)  a custom procedure. The custom procedure would be modified, but technically, something was added or deleted.

Thinking about these problems has also pushed me to consider how to address modifications and re-organization when displaying the code changes. I think revision histories on git with + and - on added and deleted lines makes sense and is useful when working with people who do software development and are used to this standard. However, in that system, if a line is modified, it would show a deleted line and the added new line that is slightly different. Similarly, a line that moves would be deleted from one location and added somewhere else. If this is what developers are used to seeing, it may make sense to show them the revisions in that way, but store them in a different way so that the suggestions are shown to kids in a way that makes sense.

Ð?омментарийs

  • No comments yet

Вход или Зарегистрироваться to leave a comment.